7 ms·
Let’s Encrypt will put CRL URLs in certificates before or when removing OCSP URLs, so no CCADB lookup should be required
by mcpherrinm 2y ago
Let’s Encrypt will put CRL URLs in certificates before or when removing OCSP URLs, so no CCADB lookup should be required
- agwa 2y agoIndeed! I forgot that the BRs mandate the CRLDP extension if the certificate lacks OCSP AIA. So all (non-short-lived) certificates will continue to have a standard revocation checking mechanism encoded in them.
- remram 2y agoSo my client should download the 100 MB CRL to check? Is that the secure workflow?
- warhorse10_9 2y agoModern crls are partitioned so this really isn’t a problem you will run into.
- remram 2y agoDoes that not recreate the privacy problem then, since the CRL server can see which CRL partition we download and when? Should we expect CRL stapling?
- mst 2y agoI think one would expect a partition to cover a lot of certificates for its size (or in the case of a compromise all certificates mapped to that partition) so I don't think you end up with nearly so meaningful a problem.
- mcpherrinm 2y agoThe largest Let's Encrypt CRL right now is 254 KB. Most are smaller. We might want to partition into smaller shards again to hit a bit smaller size than that in the future. Shorter certificate lifetimes will also reduce CRL sizes. A lot of traffic comes from browsers, or TLS stacks integrated with their host operating system, which we expect will use compressed push-based methods like Mozilla's CRLite to receive more efficient data structures as well. One thing this announcement allows us to do is motivate us to start working on making CRL mechanisms more efficient.