up:: In the Protocols MOC

Merkle Tree Certificates (MTC)

Merkle Tree Certificates (MTC) are an emerging IETF proposal to make post-quantum web PKI affordable at internet scale by changing how a certificate proves itself. Instead of sending a chain of post-quantum signatures on every TLS connection, a certificate authority periodically batches many certificates into a Merkle tree and signs only the tree’s root. Each server then presents a short Merkle inclusion proof, a chain of sibling hashes, that ties its certificate back to a root the browser already holds, obtained ahead of time through a background update rather than over the connection. The design is under active development in the IETF PLANTS working group and is being trialed by Google Chrome and Cloudflare, and it rests on a sharp thesis, that for web PKI the binding problem in the quantum transition is scale and bandwidth, not the algorithm.

The short version:

1. Post-quantum signatures are roughly 20 times larger than the elliptic-curve ones they replace, so a post-quantum certificate chain balloons a TLS handshake from a few hundred bytes of authentication data to well over 10,000 bytes.
2. Merkle Tree Certificates cut that by having a CA sign one Merkle tree root over millions of certificates, then shipping each certificate as a compact inclusion proof against that root instead of as its own signature.
3. An optional signatureless mode carries no signatures at all, just a 736-byte proof of 23 hashes, which is smaller than a single post-quantum signature.
4. The trust anchor, called a tree head, reaches the browser out of band through a predistributed list, so it is not paid for on the wire the way a signature chain is.
5. It stays honest about its limits, the browser must be reasonably up to date (certificates live about a week), and a server keeps a full classical fallback certificate for clients that are behind.
6. It is a proposal under experimentation, not a finalized standard, so it belongs in a migration plan as a thing to watch and pilot, not yet a thing to depend on.

Picture a huge stadium where every ticket holder needs to prove their seat is legitimate. The slow way is for each person to carry a letter individually signed and notarized by the box office, and with post-quantum notary stamps those letters are enormous, so the turnstiles crawl.

Merkle Tree Certificates change the arrangement. Once an hour the box office publishes a single sealed summary of every valid ticket sold that hour and posts it at the gate ahead of time. Now each ticket holder just carries a short receipt showing their ticket folds into that hour’s summary. The guard already trusts the posted summary, so the check is a quick fold-up-and-compare rather than reading a giant notarized letter every time. The tickets are the certificates, the hourly summary is the signed tree head, and the short receipt is the inclusion proof.

What is a Merkle Tree Certificate?

A Merkle Tree Certificate is a certificate whose authenticity is proven by a Merkle inclusion proof against a signed tree root, rather than by a signature carried on the certificate itself. The CA collects the certificates it issues over a short window, arranges them as the leaves of a Merkle tree, and produces a single signed value, the tree head, that commits to all of them at once. A server’s certificate then travels with the sibling hashes needed to recompute the tree root from its own leaf, and a browser that already trusts that tree head accepts the certificate the moment the recomputed root matches.

The design also integrates public logging directly into issuance. Classical web PKI bolts Certificate Transparency on afterward, having each certificate carry Signed Certificate Timestamps (SCTs) that prove it was submitted to public logs, and in a post-quantum world each of those SCTs carries its own large signature. Merkle Tree Certificates fold the logging into the same tree, so the inclusion proof simultaneously proves the certificate exists, is genuine, and was publicly logged, without separate SCT signatures riding along.

Source: D. Benjamin, D. O’Brien, B. Westerbaan, “Merkle Tree Certificates,” draft-ietf-plants-merkle-tree-certs-05, IETF PLANTS working group, July 6 2026, datatracker.ietf.org.

Source: E. Nygren, “Cultivating a robust and efficient quantum-safe HTTPS,” Google Security Blog, February 28 2026, blog.google.

Why do post-quantum signatures break web PKI at scale?

Because the standardized post-quantum signatures are far larger than the elliptic-curve signatures they replace, and a TLS handshake pays that cost several times over on every single connection. This is the whole reason Merkle Tree Certificates exist, so it is worth seeing the sizes plainly. An ECDSA-P256 signature is 64 bytes and its public key is 64 bytes. The general-purpose post-quantum replacement, ML-DSA at its smallest parameter set (ML-DSA-44), has a 2,420-byte signature and a 1,312-byte public key, roughly a twentyfold jump.

Now count how many of those a normal handshake sends. A server today typically transmits about 5 signatures and 2 public keys during authentication, the leaf certificate’s signature, the issuing CA’s signature, the SCT signatures that prove public logging, and the handshake signature, plus the leaf and intermediate public keys. Swap every one of those for ML-DSA and the authentication payload climbs from a few hundred bytes to well over 10,000 bytes per connection. The IETF draft measures one slice of this directly, two SCTs plus the leaf signature alone add 7,260 bytes at ML-DSA-44 and 9,927 bytes at ML-DSA-65.

Source: K. Kwiatkowski, B. Westerbaan, “Bootstrapping Merkle Tree Certificates,” Cloudflare Blog, blog.cloudflare.com.

Source: NIST, “Module-Lattice-Based Digital Signature Standard,” FIPS 204, August 2024, table of parameter sizes, csrc.nist.gov.

That bandwidth lands where it hurts most. Bigger handshakes mean more round trips before a page starts loading, more data on constrained mobile links, and oversized TLS messages that trip the middlebox ossification problems the applied-PQC world already fights. The underlying algorithms are sound and standardized, so the obstacle to a quantum-safe web is the logistics of moving all those bytes on every connection, which is a distribution problem rather than a cryptographic one. Merkle Tree Certificates attack exactly that distribution problem.

How does a Merkle Tree Certificate work?

It works in four moves, and the key idea is that the expensive signature is computed once by the CA and amortized across every certificate in a batch:

1. The CA batches and builds a tree. Over a short window, the CA takes every certificate it is issuing and makes each one a leaf of a Merkle tree, hashing upward in pairs to a single root, exactly the structure described in the Merkle Tree note.
2. The CA signs one tree head. Rather than signing each certificate, the CA signs the root, producing a tree head that commits to the whole batch at once. A single post-quantum signature now covers millions of certificates instead of one.
3. The tree head is distributed out of band. Browsers receive a predistributed, periodically updated list of trusted tree heads through a background channel, the same kind of software-update or root-store mechanism that already ships trust anchors, so the tree head is never sent over the TLS connection it protects.
4. The server presents an inclusion proof. On each connection the server sends its certificate plus the sibling hashes tying its leaf to the root. The browser recomputes the root from the leaf and the proof, and if it matches a tree head it already trusts, the certificate is authenticated, with no per-connection signature verification.

The efficiency is the same logarithmic property that makes Merkle proofs useful everywhere, an inclusion proof needs only about log2(n) sibling hashes for a tree of n leaves, so even a tree over millions of certificates yields a proof of a few dozen hashes. Because the trust anchor arrives ahead of time, the connection carries a tiny proof where a classical post-quantum chain would carry a stack of large signatures.

Source: D. Benjamin, D. O’Brien, B. Westerbaan, “Merkle Tree Certificates,” draft-ietf-plants-merkle-tree-certs-05, datatracker.ietf.org.

What is the signatureless optimization, and how small does it get?

The signatureless optimization is a mode that carries no signatures on the wire at all, relying entirely on the browser having already received the trusted tree structure, and it produces the striking size numbers behind the whole proposal. When a relying party is up to date, its certificate is validated purely against predistributed information about which subtrees are trusted, so the server sends only the inclusion proof.

The draft works a concrete case. If a landmark tree size is allocated every hour and certificates live about 7 days, a signatureless subtree spans roughly 4,400,000 certificates, which gives an inclusion proof of 23 hashes, or 736 bytes with SHA-256. Set that against the alternatives, 736 bytes is smaller than a single ML-DSA-44 signature at 2,420 bytes, and almost 10 times smaller than the three ML-DSA-44 signatures a post-quantum SCT arrangement would need. That is how a post-quantum certificate can end up smaller than today’s classical certificate chain, a genuinely counterintuitive result that the whole design is built to deliver.

Source: D. Benjamin, B. Westerbaan, et al., “Merkle Tree Certificates for TLS,” draft-davidben-tls-merkle-tree-certs-09, §on signatureless certificate sizes, ietf.org.

The tradeoff is baked into the name of the mode. A signatureless certificate only works for a relying party that already holds the right trusted subtree, so a server that wants to serve everyone deploys a corresponding full certificate, one that does carry cosigner signatures, alongside the signatureless one, and presents whichever the client can verify.

What is a landmark, and how does a browser get the tree head?

A landmark is a designated tree size that both sides agree to treat as a common reference point, and the tree head at that size is the trust anchor a browser downloads ahead of time. Because the whole scheme depends on the browser trusting the tree without a live signature check, the mechanics of getting the tree head to the browser are the load-bearing part of the design:

1. Landmarks are allocated periodically. The recommended cadence is once per hour, so at each landmark the log has a well-defined size and a corresponding signed tree head that clients can converge on.
2. Tree heads are cosigned and checked for consistency. A relying party obtains assurance that each subtree is consistent with checkpoints observed by a sufficient set of independent cosigners, which is what keeps a single CA from privately rewriting history, the same accountability Certificate Transparency provides.
3. Distribution is out of band. Browsers receive a periodically updated, predistributed list of active landmark subtrees through a background channel such as a component or root-store update, entirely separate from the TLS handshake. Google’s design pairs this with a proposed Chrome Quantum-resistant Root Store (CQRS) built specifically for MTCs.

Source: D. Benjamin, D. O’Brien, B. Westerbaan, “Merkle Tree Certificates,” draft-ietf-plants-merkle-tree-certs-05, datatracker.ietf.org.

Source: E. Nygren, “Cultivating a robust and efficient quantum-safe HTTPS,” Google Security Blog, February 28 2026, blog.google.

What happens when a client is out of date?

The server falls back to a full, traditionally signed certificate, which is the honest answer to the obvious objection that not every browser updates on time. Merkle Tree Certificates are designed to have short lifetimes, about a week, so if a client’s most recent landmark predates that window, the tiny signatureless path stops applying and the connection needs a larger certificate the client can verify on its own.

This is why the current experiments run MTCs with a safety net rather than as a replacement. In the Chrome and Cloudflare feasibility study, every MTC-based connection is backed by a traditional, trusted X.509 Certificate during the trial, so a failure to validate the Merkle path degrades to ordinary web PKI instead of breaking the site. The practical consequence for planning is that MTCs shine for the large population of current, frequently-updated clients and lean on classical certificates for the long tail, which makes them a bandwidth optimization layered on top of the existing system rather than a rip-and-replace of it.

Source: K. Kwiatkowski, B. Westerbaan, “Bootstrapping Merkle Tree Certificates,” Cloudflare Blog, blog.cloudflare.com.

How does an MTC differ from a classical X.509 certificate chain?

The difference is what travels on the wire per connection, and the table below compares a post-quantum X.509 chain against a signatureless MTC. The classical chain re-transmits large signatures every time, while the MTC front-loads one signed tree head out of band and sends a short proof.

What’s transmitted per connection	Post-quantum X.509 chain with CT (ML-DSA-44)	Merkle Tree Certificate (signatureless)
Certificate signatures	Multiple ML-DSA signatures at 2,420 bytes each, sent every connection	None
Proof of public logging	SCTs carrying post-quantum signatures; two SCTs plus the leaf signature add 7,260 bytes	Folded into the inclusion proof, no separate SCT
How authenticity is proven	The chain of signatures itself, verified up to a trusted root each time	A 736-byte Merkle inclusion proof of 23 SHA-256 hashes recomputed against a trusted tree head
Where the trust anchor comes from	Root CA key in the trust store; signatures paid on the wire	Predistributed, hourly-published tree head (landmark), obtained out of band
Net authentication payload	Well over 10,000 bytes once every signature, key, and SCT is counted	About 736 bytes
Works for out-of-date clients	Yes, self-contained	No, needs a full-certificate fallback

Source: D. Benjamin, D. O’Brien, B. Westerbaan, “Merkle Tree Certificates,” draft-ietf-plants-merkle-tree-certs-05, datatracker.ietf.org; NIST, FIPS 204, August 2024, csrc.nist.gov.

The structural point is that an MTC keeps the X.509 world it lives in and changes the economics of proving a certificate, trading a per-connection signature for a per-connection proof plus a predistributed anchor. It sits alongside the other transition bridges like composite certificates, and like all of them it leans on crypto-agility, since a system that can only speak one certificate format cannot adopt a new proving mechanism without being rebuilt first.

What is the status of Merkle Tree Certificates?

Merkle Tree Certificates are an active IETF proposal under experimentation, not a finalized standard, and any plan that references them should treat them that way. The work began as an individual draft, draft-davidben-tls-merkle-tree-certs, authored by David Benjamin of Google, and has since been adopted by the IETF’s PLANTS working group (PKI, Logs, And Tree Signatures) as draft-ietf-plants-merkle-tree-certs, with version 05 published July 6 2026. Adoption by a working group means the idea has enough support to be developed toward a standard, though the specification is still changing between versions.

On the deployment side, Google and Cloudflare are running a phased trial:

1. Phase 1, underway. A feasibility study evaluating the performance and security of TLS connections that rely on MTCs, with Cloudflare running an MTC authority and every MTC connection backed by a traditional X.509 fallback.
2. Phase 2, targeted for Q1 2027. Inviting Certificate Transparency log operators to help bootstrap public MTCs.
3. Phase 3, targeted for Q3 2027. Finalizing requirements for the proposed Chrome Quantum-resistant Root Store, a trust store built to accept MTCs.

Source: D. Benjamin, D. O’Brien, B. Westerbaan, “Merkle Tree Certificates,” draft-ietf-plants-merkle-tree-certs-05, IETF PLANTS working group, July 6 2026, datatracker.ietf.org.

Source: E. Nygren, “Cultivating a robust and efficient quantum-safe HTTPS,” Google Security Blog, February 28 2026, blog.google.

Common misconceptions

1. “Merkle Tree Certificates are a finished standard you can deploy.” They are an IETF working-group draft under active revision and a phased experiment. The concept is promising and backed by major browsers, and it is still moving, so it belongs on a watch-and-pilot list, not a production dependency.
2. “MTCs replace X.509.” They live inside the X.509 and web-PKI world and change how a certificate is proven, from a carried signature to a Merkle proof against a distributed root. The certificate ecosystem, the CAs, and the trust stores remain.
3. “MTCs invent new post-quantum math.” The cryptography underneath is the same standardized ML-DSA signatures and SHA-256 hashing everyone else uses. The innovation is structural, amortizing one signature across a whole batch through a Merkle tree.
4. “A signatureless certificate means no trust and no verification.” Verification still happens, against a signed tree head the browser downloaded ahead of time and that independent cosigners have checked. The signature moved off the connection and into the predistributed anchor, it did not disappear.
5. “This makes post-quantum certificates bigger, like everything else quantum.” In signatureless mode a proof of 736 bytes can be smaller than a single classical certificate chain, which is the counterintuitive payoff of the whole design.
6. “If my browser is behind, the site will break.” A server deploys a full classical fallback certificate for out-of-date clients, so a stale browser drops back to ordinary web PKI rather than failing.

Questions people ask

What problem do Merkle Tree Certificates actually solve? Bandwidth. Post-quantum signatures are about 20 times larger than elliptic-curve ones, and a TLS handshake sends several per connection, so a post-quantum certificate chain runs well over 10,000 bytes. MTCs amortize one signature across millions of certificates and ship a short inclusion proof instead, shrinking the per-connection cost dramatically.

How big is a Merkle Tree Certificate? In the signatureless mode the draft works out, an inclusion proof is 23 SHA-256 hashes, or 736 bytes, for a subtree of roughly 4,400,000 certificates. That is smaller than one ML-DSA-44 signature at 2,420 bytes.

Is this deployed anywhere today? Only in experiments. Google Chrome and Cloudflare are running a Phase 1 feasibility study in which MTCs are trialed with a traditional X.509 certificate as a fallback on every connection, with later phases targeted through 2027.

Do Merkle Tree Certificates use quantum-safe cryptography? Yes. Tree heads are signed with standardized post-quantum signatures such as ML-DSA, and the tree itself is built on SHA-256 hashing, which is quantum-resistant. The scheme is a more efficient way to carry that cryptography, not a substitute for it.

How is this different from Certificate Transparency? Certificate Transparency bolts public logging onto certificates after issuance through SCTs, each carrying its own signature. MTCs build the log into issuance, so one Merkle structure proves the certificate is genuine and that it was logged, without separate SCT signatures on the wire.

What are the risks or downsides? The main one is client freshness. Certificates live about a week, so a browser that has not updated its landmarks within that window cannot use the small signatureless path and needs a full fallback certificate. The scheme also adds an out-of-band distribution channel for tree heads that has to be operated reliably.

Should this change my migration plan right now? It changes what you watch, not what you deploy. The near-term migration still runs on ML-KEM hybrid key exchange and ML-DSA signatures in standard certificates. MTCs are worth tracking as the likely answer to the post-quantum certificate-size problem for the public web, and worth piloting once the standard stabilizes.

Who is building Merkle Tree Certificates? The original draft is authored by David Benjamin of Google, the work is now developed in the IETF PLANTS working group, and the first live trials are a collaboration between Google Chrome and Cloudflare.

---

Everything here is the map, given freely. When your team needs its own certificate estate found, sized against the post-quantum bandwidth problem, and sequenced onto a path that keeps room for what standardizes next, that’s the work I do. Request an alignment briefing.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.