Let's encrypt seems to intend to replace OCSP, and also OCSP stapling, with CRLs. However, the blog post explaining the OCSP privacy issues doesn't seem to address at all the other problem OCSP stapling solves, which is of CA server downtime. This was a very common problem with OCSP, that has a worse practical impact in practice for clients that want to be safe at least in my past experience, than the privacy concerns.
Is the intention that this problem will now be introduced? I can't find any information on CRL stapling on Google. It seems like this mechanism would be needed to avoid this, unless the universe should go back to just letting any man in the middle block the CRL lookup requests again, and clients won't be able to do anything about it. If true, I don't understand how this wouldn't be a huge step downward in terms of security compared to OCSP stapling that clients could decide to enforce if the OCSP servers aren't reachable.
Or am I missing something? My apologies if I got any of this wrong, I'm not a crypto expert.
The big change that's happened in the CRL ecosystem in the last few years is that clients do not directly fetch CRLs from CAs.
Instead, the major browsers operate "push" systems, which condense CRLs across the entire CA ecosystem and push them to clients out-of-band.
The best documented of these system's is Mozilla's, called CRLite. Chrome's is called CRLSets. Apple also operates a system that isn't very documented, but is known as "Valid" because it uses the hostname valid.apple.com.
Of course not all systems support these, so some clients may still fetch CRLs. Unlike OCSP, there's a small number of CRLs that cover all certificates, so caching them is much more readily feasible. One of the original (in the 90s) blockers for this was the size of CRLs, but modern end-user systems typically can support this, except for the smallest embedded devices - which often have no revocation checking anyways.
Short-lived certificates without revocation information are the other option, which are logically equivalent to a certificate plus OCSP staple. These are coming, but we can't support them at the same time as OSCP due to the scale of our CA.
I''m still confused: wouldn't the push systems not work for a large amount of clients, like, wget, curl, and so on? And I assume short-lived still means more than a month, doesn't it? Since a certificate that leaked might get misused in mere days, I don't think that would help much either, unless short-lived is a mere 48 hours or so. But in that case, if the CA goes down, then half the internet is dead again.
I don't really see still how this is going to be solved without a CRL stapling equivalent.
Sorry it seems like I left out the actual question, and of course I might be still misunderstanding, since it seems like I can't edit the post above here it is:
Why wasn't there simply a CRL stapling put on the roadmap, preferably before a major CA like Let's Encrypt abandons OCSP stapling? It doesn't seem like it would conflict with any of the other measures.
There is no mechanism for servers to provide CRLs, so no "CRL stapling" doesn't exist. You would have to develop a completely new sub-protocol for that and have that deployed to billions of devices, which tends to take many years and significant resources. The vendors will rather invest their time and energy into alternatives, like pushing CRLs via back-channels. Or just circumvent the problem with short-lived certificates.
Also, look at it this way: If stapling was viable, then why not just keep OCSP stapling? OCSP stapling is privacy-preserving, compatible, and theoretically reliable. The reason it is abandoned is because Let's Encrypt decided that they've given up on it - adoption of OCSP stapling isn't growing, server support is moderately poor, client support is horrible. We couldn't make OCSP stapling work in over 15 years, so why would a hackish attempt at a "OCSP stapling, but in green this time" have more success?
Sorry I might be misreading this again, but wouldn't pushing the CRLs via back-channels also require a new sub-protocol and need to be deployed to millions of devices, but while then only being limited to browsers? I don't really understand the difference.
The browser vendors already have ways of pushing updates to their users. This isn't new. CRLite has also been around for a few years now, so isn't brand new either. Pushing CRLs via a back-channel isn't a great solution, because it leaves every TLS library vendor to fight on their own. A single, unified standard would have been better, but the one that we had failed.
There is no hopeful future for revocation. The CRLs are a band aid until everyone is on short-lived certs and revocation just goes away entirely.
So what's the "short" revocation interval people are dreaming of? Is it something like 3-4 days? If it's longer, I don't really understand why not everybody would still want CRL stapling (and until then, OCSP stapling to stay available). Sorry if I'm still missing something here.
On some OSes, there's a shared CRL cache that can be used, so tools like curl don't have to fetch them each time. Eg, curl on windows uses the OS's stack to do so. On other platforms, curl simply doesn't check revocation.
Short-lived certs have the same lifetime requirements as OCSP staples, 7 days or less, so it's not a reduction in security. It's also one less signature, which is important in post-quantum when signatures are much bigger.
This is ultimately a pragmatic approach to making revocation better for most users, in browsers. It may not help everyone, and not right away.
For users of OCSP stapling amd must-staple, it isn't as good. But there's so little adoption of must-staple that it unfortunately isn't a path forard.
The CA browser forum has decided that certificates valid for 7 days or less do not need any revocation. Let's Encrypt will offer 6 day certificates in the near future.
Thanks, the same lifetime requirements part explains it. Reading the six days blog post though, I wonder if it still wouldn't be nice to have CRL URLs for those six days certs anyway. Then they could even be revoked early for clients which check those. But I guess I get if the general notion is that at that point, CRL servers might be considered not worth the effort anymore to keep running.
The CRLs will still exist and support revocation, which will still be consumed and pushed by the push-based systems (which consume all CRLs). In fact we're likely to launch with CRL URLs.
Unlike OCSP, it's easy to keep supporting CRLs, so they're probably never going away.
Eventually, our 6 day certs will not contain CRL URLs. Not having to contain revocation information is the whole point of short-lived certs.
Those short-lived certs probably will continue to appear on our CRLs anyway. So if you're getting your CRLs from a system like Mozilla's CRLite, then you can still get revocation updates for short lived certs. But clients that try to download CRLs directly won't be given a URL to do so, because a) that reduces traffic to our CRL servers, and b) it would have little worst-case security benefit due to the lifetime of the CRLs outliving the certificates themselves.
Since I assume >30 day certificates will remain in use for other CAs and OCSP support seems to be winding down, wouldn't it remain a problem worth addressing on Linux? Edit: nvm, I mixed up the threads. Thanks for elaborating.
No, short-lived certs will not reach general availability before May 7.
Also, the shortlived profile uses all the same attributes as the tlsserver profile, which is already omitting the OCSP URI. If shortlived certs were generally available today, they still wouldn't contain an OCSP URI.
Short-lived certs might be fully available before we remove the CRL URL from them. That depends on a variety of factors, including changes to the Microsoft Root Program Requirements.