codexproof

glossary / CRL and OCSP (the cautionary ancestors)

WebPKI's two revocation mechanisms - periodically published revocation lists, and an online status-checking protocol - both effectively neutered in practice because browsers treat their failure as ignorable.

srlc2pa
CRL and OCSP (the cautionary ancestors) - The soft-fail flow, step by step, ending in the shrug that killed web revocation

The soft-fail flow, step by step, ending in the shrug that killed web revocation.

Etymology and backstory

CRLs shipped with X.509; OCSP (RFC 6960) was the 1990s answer to CRLs growing huge - ask the CA about one certificate in real time. Then reality: OCSP responders go down, add latency, and leak browsing history to CAs, so browsers made failures SOFT - unreachable responder, proceed anyway. Measurement studies (notably Liu et al., IMC 2015) documented the result: revocation on the web mostly does not work. Chrome ships curated CRLSets; Firefox built CRLite; OCSP stapling patched the privacy leak; the saga continues.

Ecosystem

the whole WebPKI revocation literature - the best-documented case study of availability pressure hollowing out a security control.

In codexproof

the named anti-pattern. The SRL design inverts every soft choice: mandatory freshness, whole-set signing, monotone versions, and fail-closed consumers. Q21's line: PKI with the CAs deleted and the one part everyone soft-fails made mandatory.

"The web taught us exactly how revocation dies - it dies of optional - so we made it the one thing a verifier is never allowed to skip."
References: RFC 6960, OCSP (2013). Liu et al., "An End-to-End Measurement of Certificate Revocation in the Web's PKI," ACM IMC (2015). Larisch et al., CRLite, IEEE S&P (2017).

All terms · Questions & answers · The verifier