The primary aim[1] of CRLSets was always to be a mechanism via which we could quickly react to CA situations like DigiNotar, ANSSI etc. Doing full binary pushes

The primary aim[1] of CRLSets was always to be a mechanism via which we could quickly react to CA situations like DigiNotar, ANSSI etc. Doing full binary pushes like we did during a few years back was too heavy. As a secondary aim, we tried to make them do something more. Quoting myself[2]: "The original hope with CRLSets was that we could get revocations categorised into important and administrative and push only the important ones. (Administrative revocations occur when a certificate is changed with no reason to suspect that any key compromise occurred.)". Certainly at the time, and probably even now with the large number of post-Heartbleed revocations, most revocations are not done because key compromise is feared, but because a certificate is getting rotated for other reasons. (E.g. a site asked for a certificate to be reissued with different names but the same key. The old certificate now hangs around as a revocation for years.) It seemed reasonable that a few tens of thousands of revocations would be enough to cover the cases where actual key compromise worries had occured - if the CAs would sort them. Again, quoting myself[2]: "Sadly, that mostly hasn't happened." The text even contains a situation where online revocation checking is supposed to help, except it probably doesn't as usual: The claim is that a user will download and cache a CRL while not being attacked and then be protected from a local attacker using a certificate that was included on that CRL. The problem is that OCSP only covers a single certificate. OCSP is used in preference because it's so much smaller and thus removes the need to download CRLs. So the user isn't expected to download and cache the CRL anyway. So that doesn't work. However, it's clear that /someone/ is downloading CRLs because Cloudflare are spending half a million dollars a month[3] to serve Globalsign's CRLs. Possibily it's non-browser clients but the bulk is probably CAPI (the library that IE, Chrome and other software on Windows typically uses - although not Firefox). CAPI will download a CRL when it has 50 or more OCSP responses cached for a given CA certificate. But CAs know this and /split/ their CRLs so that they don't get hit with huge bandwidth bills. But a split CRL renders the "protection" from caching ineffective. So that argument is actually for something like CRLSets (download and cache revocations) over online checking. It's just a clumsy way of arguing that the downloaded data should be much larger so that it covers most or all revocations. Quoting myself again: "Perhaps we need to consider a system that can handle much larger numbers of revocations, but the data in that case is likely to be two orders of magnitude larger and it's very unlikely that the current CRLSet design is still optimal when the goal moves that far. It's also a lot of data for every user to be downloading and perhaps efforts would be better spent elsewhere. It's still the case that an attacker that can intercept traffic can easily perform an SSL Stripping attack on most sites; they hardly need to fight revoked certificates." The conclusions in the text that follow from that reasoning are then mostly wrong, although OCSP Must Staple is still a nice idea. If Firefox implement it first then good for them. It's tougher for Chrome because we use the platform's verification libraries. (I wrote a bunch of thoughts about what a good design for a "large" CRLSet would look like[5].) [1] https://www.imperialviolet.org/2012/02/05/crlsets.html https://www.imperialviolet.org/2012/02/05/crlsets.html [2] https://www.imperialviolet.org/2014/04/19/revchecking.html https://www.imperialviolet.org/2014/04/19/revchecking.html [3] http://blog.cloudflare.com/the-hard-costs-of-heartbleed http://blog.cloudflare.com/the-hard-costs-of-heartbleed [4] http://technet.microsoft.com/en-us/library/ee619754(v=ws.10).aspx http://technet.microsoft.com/en-us/library/ee619754(v=ws.10)... [5] https://www.imperialviolet.org/2011/04/29/filters.html https://www.imperialviolet.org/2011/04/29/filters.html