Yes, agreed on the primary problem with "classic" OCSP. OCSP stapling and must-staple (for the benefit of other readers: a flag that's set on a certificate to i

Yes, agreed on the primary problem with "classic" OCSP. OCSP stapling and must-staple (for the benefit of other readers: a flag that's set on a certificate to indicate that it's only valid with an attached—stapled—fresh OCSP response) solves that. 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.