A New Life for Certificate Revocation Lists
letsencrypt.org
A New Life for Certificate Revocation Lists
1–10 of 72 posts
Re: A New Life for Certificate Revocation Lists
#2Is certificate revocation really so common a crl of a normal authority is gigabyte sized?
Re: A New Life for Certificate Revocation Lists
#3Is certificate revocation really so common a crl of a normal authority is gigabyte sized?
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.
Re: A New Life for Certificate Revocation Lists
#4I was kind of surprised that OCSP stapling didn't get any mention at all. I thought that was a major improvement in both resource cost and privacy? Since the time stamped response is proxied by the site operator rather then going directly to the CA, the load is almost entirely switched to the site itself, and the site itself is the only one who knows a given IP is asking for it, which is fine because obviously the site knows a given browser is connecting to it anyway. It's decentralized again. I vaguely remember at one point there was a major limitation of only supporting a single OCSP response at a time but I thought that was dealt with via a later RFC and then entirely obviated as an issue by TLS 1.3.
Did something happen there or some other significant issue get discovered? I'm curious why the move back to CRLs (albeit improved) vs must-staple. It seemed like a reasonable elegant and straight forward solution that fit the web pretty well.
Re: A New Life for Certificate Revocation Lists
#5I was kind of surprised that OCSP stapling didn't get any mention at all. I thought that was a major improvement in both resource cost and privacy? Since the time stamped response is proxied by the site operator rather then going directly to the CA, the load is almost entirely switched to the site itself, and the site itself is the only one who knows a given IP is asking for it, which is fine because obviously the si…
must-staple requires additional effort from server operators, which is very challenging to roll out. This new scheme can be implemented by the browsers and CAs together, which is vastly simpler than having every webserver in the world turn on OCSP stapling.
There isn’t any particular force driving for OCSP stapling: Browsers can’t turn it on until it is ubiquitous. CAs don’t want to enforce must-staple because their users will need enormous amount of help rolling it out. Site operators don’t care if browsers are fetching OCSP (especially since Chrome and Edge don’t)
Re: A New Life for Certificate Revocation Lists
#6I was kind of surprised that OCSP stapling didn't get any mention at all. I thought that was a major improvement in both resource cost and privacy? Since the time stamped response is proxied by the site operator rather then going directly to the CA, the load is almost entirely switched to the site itself, and the site itself is the only one who knows a given IP is asking for it, which is fine because obviously the si…
I also love OCSP stapling but there are some limitations:
- webserver need to implement it
- admin need to enable it
- webserver need internet access
Maybe they saw with some telemetry that very few website actually enable OCSP stampling and decided to implement a fix that cover all certs and can really be deployed
Re: A New Life for Certificate Revocation Lists
#7I was kind of surprised that OCSP stapling didn't get any mention at all. I thought that was a major improvement in both resource cost and privacy? Since the time stamped response is proxied by the site operator rather then going directly to the CA, the load is almost entirely switched to the site itself, and the site itself is the only one who knows a given IP is asking for it, which is fine because obviously the si…
Yes, I noticed this too and asked the author about it [0].
IMO, OCSP stapling is the best overall solution until certificate lifetimes are shorter (As a server developer I'm worried that the focus on independent CRLs will make it difficult to automate certificates in the face of revocation. Currently, Caddy staples OCSP for all certificates by default, caches the staples, and refreshes them halfway through their lifetime. Works great. Every server should do this. And when an OCSP response is discovered to be Revoked, Caddy automatically replaces the certificate. Works great. Every server should do this.
If every browser is independently going to decide which certificates to distrust, now I am not sure of a good, authoritative way to determine "revoked" and then replace certificates automatically. I'm worried this will hurt the TLS ecosystem unless we answer those questions first.
Actually, let's just shorten certificate lifetimes and be done with it already.
Main blockers to short cert lifetimes:
- CA's uptime determines Web's uptime.
Main solution:
- Multiple redundant ACME CAs. If one goes down, try another. (This is what Caddy already does.)
Re: A New Life for Certificate Revocation Lists
#8Browsers and CAs still deciding for the user what's best with yet another centralized database that we have to "trust" is complete and implemented correctly. I don't see how this is so hard: just let us download the CRLs. Maybe add them on a torrent-like system so they can be shared (and validated) peer-to-peer, or at least have hundreds or thousands of mirrors that can provide that data. All this "it's too big and the user would have to download it" bullshit is just pushing us more and more into "computing as a service"; aka: we OWN your digital life.
Edit: I was partly wrong, this is a good thing because you CAN download the CRLs now (see comments below here for info), whereas previously you couldn't. Your browser still probably won't support a full CRL download, but I could be pleasantly surprised.
Re: A New Life for Certificate Revocation Lists
#9Browsers and CAs still deciding for the user what's best with yet another centralized database that we have to "trust" is complete and implemented correctly. I don't see how this is so hard: just let us download the CRLs. Maybe add them on a torrent-like system so they can be shared (and validated) peer-to-peer, or at least have hundreds or thousands of mirrors that can provide that data. All this "it's too big and t…
> I don't see how this is so hard: just let us download the CRLs
Previously, you couldn't do this, because not all CAs published CRLs.
Beginning October 1, you will be able to just download the CRLs, because Apple and Mozilla are requiring it.
It's therefore unclear what your beef is,
Re: A New Life for Certificate Revocation Lists
#10Browsers and CAs still deciding for the user what's best with yet another centralized database that we have to "trust" is complete and implemented correctly. I don't see how this is so hard: just let us download the CRLs. Maybe add them on a torrent-like system so they can be shared (and validated) peer-to-peer, or at least have hundreds or thousands of mirrors that can provide that data. All this "it's too big and t…
> I don't see how this is so hard: just let us download the CRLs Previously, you couldn't do this, because not all CAs published CRLs. Beginning October 1, you will be able to just download the CRLs, because Apple and Mozilla are requiring it. It's therefore unclear what your beef is,
> Beginning October 1, you will be able to just download the CRLs
Correction: Apple and Mozilla will be able to just download the CRLs. Not me. The link in the post SPECIFICALLY says us common plebes don't get that right.