Apple seems to have omitted this question from their documentation (Parse the Receipt and Verify Its Signature)
It seems to leave it as an excercise for the reader:
/* You must verify the fingerprint of the root certificate and verify the OIDs of the intermediate certificate and signing certificate. The OID in the certificate policies extension of the intermediate certificate is (1 2 840 113635 100 6 2 1), and the marker OID of the signing certificate is (1 2 840 113635 100 6 11 1). */
If you don't do the thing in the comments, and don't verify the fingerprint of the root certificate, but only the fact that it's a known and valid root (such as Apple Root CA), then theoretically, an attacker with a private key and its certificate issued by any root authority (for example, one can use another Apple Developer ID but even a non-Apple one such as a VeriSign SSL key and cert created for a HTTPS website) can sign a receipt that will pass verification by your application without the attacker having paid for it. Because the root cert will be a valid one, not a concrete one, so the entire cert chain will be valid.
But even If you validate the root cert's fingerprint and make sure it's Apple Root CA, the attacker can still use his Developer ID to sign the fake receipt, because the Developer ID certificate is also signed by Apple Root CA.
It means that we also need to verify the intermediate certs, but they are not root and are not pre-installed on the computer. Also, their number may theoretically change in the future, so they can hardly be hard-coded (Apple is free to choose how many intermediate certs to use, and also they can be revoked/expired/replaced etc).
How do you work around this problem? It looks like it's creating a vulnerability? Is there an example of how to verify all intermediate and root certs?
