4 ms·

Is certificate revocation really so common a crl of a normal authority is gigabyte sized?

schoen 4y ago
No, not at all. The bad case would be if Let's Encrypt discovers a problem (like a security flaw or implementation error in a validation method, as happened with the TLS-ALPN-01 method before) and concludes that it has to mass-revoke a very large number of affected certificates.
- hinkley 4y ago
  Or perhaps if another CloudBleed style incident ever happens.
roblabla 4y ago
The problem is, you need to design for the worse case scenario here, because when the worse case does happen, the last thing you need is for your revocation system to not work because it doesn't scale. So, no, it's not common. But it's necessary.
er4hn 4y ago
The DoD uses x509, and CRLs, in those Common Access Cards (CAC) everyone in the org has. Since this covers most of the armed forces, that's fairly large. As of 2012[1] this was around 200 MB of CRLs and was only expected to get larger over time. [1] https://dl.dod.cyber.mil/wp-content/uploads/pki-pke/pdf/unclass-certvalidation_capability_require-bestpractices.pdf https://dl.dod.cyber.mil/wp-content/uploads/pki-pke/pdf/uncl... - Pg 7, under Local Cache
- OrvalWintermute 4y ago
  As mentioned above, DoD uses smart strategies around certificate validation. CDNs + Localized OCSP + Tactical OCSP + Smart OCSP Clients + Network caching + OCSP & CRLs on the filesystem, just to name a few (not including delta CRLs and other solutions). The DoD OCSP Responders are configured to share hash sets with downstream OCSP Responders & Repeaters, which makes promulgation particularly easy.
michaelt 4y ago
According to [1] "On a typical Monday, we would expect to see a total of around 22,000-30,000 SSL certificates being revoked over the course of the day." i.e. ~8 million per year. [3] meanwhile says "1.8 million certificates are revoked per year" Looking at a random CRL [2] it's 41 bytes per revoked certificate. 8 million records at 41 bytes per record would be 300+ Megabytes. And a cautious CA might keep revoked certificates in their CRL for more than a year. So if an event like heartbleed happened again and uncommonly large numbers of certificates needed to be revoked, the gigabyte range is within the bounds of possibility. [1] https://news.netcraft.com/archives/2014/04/11/heartbleed-certificate-revocation-tsunami-yet-to-arrive.html https://news.netcraft.com/archives/2014/04/11/heartbleed-cer... [2] http://crl3.digicert.com/Omniroot2025.crl http://crl3.digicert.com/Omniroot2025.crl [3] https://www.grc.com/revocation/crlsets.htm https://www.grc.com/revocation/crlsets.htm
- WorldMaker 4y ago
  > And a cautious CA might keep revoked certificates in their CRL for more than a year. A CA does need to keep the revoked certificate in the CRL until at least the natural expiration date on the certificate, so for the CAs that give certificates out with 5 years out or more expiration dates, they may need to keep CRLs for much longer than just a year just naturally by nature of their expiration dates.
  - tialaramex 4y ago
    This CRL rule is about the Web PKI, for which currently policy requires new certificates expire after no more than 398 days. The previous status was the certificates could last up to 825 days, however that policy changed at the end of August 2020, so there are no extant certificates under those rules which expire after this year. And before that the policy was 39 months, but the last such certificate expired in 2021. Before that the policy was 5 years, but that policy changed in 2015 and so such certificates are long expired.

No, not at all. The bad case would be if Let's Encrypt discovers a problem (like a security flaw or implementation error in a validation method, as happened with the TLS-ALPN-01 method before) and concludes that it has to mass-revoke a very large number of affected certificates.

hinkley 4y ago
Or perhaps if another CloudBleed style incident ever happens.

roblabla 4y ago

The problem is, you need to design for the worse case scenario here, because when the worse case does happen, the last thing you need is for your revocation system to not work because it doesn't scale. So, no, it's not common. But it's necessary.

er4hn 4y ago

The DoD uses x509, and CRLs, in those Common Access Cards (CAC) everyone in the org has. Since this covers most of the armed forces, that's fairly large. As of 2012[1] this was around 200 MB of CRLs and was only expected to get larger over time. [1] https://dl.dod.cyber.mil/wp-content/uploads/pki-pke/pdf/unclass-certvalidation_capability_require-bestpractices.pdf https://dl.dod.cyber.mil/wp-content/uploads/pki-pke/pdf/uncl... - Pg 7, under Local Cache

OrvalWintermute 4y ago
As mentioned above, DoD uses smart strategies around certificate validation. CDNs + Localized OCSP + Tactical OCSP + Smart OCSP Clients + Network caching + OCSP & CRLs on the filesystem, just to name a few (not including delta CRLs and other solutions). The DoD OCSP Responders are configured to share hash sets with downstream OCSP Responders & Repeaters, which makes promulgation particularly easy.

michaelt 4y ago

According to [1] "On a typical Monday, we would expect to see a total of around 22,000-30,000 SSL certificates being revoked over the course of the day." i.e. ~8 million per year. [3] meanwhile says "1.8 million certificates are revoked per year" Looking at a random CRL [2] it's 41 bytes per revoked certificate. 8 million records at 41 bytes per record would be 300+ Megabytes. And a cautious CA might keep revoked certificates in their CRL for more than a year. So if an event like heartbleed happened again and uncommonly large numbers of certificates needed to be revoked, the gigabyte range is within the bounds of possibility. [1] https://news.netcraft.com/archives/2014/04/11/heartbleed-certificate-revocation-tsunami-yet-to-arrive.html https://news.netcraft.com/archives/2014/04/11/heartbleed-cer... [2] http://crl3.digicert.com/Omniroot2025.crl http://crl3.digicert.com/Omniroot2025.crl [3] https://www.grc.com/revocation/crlsets.htm https://www.grc.com/revocation/crlsets.htm

WorldMaker 4y ago
> And a cautious CA might keep revoked certificates in their CRL for more than a year. A CA does need to keep the revoked certificate in the CRL until at least the natural expiration date on the certificate, so for the CAs that give certificates out with 5 years out or more expiration dates, they may need to keep CRLs for much longer than just a year just naturally by nature of their expiration dates.
- tialaramex 4y ago
  This CRL rule is about the Web PKI, for which currently policy requires new certificates expire after no more than 398 days. The previous status was the certificates could last up to 825 days, however that policy changed at the end of August 2020, so there are no extant certificates under those rules which expire after this year. And before that the policy was 39 months, but the last such certificate expired in 2021. Before that the policy was 5 years, but that policy changed in 2015 and so such certificates are long expired.