In a group chat today, someone asked about the recent dispatch from LetsEncrypt about ending OCSP service. To wit, they brought up that CRLs can be big and clunky and OCSP stapling fixes the privacy problem. I started to duck, but not before someone said "@rs is probably the person I would ask". Not sure how I became the designated crypto expert, but here goes...

When you download a CRL, you aren't necessarily downloading a list of all certificates that have ever been revoked from that CA, you're downloading a list of certificates that have been revoked but would otherwise appear to be valid in a proper context. There would be little point in listing certificates that had been revoked but were invalid by virtue of their own expiration or an intermediate CA's expiration. Given how short the lifetime of LE certs is (90 days), this is likely to be a whole lot less clunky than you might think. Certs that have been renewed are not auto-revoked. So in practice it is quite small. For instance:

Hunters-Laptop:~ rs$ openssl x509 -text -noout < server-intermediate.crt | grep -A3 "Distribution Points"
            X509v3 CRL Distribution Points: 
                Full Name:
                  URI:http://x1.c.lencr.org/
    Signature Algorithm: sha256WithRSAEncryption
Hunters-Laptop:~ rs$

and

Hunters-Laptop:~ rs$ curl http://x1.c.lencr.org/ | openssl crl -text -noout | grep Certificate
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   717  100   717    0     0  63149      0 --:--:-- --:--:-- --:--:-- 65181
Certificate Revocation List (CRL):
No Revoked Certificates.
Hunters-Laptop:~ rs$

I'll admit that I didn't expect the CRL to be 717 bytes long including the signatures and metadata and literally empty, but upon reflection I suspect that there is not a whole lot of revocation activity going on in that CA despite the fact that how to do it is well documented and revoking the certificates that go with compromised keys is required by the subscriber agreement - section 3.2.

It's important to note that OCSP and OCSP stapling are not the same thing. While OCSP has privacy problems on its surface, OCSP stapling (the proffered solution) has implementation bugs and limitations. See the Wikipedia article on it for the particulars.

Supporting OSCP at all is setting up for a potential information leak. The ISRG dispatch about it linked above states that they are specifically concerned about CAs that do not currently collect or retain this data being forced to under color of law. Left unstated is the possibly of having to do so without disclosure.

Even setting aside the privacy and trust implications of complying with such an order, through a risk lens it's not entirely clear to me that reimbursement of the costs of doing it would be forthcoming. It's hard enough to get reimbursement for CALEA costs and litigation is expensive - if the usual actors who don't like pervasive crypto wanted a fulcrum upon which to put ISRG out of business, this might be it. No need to actually do anything with the data collected, just force it to be collected and delivered - if you don't like footing the bill sue us for the next 8 years and pay the lawyers while the case makes its way through the courts. Better for the LetsEncrypt folks to just say "nope, sorry, not doing OCSP anymore".