Post-quantum signatures don’t fail because they’re insecure. They fail because they’re enormous, and the entire web PKI was quietly built on the assumption that signatures are small. Pull that assumption out and a surprising number of things tip over at once.
The Byte Size Problem
Start with the raw numbers, because the gap is not subtle. A classical ECDSA P-256 signature is 64 bytes raw, roughly 72 once DER-encoded on the wire, and its public key is 65 bytes uncompressed. The post-quantum replacements are an order of magnitude larger:
| Scheme | Public key | Signature | Security category |
|---|---|---|---|
| ECDSA P-256 (classical) | ~65 B | ~64 B raw / ~72 B DER | n/a |
| ML-DSA-44 | 1,312 B | 2,420 B | 2 |
| ML-DSA-65 | 1,952 B | 3,309 B | 3 |
| ML-DSA-87 | 2,592 B | 4,627 B | 5 |
| SLH-DSA (128f) | 32 B | 17,088 B | 1 |
Sizes per FIPS 204 and FIPS 205 [1][2]
A single ML-DSA-65 signature is roughly fifty times an ECDSA signature, and SLH-DSA, the hash-based option you reach for when you don’t trust lattices, is measured in tens of kilobytes. FN-DSA (FIPS 206, not yet finalized) gets signatures back down near 700 bytes, but it pays for that with floating-point sampling that is notoriously hard to implement in constant time and has produced side-channel bugs in multiple libraries, so it is not the easy escape it looks like.
Now multiply. A TLS handshake doesn’t carry one signature, it carries several: the server’s CertificateVerify, plus the signatures binding the chain together. A normal chain with a leaf and an intermediate already has two X.509 signatures in it before the handshake signature [3].
Embedded SCTs carry CT log signatures of their own, typically two per certificate, so the transparency stamps inflate along with everything else. Swap every one of those from ~64 bytes to a few kilobytes and the authentication portion of the handshake balloons from a few hundred bytes to ten kilobytes or more, on every connection, much of it in the first round trip where it does the most damage to latency.
That weight lands hardest on the part of the system that was already the weakest: revocation. The industry spent 2025 walking away from live revocation checking. Let’s Encrypt shut down its OCSP responders on August 6, 2025, having dropped OCSP URLs from certificates that May [4]. At peak it was answering roughly 340 billion OCSP requests a month, about 140,000 per second [4], and it decided that cost and the privacy leak of telling a CA every site you visit were both no longer worth carrying.
What replaces OCSP is CRLs, but not the old download-the-list model. The modern approach has browser vendors continuously ingest every CA’s CRLs and ship compressed revocation sets to clients, the CRLite lineage. That works, but it assumes the revocation data stays a manageable size, and post-quantum signatures push in the opposite direction.
Two Ways to Stay Calm, and Why Neither Holds
Certificate Transparency is where the compounding becomes a real bandwidth problem. Every publicly trusted certificate is logged, and browsers expect proof of logging. As of mid-2025 there were on the order of 2.1 billion unexpired certificates across CT logs, with a single CA accounting for around 558 million active certificates [5]. Three forces now push on that number at once. The 47-day regime from article three multiplies how often each certificate is reissued. Post-quantum signatures multiply the bytes in each logged entry. CT logging requires all of it to be proven, on top of both.
Short-lived certificates are often pitched as the answer to revocation, and they genuinely help, a certificate that lives six days barely needs revoking, which is the cleanest substitute we have. But shortening lifetimes increases issuance volume, which increases what the transparency apparatus has to absorb, at exactly the moment each entry is getting bigger. The revocation fix makes the size problem worse.
There are two respectable arguments for staying calm about all of this. Defer. Unlike key exchange, signatures have no retroactive failure mode. An adversary who records encrypted traffic today can decrypt it the day a sufficiently large quantum computer exists, but a signature forged years from now authenticates nothing that already happened, so authentication only needs to be quantum-safe once the machine is real. The June 2026 US executive order encodes exactly this staging, key establishment migrated by end of 2030 and signatures a year behind [7].
Go incremental. TLS certificate compression (RFC 8879) and abridged chains that predistribute the common intermediate set claw back real bytes with no new trust machinery at all. Both arguments are correct, and neither closes the gap. Compression cannot shrink the signatures themselves, they are randomness and randomness does not compress.
And the deferral argument quietly assumes the signature migration is gated on algorithms, when it is actually gated on infrastructure: root program churn, CT log capacity, and issuance tooling allsmove on decade timescales. Waiting for the machine before restructuring the PKI means scheduling the slowest part of the migration last.
This is the corner the web PKI has painted itself into, and it is why Merkle Tree Certificates exist. The core move is to stop putting a per-certificate signature on the wire at all:
- Issuance log. A Merkle Tree CA appends everything it issues to an append-only log, in the style of a CT log, and signs checkpoints of that log rather than individual certificates.
- Predistribution. Subtrees anchored at periodic landmarks are pushed to relying parties through a transparency service, so an up-to-date client already trusts the tree before the handshake starts.
- The certificate. What the server sends is effectively a signatureless inclusion proof that the leaf sits under a landmark subtree the client already trusts, scaling logarithmically with subtree size instead of carrying a multi-kilobyte signature [5].
- Negotiation. The relying party advertises its trusted subtrees as trust anchors; a matching server sends the compact Merkle form, otherwise it silently falls back to a normal X.509 chain [5][6].
- Revocation. A relying party can mark revoked ranges of log indices, so even unknown entries can be revoked in bulk [5].
What’s Still Unsettled
It is also the contested part. A mechanism that lets relying parties advertise arbitrary trust sets makes trust-store divergence cheap, and the trust-expressions lineage this grew out of took sustained fire in the TLS working group on exactly that ground: easy trust negotiation is also easy deployment of government-mandated roots, a concern that should sound familiar from the eIDAS discussion earlier in this series. Trust Anchor Identifiers was reshaped partly in response, and that argument is not settled. The signature blowup, the revocation load, and the CT volume all get answered by the same structural change, which is the sign that the structure, not the algorithm, was the real problem.
Merkle Tree Certificates (MTC) are not some exotic side quest, it’s what the size math forces once short-lived certs, post-quantum signatures, and transparency logs all turn up to the same handshake. Where it goes from here is being argued out in the IETF right now, which is the most honest place to leave it. The proposal has moved from an individual draft into the PLANTS working group as draft-ietf-plants-merkle-tree-certs [5], and it leans on the trust-anchor negotiation being standardized in draft-ietf-tls-trust-anchor-ids [6]. Three fights are still open:
- Scope: whether this stays a web-PKI mechanism with browser-distributed trust or generalizes beyond it.
- Governance: how the transparency and mirror infrastructure gets run, and by whom.
- Naming: whether the certificate type ever gets a real name or ships as the Bikeshed Certificate the drafts still call it.
Closing Down This Series, Not the Discussion
To circle our wagons and back to our horse analogy, Ballot, Reckoning, and Sunset all have our dates on them because someone filed some paperwork. The pale horse still doesn’t, and it never will until the day it arrives. That is not a reason to wait for it. Discovery, automation, multi-CA sourcing, the standards you’re bound by, the PQC sequencing, and now the structural rebuild revocation and signatures both need: none of it was ever seven separate problems. It was one migration wearing seven deadlines, and the only version of this that goes badly is the one where each part gets planned in isolation, on its own clock, by different teams that never talk to the others. Somewhere in there, our interns are still renewing OV certs by hand.
This is where the next two years of this story actually get written. And where ours ends.
Happy PKI’ing! 
References
[1] National Institute of Standards and Technology. FIPS 204, Module-Lattice-Based Digital Signature Standard (ML-DSA), August 2024. Parameter sizes: ML-DSA-44 (pk 1,312 / sig 2,420), ML-DSA-65 (pk 1,952 / sig 3,309), ML-DSA-87 (pk 2,592 / sig 4,627); security categories 2, 3, and 5 respectively.
[2] National Institute of Standards and Technology. FIPS 205, Stateless Hash-Based Digital Signature Standard (SLH-DSA), August 2024. SLH-DSA-128f signature 17,088 bytes (~17 KB); security category 1.
[3] draft-ietf-plants-merkle-tree-certs and predecessor draft-davidben-tls-merkle-tree-certs
[4] Let’s Encrypt. “OCSP Service Has Reached End of Life,” August 6, 2025. Peak OCSP load ~340 billion requests/month, more than 140,000 requests/second at the CDN, ~15,000/second at origin. OCSP URLs removed from certificates May 7, 2025 per “Ending OCSP Support in 2025,” December 5, 2024.
[5] draft-ietf-plants-merkle-tree-certs (PLANTS WG; -04, May 2026). Append-only issuance log with signed checkpoints, predistributed landmark subtrees, signatureless inclusion-proof certificates, revoked-index ranges. Issuance-rate estimates in Section 6.4 (data as of June 9, 2025): ~2.1 billion unexpired certificates across CT logs and ~444,000 certificates/hour issuance (MerkleTown); ~558 million active certificates for a single CA (Let’s Encrypt).
[6] draft-ietf-tls-trust-anchor-ids (TLS WG; -04, May 2026; formerly draft-beck-tls-trust-anchor-ids). Trust-anchor negotiation MTC relies on for certificate selection and X.509 fallback.
[7] Executive Order 14412, “Securing the Nation Against Advanced Cryptographic Attacks,” June 22, 2026. Key-establishment migration by end-2030, digital-signature migration by end-2031.