It's not surprising that TLS clients won't be making OCSP requests in the future. People thought that was a terrible idea from the beginning, for privacy reasons and non-scalability among other things, and many clients never even implemented it.

It may seem a little strange that stapling, which didn't suffer from those obvious problems, is also going away. The comments on the Hacker News story have some detail from people involved with Let's Encrypt. Basically, with upward of 200 million active certificates, the back-end work to sign that many responses every few days (OCSP response lifetime generally being a week) is more significant than handling the clients, who'd essentially be fetching static data. Although Let's Encrypt already plans to issue less-than-90-day certificates, which seems even more involved than OCSP: every new certificate needs to be added to the issuer's database and the public certificate-transparency logs.

What's really surprising is that certificate revocation lists (CRLs) are slated to be the replacement. Firefox deprecated those a decade ago, and I think most software never implemented them. It'd be annoying to wget a several-kilobyte file and have to wait for megabytes of CRL data first, for example, and we've already seen instances in which certificate authorities decided against revocation because the risk wasn't worth bloating their CRLs. And, yet, CRLs are apparently coming back, with no improvements whatsoever.

I'm kind of baffled by this. Obviously, each program fetching CRLs itself is duplicative and inconvenient. Particularly with programs too sandboxed to store them anywhere, or that run infrequently enough (like my "banking" browser profiles) that they'd always have outdated data. There probably should've been some years of warning that CRLs would return, during which maybe someone could've written a system/network service to fetch the lists and run an OCSP-like service for their TLS clients to check.

I think the main innovation has been the browser summarized CRLs as CRLite or CRLSets: https://letsencrypt.org/2022/09/07/new-life-for-crls.html#browser-summarized-crls

Presumably other programs would pull the same summarized CRLs, or the OS would share one like it shares the CA trust store.

seankhliao, thanks for the links, but...

Presumably other programs would pull the same summarized CRLs

Reducing the amount of data mitigates one problem, but leaves many others. If nothing else, most programs don't have code to update or use CRLs of any kind, which makes this a rather optimistic presumption.

While a library could theoretically do this "behind the scenes", it's kind of problematic to have libraries unexpectedly spawning threads, making network connections, and updating shared databases; and it runs into similar problems as un-stapled OCSP, like "what if the certificate looks valid but we couldn't fetch the latest CRL?"

The linked page mentions that Firefox might be pushing updates every 6 hours, but doesn't address that last question. What if I turn my computer off on Friday, then come back on Monday and start making HTTPS connections? Should they be blocked till the weekend's CRL updates have come in? Probably everyone would hate that, but it'd be an obvious security hole to not do it. The nice thing about OCSP stapling was that we'd "automatically" get recent lack-of-revocation confirmation, specific to each connection we initiated.

or the OS would share one like it shares the CA trust store.

It'd have to be updated daily to get the same benefit as OCSP. It could be done, but I don't know of any plan to do it, nor any OS package that updates with such frequency.

The shrunken lists seem like more of an idea than a plan, and the wording of "One possible solution that has been making headway recently" is consistent with that.