We build X.509 chains so you don't have to

yes, hence my comment on SML

while it's nice that the rest of the world is slowly waking up to type systems functional programmers have been bleating on about for the past four decades

... having read through the first couple of pages of bc vulns: even a much stronger type system than rust provides wouldn't appear to help very much in this specific example

however if someone wants to rewrite OpenSSL in Rust that would be a massive massive improvement

Sure! I'm happy to discuss, my reason for referencing the video is because I think 'mcpherrim explains this stuff better than I do :-).

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.

Most SSO runs on SAML, which uses XML Signature, which uses PKI certificate chains without TLS.

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.

"The spiral of non-adoption" is an interesting blog post someone should write. I bet there are a couple more examples besides the obvious one.

I think you're right about CRLSets. IMO, Mozilla really wanted to solve the problem, whereas Chrome just wanted to have a solution that they could use for emergency revocation of certificates of high-profile sites (and intermediates/roots). Small-time sites won't be in CRLSets, although if you know the right people and make enough noise you may be added to their list. As for Apple, no one knows what's going on because they don't like to share :)

OCSP must-staple doesn't require code changes. It's a "flag" you set on a certificate. Maybe what you mean is that OCSP stapling is not enabled by default on many installations, and that's true. IIS got it right, and Caddy (obviously, the only platform that got everything right).

Again, we're in this place only because browsers don't care about revocation. If they pushed for it, things would fall into place very quickly. But they're going in the opposite direction.

Short-lived certificates are great, assuming you're fine with a 3.5 day (on average) window of opportunity for exploitation. There's a potentially major problem with clock skew, as many clients have inaccurate clocks. Personally, I recommend that certificates are obtained at least a week before they're deployed; a month would be better. Then rotated a month before they expire. That's how you minimise the problems due to clock skew.