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