A First Look at Certificate Revocation Latency#

Authors: Nehal Fooda (University of Maryland), James Larisch (Cloudflare), John Schanck (Mozilla), Bruce Maggs (Duke University and Emerald Innovations), Tijay Chung (Virginia Tech), Dave Levin (University of Maryland)

• Why: Revocation is the last line of defense after key compromise, and the entire chain has been measured except one leg: how long a CA takes to turn a revocation request into publicly downloadable revocation data. If you run incident response for key compromise, that leg determines your real remediation window.
• What: The first study of CA-side revocation-data publication latency, covering six of the most popular CAs across both CRL and OCSP, plus end-to-end latency through to Mozilla Firefox's CRLite. Headline: CAs generally operate on tighter bounds than the CA/B Baseline Requirements strictly require, but some major CAs still show up to 24-hour delays from request to availability. (from abstract only)
• How: A custom tool that requests revocations and polls/downloads the resulting revocation state, varying time of day, distribution mechanism (CRL vs OCSP), reason code, and other factors; separately measures end-to-end propagation into CRLite.
• Where applicable: Web PKI broadly — relevant to incident-response playbooks (what "revoked" actually means hour-by-hour), and to CA/BR policy work. The CRLite end-to-end numbers are Firefox-specific.