X.509 certificate revocation is structurally broken: CRLs lag by days, OCSP has privacy and reliability problems, and no fix has full deployment.
Key Takeaways
CRLs list all unexpired revoked serial numbers; the example Let’s Encrypt CRL had a 9-day window where relying parties could remain unaware of a revocation.
OCSP stapling shifts status delivery to the server, but servers can omit it and clients must decide whether to hard-fail or soft-fail on missing responses.
Mozilla’s CRLite compresses a 6.7GB full CRL dataset into a 1.3MB Bloom filter; delta updates on a 6-hour interval run roughly 60kB each.
Let’s Encrypt is shortening cert lifetimes further in May 2026, which reduces revocation exposure windows but increases issuance and renewal churn.
DANE (RFC 6698) could replace CA-based revocation by anchoring cert identity in DNS, but requires DNSSEC, which remains sparsely deployed.
Hacker News Comment Review
Commenters pushed back on the claim that CRLs must grow large: Entrust’s original design used issuing distribution points so each CRL shard stayed small even at CA scale.
There is consensus that DANE is the cleanest architectural fix but DNSSEC adoption is the real blocker, not CA industry resistance alone.
One commenter flagged the article’s structure as circular and noted a conceptual confusion around why OCSP status decisions are deferred to clients rather than servers terminating bad sessions directly.
Notable Comments
@bblb: “DNS and PKI. Two of the most centralized services in the Internet. Take over both of them, and you have the whole net under your command.”
@Parodper: Points out the irony that X.509 revocation problems are being solved via DNS, a substitute for X.500 – the directory system X.509 was originally designed to work with.
