The problem with requiring OCSP stapling is that it's not practically enforceable without breakage.

The underlying dynamics of any change to the Web ecosystem is that it has to be incrementally deployable, in the sense that when element A changes it doesn't experience breakage with the existing ecosystem. At present, approximately no Web servers do OCSP stapling, so any browser which requires it will just not work. In the past, when browsers want to make changes like this, they have had to give years of warning and then they can only actually make the change once nearly the entire ecosystem has switched and so you have minimal breakage. This is a huge effort an only worth doing when you have a real problem.

As a reference point, it took something like 7 years to disable SHA-1 in browsers [0], and that was an easier problem because (1) CAs were already transitioning (2) it didn't require any change to the servers, unlike OCSP stapling which requires them to regularly fetch OCSP responses [1] and (3) there was a clear security reason to make the change. By contrast, with Firefox's introduction of CRLite, all the major browsers now have some central revocation system, which works today as opposed to years from now and doesn't require any change to the servers.

[0] https://security.googleblog.com/2014/09/gradually-sunsetting... [1] As an aside it's not clear that OCSP stapling is better than short-lived certs.

I think you are correct. There were similar issues with Firefox rolling out SameSite=Lax by default, and I think those plans are now indefinitely on hold as a result of the breakage it caused. It's a hard problem to solve.

> As an aside it's not clear that OCSP stapling is better than short-lived certs.

I agree this should be the end goal, really.

> The underlying dynamics of any change to the Web ecosystem is that it has to be incrementally deployable, in the sense that when element A changes it doesn't experience breakage with the existing ecosystem.

Absolutely, this is important.

But I don't understand why this should have any effect on OCSP-stapling vs. CRL.

As you note, "approximately no Web servers do OCSP stapling, so any browser which requires it will just not work." But browsers also cannot rely on CRLs being 100% available and up-to-date.

Enforcing OCSP stapling and enforcing a check against an up-to-date CRL would both require this kind of incremental or iterative deployment.

> As an aside it's not clear that OCSP stapling is better than short-lived certs.

This is equally applicable to CRL, though.

The current plan for phased reduction of TLS cert lifespan is to stabilize at 47 days in 2029. If reducing cert lifetime achieves the goal of reducing the value of compromised certs, then any mechanism for revoking/invalidating certificates will be reduced in value.