Merkle Tree Certificates

Build Merkle trees interactively, generate and verify inclusion proofs, and compare MTC vs traditional PKI for post-quantum TLS.

The Certificate Bloat Problem

Post-quantum digital signatures are dramatically larger than their classical counterparts. While an P-256 signature is just 64 bytes, an signature is 2,420 bytes — a 37× increase. A typical TLS certificate chain contains three signatures (Root CA, Intermediate CA, and end-entity), three public keys, and multiple Certificate Transparency .

64 B
ECDSA P-256 signature
2,420 B
ML-DSA-44 signature
18–36 KB
PQC TLS chain overhead

This “certificate bloat” breaks constrained clients that reject chains larger than 10 KB, degrades connection setup times (especially on mobile networks), and increases bandwidth costs for high-traffic servers handling millions of TLS handshakes per second.

How Merkle Tree Certificates Work

Merkle Tree Certificates (MTCs) solve certificate bloat by replacing individual per-certificate signatures with a batch-signing approach using :

1
Batch Certificates

The Merkle Tree CA (MTCA) collects thousands of certificate assertions and places them as leaves in a binary hash tree. Each leaf is SHA-256(0x00 || cert data); internal nodes use SHA-256(0x01 || left || right). The domain-separation prefixes (0x00 / 0x01) prevent leaf hashes from ever being confused with internal node hashes.

2
Sign the Root

Only the tree's root hash is signed with the CA's private key. One single PQ signature covers the entire batch — potentially millions of certificates.

3
Distribute Inclusion Proofs

Each certificate holder receives a compact inclusion proof: the chain of sibling hashes from their leaf up to the root. This proof is 736 bytes for a batch of ~4.4 million certificates (23 sibling hashes × 32 bytes).

4
Verify via Hash Recomputation

The relying party hashes the certificate, then combines it with each proof sibling up the tree. If the computed root matches the signed root, the certificate is authenticated — no per-certificate signature verification needed.

Root Hash (signed by MTCA)
↓        ↓
  H(0,1)         H(2,3)
↓ ↓      ↓ ↓
Cert 1  Cert 2    Cert 3  Cert 4
To prove Cert 3 belongs to the batch, provide: H(Cert 4) + H(0,1) → recompute up to root

MTC Architecture

The MTC ecosystem defines three key roles, similar to existing Certificate Transparency (CT) infrastructure but redesigned for batch efficiency:

MTCA

Merkle Tree CA — Collects certificate assertions, builds the Merkle tree, signs the root hash, and distributes inclusion proofs to subscribers.

Transparency Service

Publishes signed tree roots so clients can periodically sync. Analogous to CT logs but with batch-level granularity rather than individual certificate entries.

Subscribers

TLS servers that receive their certificate assertion + inclusion proof from the MTCA and present them during the TLS handshake for client verification.

Tradeoffs

MTCs offer significant size savings, but they introduce new requirements:

Advantages
  • • Massive size reduction (63–74% for ML-DSA)
  • • Single CA signing operation covers millions of certificates
  • • Inclusion proof is pure hash computation — fast to verify
  • • Inherent certificate transparency (batch = public log)
Considerations
  • • Clients must sync signed subtrees periodically (background, out-of-band)
  • • Not suitable for fully offline verification scenarios
  • • Revocation uses Revocation by Index: relying parties maintain index-range exclusion lists checked at verification time
  • • Trust requires a cosigner quorum — relying parties accept a subtree only after a configured set of external witnesses co-sign it, preventing a compromised CA from silently misissu­ing

IETF Standardization Status

Merkle Tree Certificates originated as draft-davidben-tls-merkle-tree-certs (reaching draft-10, January 2026) and have since been adopted by the IETF PLANTS working group as draft-ietf-plants-merkle-tree-certs. The draft has five co-equal authors across Google, Cloudflare, and Geomys.

Timeline
  • • March 2023: Initial draft published (draft-00)
  • • October 2025: Cloudflare + Chrome experiment announced
  • • January 2026: draft-10 published; IETF PLANTS WG adoption
Authors & Analysis
  • • David Benjamin + Devon O'Brien (Google)
  • • Bas Westerbaan + Luke Valenta (Cloudflare)
  • • Filippo Valsorda (Geomys)
  • • Radboud University (independent implementation analysis, 2025)

Connection to Hash-Based Signatures

Merkle trees are fundamental to post-quantum cryptography beyond MTCs. (SPHINCS+, FIPS 205) uses nested Merkle trees internally (a hyper-tree of FORS trees) for quantum-resistant signatures. Stateful hash-based schemes like and use Merkle trees to organize pools of one-time signing keys.

MTCs apply the same hash-tree principle at the infrastructure level — organizing certificates rather than signing keys — to solve the size problem that these PQ signature schemes create.

Stateful Hash Signatures ModulePKI Workshop

Ready to Build?

Head to the Workshop to build a Merkle tree, generate inclusion proofs, and verify certificates hands-on.