Learn
0%
Build
0%

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(incl. cert body, SANs, extensions)

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 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

One CA signing operation covers the entire batch — potentially millions of certificates. Depending on the relying party's cosigner policy, additional external witnesses may also co-sign the subtree to guarantee public transparency. For signatureless certificates, no embedded signatures are needed at all (relying parties use predistributed trusted subtrees instead).

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 CA)
↓        ↓
  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 five key roles (per draft-ietf-plants-merkle-tree-certs Section 2.1), redesigned from Certificate Transparency for batch efficiency:

Certification Authority (CA)

Maintains the issuance log, builds the Merkle tree, signs checkpoints and subtrees, requests cosignatures, and assembles certificates with inclusion proofs. The CA certifies information by logging it, inverting the CT model.

Cosigner

Signs views of the issuance log to assert correct operation. Cosigners verify the log is append-only, optionally mirror its contents, and cosign checkpoints and subtrees. One cosigner signature covers a subtree of millions of entries.

Authenticating Party

TLS servers that receive their certificate assertion + inclusion proof from the CA and present them during the TLS handshake. Sends the Certificate and CertificateVerify messages.

Relying Party

The client that verifies certificates. Maintains trusted subtrees, cosigner requirements, and revoked index ranges. For landmark certificates, relying parties pre-sync trusted subtrees in the background.

Monitor

Watches the issuance log for certificates of interest, analogous to CT monitors. Ensures the CA is operated correctly and entries are publicly visible.

Certificate Types & Tradeoffs

The spec defines two certificate types. Authenticating parties SHOULD deploy both and select based on client capabilities:

Standalone Certificate

Contains an inclusion proof plus cosignatures from the CA and external cosigners. Works without any predistributed state — the relying party verifies signatures at connection time. Can be issued with minimal processing delay.

Landmark Certificate

Contains an inclusion proof to a predistributed landmark subtree and no signatures. Relying parties pre-sync trusted landmark subtrees in the background. Maximal size savings but requires an up-to-date client.

Advantages (both types)
  • • Massive size reduction (60–63% standalone, 92% landmark for ML-DSA)
  • • Single CA signing operation covers millions of certificates
  • • Inclusion proof is pure hash computation — fast to verify
  • • Inherent certificate transparency (issuance log = public record)
Considerations
  • • Landmark only: clients must pre-sync trusted subtrees periodically; not suitable for offline or intermittently-connected devices
  • • Revocation uses Revocation by Index (Section 7.5): relying parties maintain revoked ranges of indices checked at verification time
  • • Trust requires meeting cosigner requirements — relying parties accept a subtree only after a configured set of cosigners have signed it, preventing a compromised CA from silently misissu­ing
  • • Standalone only: certificates carry multiple cosignatures, adding some bytes beyond the inclusion proof

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. Draft — not yet an RFC

Timeline
  • • March 2023: Initial draft published (draft-00)
  • • October 2025: Cloudflare + Chrome experiment announced
  • • January 2026: draft-davidben-tls-merkle-tree-certs-10 submitted; adopted by IETF PLANTS WG as draft-ietf-plants-merkle-tree-certs-00
  • • February 2026: draft-ietf-plants-merkle-tree-certs-01 published
  • • March 2026: draft-ietf-plants-merkle-tree-certs-02 published
  • • Status: Active IETF draft — not yet standardized as an RFC. Not recommended for production deployment without vendor support.
Authors & Analysis
  • • David Benjamin + Devon O'Brien (Google)
  • • Bas Westerbaan + Luke Valenta (Cloudflare)
  • • Filippo Valsorda (Geomys)
  • • Radboud University (independent implementation analysis, 2025)

Related Resources

Merkle trees are fundamental to post-quantum cryptography beyond MTCs. (SPHINCS+, FIPS 205) uses nested Merkle trees internally 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 principle at the infrastructure level to solve the certificate size problem PQ signatures create.

Stateful Hash Signatures
LMS, XMSS, and SLH-DSA Merkle tree internals
PKI Workshop
Certificate issuance and PQC root of trust migration
TLS Basics & PQC
How MTCs reduce TLS handshake size with PQ certificates

Ready to Build?

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

Check off all sections and mark this reading done.

Learning module content can be inaccurate. Please double-check its information. Report inaccuracies in PQC Today GitHub Discussions.