It's recently struck me that one of the things limiting the evolution of what is called Web PKI, the general infrastructure of TLS on the web (cf), is that it has turned out that in practice, almost anything that requires (code) changes to web servers is a non-starter. This is handily illustrated by the fate of OCSP Stapling.

One way to make Web PKI better is to make certificate revocation work better, which is to say more or less at all. The Online Certificate Status Protocol (OCSP) would allow browsers to immediately check if a certificate was revoked, but there are a huge raft of problems with that. The only practical way to deploy it is with OCSP Stapling, where web servers would include a proof from the Certificate Authority that their TLS certificate hadn't been revoked as of some recent time. However, to deploy OCSP Stapling, web servers and the environment around them needed to be updated to obtain OCSP responses from the CA and then include these responses as additional elements in the TLS handshake.

Before I started writing this entry I was going to say that OCSP Stapling is notable by its absence, but this is not quite true. Using the test on this OpenSSL cookbook page suggests that a collection of major websites include stapled OCSP responses but also that at least as many major websites don't, including high profile destinations that you've certainly heard of. Such extremely partial adoption of OCSP Stapling makes it relatively useless in practice, because it means that no web client or Certificate Authority can feasibly require it (a CA can issue certificates that require OCSP Stapling).

There are perfectly good reasons for this inertia in web server behavior. New code takes time to be written, released, become common in deployed versions of web server software, fixed, improved, released again, deployed again, and even then it often requires being activated through configuration changes. At any given time, most of the web servers in the world are running older code, sometimes very older code. Most people don't change their web server configuration (or their web server) unless they have to, and also they generally don't immediately adopt new things that may not work.

(By contrast, browsers are much easier to change; there are only a few sources of major browsers, and they can generally push out changes instead of having to wait for people to pull them in. It's relatively easy to get pretty high usage of some new thing in six months or a year, or even sooner if a few groups decide.)

The practical result of this is that any improvement to Web PKI that requires web server changes is relatively unlikely to happen, and definitely isn't going to happen any time soon. The more you can hide things behind TLS libraries, the better, because then hopefully only the TLS libraries have to change (if they maintain API compatibility). But even TLS libraries mostly get updated passively, when people update operating system versions and the like.

(People can be partially persuaded to make some web server changes because they're stylish or cool, such as HTTP/2 and HTTP/3 support. But even then the code needs to get out into the world, and lots of people won't make the changes immediately or even at all.)