At 3:09 PM +0100 1/5/09, Ian G wrote: >The recent MD5 collision attack has also demonstrated a "brittle" side of OCSP >[1]: > >http://blogs.technet.com/swi/archive/2008/12/30/information-regarding-md5-collisions-problem.aspx > >It seems that, assuming we can create an intermediate or subroot certificate, >then we can also redirect the OCSP to a place of our choosing, because a >certificate refers to its own OCSP [2]. > >Hence, once we rogue-players have created a certificate like this, the CA >cannot revoke it using its own control mechanisms. Which implies OCSP is >mostly good for revoking "good certs," being the ones the CA itself issues, >and is less good at dealing with externally-controlled or rogue issues.
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. >What is also curious is Microsoft's response: It seems to be recommending >that OCSP be configured using local proxy responders. Look for the words >"custom OCSP" in the above link. The article specifically makes that recommendation for corporate PKI deployments only, not for general web access. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
