Mozilla posts plan for certificate revocation checking
2014 seems to be the year of the great certificate revocation debate. Revocation was always a sore subject with cryptoheads, but the noise level on the issue shot up to 11 this spring with the news of the Heartbleed bug in OpenSSL.
As is often the case with TLS/SSL, Google was out front on this problem, but now Mozilla has posted a plan for improving certificate revocation checking in its software. The Mozilla approach tracks closely with Google's.
One of the disturbing implications of Heartbleed was that large numbers of secure web sites would have to revoke and reissue TLS/SSL certificates.
Tech Pro Research
There have always been reasons to lack confidence in the systems for certificate revocation in the PKI. There are two official, standards-based ways to check to see if a certificate has been revoked: the CRL or Certificate Revocation List, which is a static list of certificate serial numbers which can get very large and difficult to manage; and OCSP (Online Certificate Status Protocol), a method to perform a live query of the certificate authority for current status. Both methods have serious prolems.
OCSP was created to address the problems with CRLs, but OCSP can impose unacceptable latency on the page/resource request, so another standard was created: OCSP Stapling, in which an OCSP response is pre-packaged with the TLS web page and certificate, saving the time and trouble of communicating with the CA. But even this doesn't go far enough, as stapling is not mandatory; if a stapled response is not present and neither an OCSP nor CRL check work, browsers will still typically allow the page to load, because they don't consider the checks to be reliable enough to get in the way of the user. This is called a "soft fail."
So what to do? A number of methods have been proposed and are being implemented. First, there is a proposed extension to certificates called OCSP Must Staple. This extension says that if the certificate doesn't have a valid stapled OCSP response, the revocation check should fail. Mozilla explicitly endorses Must Staple and says they will advocate for it and implement it.
Google hasn't formally endorsed it, but Adam Langley, a key TLS engineer at Google, said in his personal blog that a scalable solution to the revocation problem could involve Must Staple. Must Staple also has the endorsement of the CASC (CA Security Council), an industry consortium of certificate authorities, including Symantec, GoDaddy and Comodo.
Google's other major move was to introduce CRLSets. These are Google-managed lists of revoked certificates that the company distributes to users through their existing update mechanism. Google curates this list so that only the "hot" certificates are included, ones that might matter for security. Mozilla will create a similar system called OneCRL.
The combination of CRLSet/OneCRL and OCSP Must Staple could result in a robust enough revocation system. It has the disadvantage of not being simple, but this is security and cryptography we're talking about.
Where is Microsoft in all this? They haven't made a big deal of it, but they have built a CRLSet-like system into all Windows versions since Vista. It's an expansion on the much older Windows system for tracking revoked trusted root certificates. They store the list of certificates in a CTL or Certificate Trust List. Microsoft is silent on the value of Must Staple though.
Conceptually, Microsoft's CTL, Mozilla's OneCRL and Google's CRLSets are similar enough that it would be stupid for the companies not to share lists. And why stop there? Standardize the format as well. I suggest doing so through the CASC, which has also endorsed the CRLSet approach. Microsoft publishes the URL of their disallowed CTL.
There is one last technique that both Mozilla and Langley praise: short-lived certificates. If certificates had lifetimes measured in days rather than years, the revocation problem would take care of itself. This is the approach that DNSSEC takes and could be the basis of a secure system, but I assume it would greatly increase the administrative burden on certificate authorities. For that reason, put your money on hack solutions that are more complex in design, but simpler for CAs to execute.