Questions and suggestions about OCSP deprecation and CRL

Issuance Tech
1

I have a few concerns about Let's Encrypt's announced plans for OCSP deprecation and CRL. I am not generally opposed to those changes, but I think there could be better communication, and it'd be good if there would be better ways to test things. I will likely have to deal with this in a few places where I currently rely on revocation checks via OCSP.

As I understand this post

Let's Encrypt intends to replace OCSP with CRLs, possibily quite quickly ("rapid timeline", "last OCSP response between three and six months after that announcement").

I have a few questions and suggestions. I have not found any good documentation around the already existing CRLs and their use. If there is one, pointers welcome. As far as I can see, the CRL URLs are not widely communicated, but they appear to be in CCADB. I checked it for the R11 intermediate, and it lists 128 different urls (http://r11.c.lencr.org/{1..128}.crl). So it appears there is not one CRL per issuing cert, but partitioned CRLs.

I have the following questions:

  • Will the future non-OCSP/CRL-only certificates have the CRL URL encoded, or is there another way to figure out which CRL corresponds to which certificate?
  • What is the expected way to check revocation status of a certificate with CRL? Is it necessary to download all CRLs in order to be able to check revocation status? Will there be any way to perform revocation checking without resorting to external data sources like CCADB?

Furthermore, I would suggest that in order to let people prepare for this change, Let's Encrypt should publish test certificates in the format that those future non-OCSP certificates will use. (Ideally running on a live host, with variations revoked and non-revoked.) Those could be published as soon as possible from Let's Encrypt's staging root, or a fake/test root ca. As soon as CA program rules allow, test certificates from Let's Encrypt's live certificates could be published.

Ideally, such test certificates should be made available a while before those changes are going live.

6 Likes
2

The baseline requirements currently require either OCSP or CRL URLs encoded in the certificates, except for short-lived (under 7 day) certificates which don't require revocation checking. I would expect the end state to be CRL URLs in non-short-lived certificates. Those details will come once a transition plan is announced.

We don't expect anyone to rely on CCADB for CRLs unless they're operating a "CRL Push" or summarization feature like the browsers do. I do hope we see some of that browser technology adopted outside of browsers, too, though.

The full details of our approach will be announced once we have more details from the root programs about timelines on their policies.

4 Likes
3

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.