Merkle Tree Certificates explained

Part 4 of 5 in TLS in 2026. Last week, the post-quantum migration ended on a cliff: key exchange is basically solved, but post-quantum certificate signatures are too big to ship — kilobytes added to every handshake. This week, the leading idea for fixing that without melting performance.

Post-quantum signatures have a brutal size problem. A single ML-DSA-44 signature is about 2,420 bytes, against roughly 64 bytes for the ECDSA signatures securing certificates today. Now stack up how many signatures ride in one TLS handshake — the leaf certificate’s, the intermediate’s, and the two or three Certificate Transparency proofs that are themselves signatures — and a naive post-quantum swap adds many kilobytes to the most latency-sensitive moment of the connection.

You can’t make a post-quantum signature meaningfully smaller; the math doesn’t allow it. So the people working on this stopped trying to shrink the numbers and changed the structure instead. The result is Merkle Tree Certificates (MTC), and the core trick is one you already trust every time you use Git or pull a container image: a Merkle tree.

What a certificate costs today

A quick grounding, because MTC replaces two things at once. When you load a page over HTTPS today, the server hands over:

• A leaf certificate carrying the CA’s signature over your domain and key.
• One or more intermediate certificates, each signed in turn, chaining up to a trusted root.
• A handful of Signed Certificate Timestamps (SCTs) — Certificate Transparency’s proof that the certificate was publicly logged. Each SCT is a signature from a log.

Every one of those is a signature, and in a post-quantum world every one of them balloons. CT is the quiet multiplier here: it was bolted onto the web PKI as a separate system, and it makes you pay for extra signatures on top of the certificate’s own. MTC’s insight is that the certificate and the transparency log don’t have to be separate systems paying separate signature costs. Fold them together and you can authenticate thousands of certificates with a single signature.

The core idea: sign the forest, not the trees

Instead of the CA signing each certificate individually, MTC has it collect a large batch of certificate assertions over a time window, build a Merkle tree over the whole batch, and sign one root. That single signature authenticates every certificate in the batch at once.

                Root  ◀── ONE signature for the whole batch
               /    \         (amortized over thousands of certs)
           H(0,1)    H(2,3)
           /   \      /   \
        H(c0) H(c1) H(c2) H(c3)
          │     │     │     │
        cert0 cert1 cert2 cert3
                ▲
        your certificate lives at one leaf

A Merkle tree hashes pairs of nodes upward until everything collapses into a single root hash. The magic property: you can prove a given leaf is in the tree by revealing only the sibling hashes along the path from that leaf to the root — not the whole tree. That short list of hashes is an inclusion proof.

For cert1 above, the proof is just [H(c0), H(2,3)]. A relying party that already knows the trusted root recomputes the path — hash cert1, combine with H(c0) to get H(0,1), combine with H(2,3) to get the root — and checks it matches. If it does, cert1 is provably in a batch the CA signed. No per-certificate signature was verified, or even transmitted. The server presents the certificate assertion plus that little stack of hashes, and that’s the whole authentication.

Why it’s so much smaller

The size win comes from two compounding facts. First, an inclusion proof grows with the logarithm of the batch size: doubling the number of certificates in a batch adds exactly one hash to every proof. A batch of a million certificates needs only ~20 hashes per proof. Second, hashes are tiny and already quantum-resistant — about 32 bytes each — so a 20-hash proof is roughly 640 bytes, no signature in sight.

Post-quantum X.509 + CT	Merkle Tree Certificate
One big PQ signature per certificate	One signature amortized over a whole batch
Separate SCTs (more PQ signatures) for CT	Transparency built into the tree — no extra signatures
Kilobytes added to every handshake	A few hundred bytes of hashes per proof
Proof size fixed and large	Proof size grows only logarithmically with batch size

Transparency comes for free

There’s a second prize here beyond size. Certificate Transparency exists so that mis-issued certificates can’t hide — every certificate must appear in a public, append-only log, and SCTs are the receipts. MTC gets this property structurally instead of bolting it on. The batch tree is a public log: it’s append-only by construction, anyone can monitor it, and a certificate’s very inclusion proof is also its proof of public logging. One mechanism delivers both authentication and transparency, which is exactly why the IETF working group standardizing this is named PLANTS — “PKI, Logs, And Tree Signatures.” The logging isn’t a separate system anymore; it’s the same tree.

This is also what makes the design genuinely new rather than just a compression trick. It rethinks the relationship between a certificate, its signature, and its transparency record — three things the current web PKI treats as separate and separately expensive.

Walking the lifecycle

It helps to trace one certificate through the system end to end, because the flow explains several of the constraints that follow:

1. Request. A subscriber proves domain control and asks for a certificate, the same as ACME today.
2. Batch. Rather than signing immediately, the issuer adds the assertion to the current batch and waits for the batch window to close. (This is the first tradeoff: issuance isn’t instant — you wait for the batch.)
3. Seal. When the window closes, the issuer builds the Merkle tree over every assertion in the batch, computes the root, signs it once, and publishes the tree so anyone can monitor it.
4. Deliver. The subscriber receives its certificate plus the inclusion proof — the sibling hashes connecting its leaf to that signed root.
5. Present. At TLS time the server sends the assertion and the proof. The relying party, already holding the trusted root for that batch, recomputes the path and accepts — no signature verified on the hot path.
6. Expire. The certificate is short-lived; renewal means landing in a future batch and getting a fresh proof. There’s no revocation dance — expiry does the work, exactly as the rest of this series argued it should.

The shape of this should look familiar: it’s the automated, short-lived, high-volume certificate lifecycle from the first three posts, with the per-cert signature replaced by a per-batch one.

What it is not

MTC is elegant, but it is not a drop-in replacement for X.509, and it’s important to be clear-eyed about the constraints — most of which flow from one fact: the relying party must already hold the trusted root for the batch your certificate is in.

There are a couple of other costs worth naming. Batching adds issuance latency — you wait for the batch window to close rather than getting a certificate the instant you ask. And the design leans harder on the issuer/transparency service as critical infrastructure: more of the trust model concentrates in the batch-publishing and tree-head-distribution machinery, which has to be highly available and well-monitored. These are engineering problems, not dealbreakers, but they’re the kind of operational detail that decides whether a clever design survives contact with production.

Because of that, MTC is designed as a complement to X.509, not a wholesale replacement. In practice a server holds both: it presents a compact Merkle Tree Certificate to clients that can use one, and falls back to a traditional X.509 certificate for everyone else, negotiated within the TLS handshake. Nobody is proposing to delete X.509; the proposal is to take the enormous volume of automated, short-lived, high-churn certificates — exactly the 47-day, ACME-driven world the first half of this series described — and serve it far more cheaply, while leaving the long tail on the classic path.

Seen that way, the pieces of this series snap together. MTC practically requires the world of automated renewal and short lifetimes to function, and it exists to solve the post-quantum signature bloat that world would otherwise hit. Short-lived certificates aren’t just compatible with MTC; they’re the precondition for it.

Where it stands

This is real, funded, in-progress standards work — and still very much a moving target. The concept began as an individual draft from David Benjamin (Google) and Bas Westerbaan (Cloudflare) and has since been adopted by the IETF’s PLANTS working group as draft-ietf-plants-merkle-tree-certs. On the deployment side, Let’s Encrypt’s June 2026 roadmap selects Merkle Tree Certificates for a staging rollout — a strong signal that the largest issuer on the web sees this as the path, not a thought experiment.

Next week

Across these four posts one theme keeps surfacing no matter which way the technology breaks: certificates now change constantly — shorter lifetimes, automated renewal, new cryptography, and soon new certificate shapes entirely. Whatever the cert looks like, it’s rotating faster than your monitoring was built for. The series finale tackles exactly that: how to monitor certificates in a world where they rotate every week.