letsencrypt
Add CRL generation to revocation updater
We have OCSP implemented. According to our CPS we don't need to sign CRLs for leaf certificates, only for our intermediate.
However, Firefox and Chrome each have a non-OCSP mechanism by which they ship lists of revoked certificates:
https://dev.chromium.org/Home/chromium-security/crlsets https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/
We should figure out how to make sure our revocations make it into those lists if applicable. Does Mozilla/Google crawl OCSP responses, or do they expect to be able to fetch a CRL?
Note that we have both admin- and user- initiated revocation, plus the various revocation reason codes.
I can't speak for Chrome, but the Mozilla OneCRL list is (1) manually maintained, and (2) only covers intermediate CA certificates. So this is not an issue.
It looks like Chromium does poll CRLs to get CRLset information. We should add CRL generation to the periodic revocation updater (and, for LE, send the URL to @agl to request inclusion).
Moving this out to General Availability, since clients other than Chrome will fetch OCSP anyway.
Chrome's CRLSets indeed crawl only CRLs. (It's not really possible to crawl OCSP.)
If you want to get leaf certificates included in the Chrome CRL you can publish a CRL, but not link to it in the certificates. That way, nothing will fetch the CRL except crawlers that are explicitly looking for it.
Also, the CRL should be annotated with revocation reasons so that unimportant revocations can be filtered out. (Or else only include important revocations in the CRL.) This might require an indication from the site operator that they need a "hard" revocation (i.e. key loss) as opposed to just rotating the key etc.
The underlying logic for this should probably be implemented upstream in CFSSL since it'll require a key that (I think) should be stored in a HSM, there is already an issue for it open at cloudflare/cfssl#43.
Blocked on #140 (allowing user to specify the revocation reason instead of always setting it to ocsp.Unspecified ourselves).
While it's not a immediate priority this is something we intend on supporting in the future.
As per the latest Mozilla and Apple Root Store Policies, we will be required to be issuing CRLs as of October 1, 2022. We've completed design, implemented a proof of concept, and are now moving on to review and finalization of the implementation. We are resurrecting this bug to track that work, and have the following sub-bugs (and maybe more) to track smaller work items:
- #6160
- #6161
- #6162
- #6163
All of the components have landed. Bringing this bug into the current milestone to track deployment to Staging and Prod, at which point I'll close this.
CRL generation and serving is fully deployed in Staging, and should be in Prod later this week!