Skip to content

SYSTEM Cited by 1 source

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

Last updated · 200 distilled / 1,178 read