Ian G wrote, On 2009-01-05 06:09: > The recent MD5 collision attack has also demonstrated a "brittle" side > of OCSP [1]:
I wouldn't call it an attribute of OCSP any more than it is an attribute of revocation in general. The same thing is true for CRLs that is true for OCSP. The relying party learns what form of revocation check (CRL, OCSP, or none) is available, and how to access that revocation service, from the signed content of the cert itself. > 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]. Or you can just not bother with revocation checking at all by leaving that info out of your replacement cert ... providing that you can do that and still create a hash collision. > Hence, once we rogue-players have created a certificate like this, the > CA cannot revoke it using its own control mechanisms. It *may* be able to do so, or may not. One way that it may is this: If the CA uses a single CRL for all its revoked certs, and the RP's client fetches a copy of that CRL periodically, then the CA can put serial number of the rogue cert into its CRL, and the RP's client will honor that, even if the cert has no CrlDP extension. That's the only way known to me by which revocation could still work if the rogue cert contains different revocation information than the legitimate cert would have contained. Having said that, I should disclose that it is reported that Firefox's automated periodic CRL fetcher doesn't. :( > 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. Yes, I believe that's correct. This is why it's so important for CA's to use sufficient measures to avoid forgeable cert signatures. > 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. Firefox has a similar capability. You can configure Firefox to use a locally configured (proxy) responder instead of going directly to the CA's OCSP responder. IIRC, this will cause the OCSP request to be sent to the locally configured responder for any cert that has an extension indicating that its issuer supports OCSP. > Would people think this is best practices [3]? Proxy OCSP responders make a LOT of sense in corporate environments because they can cut down the number of OCSP requests that are actually sent to the CA's OCSP responder dramatically, and reduce latency for the user in the bargain. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
