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.