Revocation#

Geoff Huston - APNIC

• Why: Directly in the PM's identity/authentication core. PKI revocation assumptions underpin everything from Web TLS to workload identity — and this talk empirically shows revocation does not work in practice.
• What: A live experiment: generate a Let's Encrypt certificate, revoke it, wait weeks, and check browsers. Only Firefox had learned of the revocation; Chrome (which disabled OCSP in 2012 and never supported Must-Staple) and Safari (CRLset-style downloads plus stapled OCSP) did not. The talk walks the whole failure chain: CRLs are too large and weekly-fresh (a DigiCert example with 17,527 entries); OCSP adds latency, leaks client activity to the CA, concentrated load (Akamai once answered ⅔ of Let's Encrypt OCSP), and forces fail-open (DDoS vector) or fail-closed (availability vector) choices; stapling adds nothing because a server holding a revoked cert would never staple its own revocation. Conclusion: revocation is unfixable within X.509 — shorter cert lifetimes bound the damage but CA infrastructure can't scale to hour-long lifetimes. The provocative alternative: DANE — put DNSSEC-signed public keys in the DNS with TTL-scale freshness and staple the DNSSEC chain into the TLS handshake, eliminating the CA third party entirely.
• How: Demonstration-first methodology (generate/revoke/wait/check across Chrome, Safari, Firefox), plus a structural analysis of CRL/OCSP/stapling mechanics.
• Where applicable: Universal for anyone depending on Web PKI or designing certificate-based workload/agent identity. The DANE proposal is contrarian and has no browser support — treat it as direction-setting, not deployable. Highly relevant to short-lived-certificate designs (SPIFFE-style) where "we'll just revoke" is a non-answer.