Skip to content

SYSTEM Cited by 2 sources

Merkle Tree Certificates (MTC)

What

Merkle Tree Certificates (MTC) is a TLS certificate-issuance mechanism designed for the post-quantum era, where conventional per-connection PQ signature chains become too large to transmit efficiently on every handshake. Instead of every leaf certificate carrying its own full PQ signature chain, MTC batches many certificates under a Merkle tree root that is signed once (with a PQ signature) and distributed to clients out-of-band; the wire presents just the leaf cert + a Merkle inclusion proof.

Cloudflare's Mid-2027 roadmap milestone names MTC as the mechanism for visitor → Cloudflare PQ authentication — the public-web-facing edge of Cloudflare's full-PQ-security stack. (Source: sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security)

The size problem MTC addresses

Classical TLS certificate chains are small:

  • RSA-2048 certificate signature: ~256 bytes
  • Ed25519 signature: 64 bytes
  • Typical chain (leaf + intermediate + root): 2-5 kB total

Post-quantum signatures are an order of magnitude larger:

  • ML-DSA-65 signature: ~3.3 kB
  • ML-DSA-65 public key: ~1.95 kB
  • SLH-DSA signature: 8-49 kB depending on parameter set
  • A PQ certificate chain with leaf + two intermediates can reach 15-50 kB per handshake.

For high-connection-rate TLS servers (CDNs, browsers, IoT endpoints) this is a structural problem:

  • Handshake ClientHello / ServerHello ballooning past IP MTU creates middlebox / QUIC amplification-limit issues.
  • Increased bandwidth cost per connection across millions of connections per second.
  • Connection-latency increase on low-bandwidth / mobile networks.

How MTC works (high level)

MTC reframes certificate issuance as a batch-and-commit operation:

CA side:
  Issue a batch of N certificates during some window (e.g. an hour).
  Build a Merkle tree whose leaves are the cert commitments.
  Sign the Merkle root once with a PQ signature.
  Publish the signed root to out-of-band distribution (e.g. to
    clients via OS / browser updates, or via CT-log-like channels).

Server side:
  During TLS handshake, present:
    - the leaf certificate, and
    - a Merkle inclusion proof that it's in a known-signed batch.
  No need to carry a full PQ signature in the per-connection
    transcript.

Client side:
  Verify:
    - the PQ signature over the Merkle root (done once per batch,
      from its local trusted-root store), and
    - the inclusion proof (O(log N) hashes).
  Accept the cert.

The key trick: the expensive PQ signature is amortised across the batch and distributed in advance, so the TLS handshake carries only logarithmic-size proof material rather than per-connection full signatures.

Why MTC specifically for visitor → Cloudflare

Cloudflare's Mid-2027 roadmap uses MTC for the visitor-facing side specifically, not for Cloudflare→origin (which uses ML-DSA directly). The split reflects structural differences:

  • Visitor → Cloudflare — massive connection rate (tens of millions of requests per second globally), heterogeneous long- tail of client capabilities, MTU-constrained mobile paths. Size matters enormously; out-of-band batch-root distribution to browsers is feasible via existing update channels.
  • Cloudflare → origin — much smaller connection count, controlled both endpoints (customer origin), direct ML-DSA cert deployment is feasible without MTC's additional complexity.

Comparison with existing alternatives

  • Certificate Transparency — also uses Merkle trees but for a different purpose: public- audit log of issued certs so mis-issuance is detectable. CT does not amortise signature size; each cert still carries its own signature. MTC is structurally closer to "CT log entries as the primary trust path" rather than as audit.
  • KEMTLS — research proposal (Schwabe, Stebila, Wiggers 2020) removes signatures from the TLS handshake entirely by using authenticated KEMs. Complementary to MTC (addresses a different aspect — in-handshake signing → KEM-based auth — rather than amortising issuance).
  • Intermediate-less hierarchies — flattening PKI to remove intermediate certs. Reduces handshake size somewhat but doesn't scale down the per-cert PQ signature cost.

Raw-scope caveats

This wiki page is scoped to what the Cloudflare 2026 post names:

  • MTC as the Mid-2027 milestone mechanism for visitor→Cloudflare PQ authentication.
  • Positioned in the overall Cloudflare 2029 PQ roadmap.

Specific protocol details — batch sizes, root-distribution cadence, interaction with browser root stores, SCT-style verification details, revocation semantics — are not in the Cloudflare post; they are covered in the separate MTC IETF-draft lineage (see external specification documents linked from Cloudflare's PQ research pages). Future ingests may deepen this page when those drafts or deployment posts are indexed.

Seen in

EO context (June 2026)

Cloudflare identifies MTC as critical to meeting the Dec 2031 PQ authentication deadline. ML-DSA signatures are significantly larger than classical signatures, degrading performance on short-lived TLS connections. MTC solves this by batching certificates into Merkle-tree structures that amortize the large PQ signature size. Cloudflare is working with Google Chrome on MTC deployment ("bootstrap MTC").

The EO's Dec 2031 authentication deadline makes MTC's timeline (Cloudflare targeting Mid-2027 for visitor→Cloudflare MTC) a critical path dependency for the broader ecosystem.

(Source: sources/2026-06-23-cloudflare-post-quantum-eo-milestone)

Last updated · 608 distilled / 1,858 read