Without expressing my opinions on the wisdom of whatever Google is proposing...

What Jean-Marc has described (and what the Google post also describes) is already covered by RFC 5280 in the concept of "indirect CRL", which you can see in Section 5.

It is also worth pointing out that "indirect OCSP" exists in the form of "designated OCSP responders". So, you have your online as well as your offline options.

The nice thing about indirect CRLs is that they are a standardized format. What Mozilla currently does with its internal blacklist, written in C++, is basically a highly proprietary form of an indirect CRL. The problem (if any) with indirect CRLs is lack of automatic support in the crypto stacks: all the more reason to beef up libpkix and the NSS entry points to libpkix. Also consider that revocation is cumulative: if you have an authoritative list for some reasons (keyCompromise) and a cert is not on the list, it doesn't mean that it's valid--just that it's not revoked for keyCompromise reasons. You don't need a single CRL (indirect or otherwise) for everything; rather, you are supposed to be able to compare against multiple lists.

Each valid list you check against reduces the overall risk profile of using the certificate. That's the deal. Therefore (in view of Nelson's recent comment about size), a list that is very small but lists the whole world's keyCompromise certificates, will offer more bang for the buck than a huge list from one CA that covers all of the reason codes, like affiliationChanged or whatever. You can never drive the risk to zero, but you can make it low enough to be pretty acceptable for certain applications (e.g., "low assurance web browsing", as opposed to "high assurance EV web browsing").

Put it another way. Suppose that for *every* improper reliance, the CA is responsible for paying the damages. But, the CA has 100K of silver bullets to immunize itself from liability. The CA is going to use those 100K bullets on reliances where the risk of loss is high, right? (I.e., keyCompromise, or caCompromise.) The long tail of everything else is then just a cost of doing business.

-Sean
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to