Paul Hoffman wrote, On 2009-01-05 08:54: > At 3:09 PM +0100 1/5/09, Ian G wrote:
>> [...] Hence, once we rogue-players have created a certificate like this, >> the CA cannot revoke it using its own control mechanisms. [...] > I am not convinced the article is correct. If it is correct, it is a > serious but easily-fixed bug in IE. That is, if a trust anchor contains a > AIA that points to an OCSP responder, and the rogue sub-CA has an AIA > that points to a different OCSP responder, the validation process should > should check the OCSP of the trust anchor. I'm surprised that you wrote that, for several reasons. Let me explain some of them. For brevity, I will use the following terms: child - the cert whose revocation we want to check parent - the cert for the CA that issued the child cert sibling - another cert issued by the same parent CA grandparent - the cert for the issuer of the parent cert. Everything I write below about OCSP is also true for CRLs, IINM. 1) It's not generally true that you can use the OCSP URL in the parent cert to check the OCSP status of a child cert. This is because it is not generally the case that the issuer of the child is also the issuer of the parent (that is, that parent == grandparent, parent is a root). 2) It's also not generally true that you can use the OCSP URL in a sibling to check the OCSP status of a child. This is because the parent may have multiple OCSP responders and may use different responders for different certs that it issues. Indeed, the parent could put a unique OCSP URL into every cert it issues. 3) A corollary of (2): Even when parent == grandparent, and hence parent is also a sibling, it's not generally true that you can use the OCSP URL from the parent to check the OCSP status of a child. 4) Trust anchors are not necessarily roots. 5) Most roots don't have AIA cert extensions. Only 8 out of the 125 roots in nssckbi have them. I'm not aware of anything in any RFC that contradicts any of the points I made above, but if you are, please share that with me/us. Thanks. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
