'mcpherrim posted a comment below[1] with some additional information, including changes to the Web PKI and CRL distribution techniques that may eventually make them more useful.
CRL is better suited for "high-volume" exchanges, for example for a CA to publish all their revocations [so that a system such as CRLite can be built].
I think we all want a good solution here. But none of the currently widely deployed ones are that.
As I see it, the main problem is that browsers don't want to do OCSP any more. Sure, we have a problem with how stapling is implemented in _some_ popular platforms (but not Caddy—hi Matt), but today maybe even those are fixed. The main problem IMO is that browsers won't support must-staple.
In the interest of full transparency, I have a pet peeve about people saying revocation doesn't work. I appreciate that that's the current reality, but—again—only because browsers choose not to implement it. Things would change overnight if Chrome (obviously) changed their stance.
My understanding is that the primary concerns with OCSP (meaning non-stapled OCSP) are that it (1) leaks end user intent to CAs, such as sites being visited, and (2) in its original form with no transport security, it is no stronger than the adversary that it needs to protect TLS/the Web PKI against (i.e., any network adversary can block the OCSP request and everything will fail open).
OCSP stapling avoids both of those concerns, but requires web server and other stack changes that are not on the "enforcement" path in the way that CAs and other "direct" parts of the PKI are. The talk infers that this is why OCSP adoption has been so sluggish (which I didn't realize was the case before).
FWIW, I'm sorry if I came across as dogmatic here -- revocation is conceptually important, and I think it'd be great if we ended up in a Web PKI where revocation was more effective. But I can also see why browsers have fumbled and/or dragged their feet on the CRLs and OCSP for so long.
When must-staple initially came out, it came to light that web servers viewed OCSP stapling as a performance optimisation. When viewed from this perspective, it's not necessary to staple 100% correctly; if you don't, clients just go to the CA directly. Unfortunately, this breaks apart with must-staple and clients who refuse to talk to Cash for privacy reasons.
Browsers refused to enforce must-staple because that would mean broken web sites and they didn't want to be blamed for it. As a result, web servers didn't have an incentive to fix their broken OCSP stapling implementations.
There's also some politics involved. Browsers don't actually want CAs to be able to revoke certificates for reasons other than security. Think one government pressuring a CA in their country to revoke a certificate of an entity outside the country, for political reasons.
(EDIT I don't really support this argument. Any organisation that cares about their availability should always have two active certificates from difference CAs. There's a variety of CA jurisdictions to choose from as well.)
I don't like these long discussion chains as much as the next guy, but there's a lot of nuance and history when it comes to certificate revocation, and I sometimes take the opportunity to gently question people's beliefs. The line "revocation doesn't work" is very often repeated and technically it's not wrong, but I think it's important for people to understand how we got here.
CRL/OCSP (which are the only revocation mechanisms close to being generally used standards today) require either online verification (which is unsuitable or unsafe for many applications) or CRL distribution with CA trust root bundles, which is always in danger of being stale.
You can read more in https://en.wikipedia.org/wiki/Certificate_revocation_list#Pr..., https://en.wikipedia.org/wiki/Online_Certificate_Status_Prot...
Revocation in PKI is a hard problem that exposes a fundamental tradeoff between time to revoke and privacy/offline capability.
There is a variety of signature standards and protocols out there that rely on PKI to manage trust, and whose users are not at all keen on calling an untrusted URL to check an intermediate cert.
Out of curiosity, what without-TLS use cases do you have in mind?
Even if you think all SSO will migrate to OIDC, the EU has enacted laws around electronic signatures that basically enshrine the use of XML Signature (with all its problems) for the foreseeable future. A lot of countries beyond the EU (many LatAm countries, for example) have followed suit.
There are other signature protocols that use certificate chains as well, and devices and networks that should not be making network calls when validating such signatures.
And as I mentioned, TLS uses are not limited to those where revocation information is readily accessible.