At 4:01 PM -0800 1/5/09, Nelson B Bolyard wrote: >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.
All of that is true (and is true for CRLs, I believe), but it is not what I was speaking to. The recent MD5 attack creates a rogue sub-CA, that is a new child of one of your trust anchors. The Microsoft article made it sound (to me, at least) that if the rogue sub-CA (the child) has a AIA, then IE will not look in the parent's AIA to determine the status of the child. If that's true, it is broken. Each level of the family can have its own AIA that applies to all of its children, not just to end entities. >4) Trust anchors are not necessarily roots. Of course. I'm not seeing where that is relevant here, but I could be missing something. >5) Most roots don't have AIA cert extensions. Only 8 out of the 125 roots >in nssckbi have them. Now *that* is sad. I was hoping for closer to 50%. It does not make my argument wrong, just pretty moot. --Paul Hoffman _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
