Skip to content

SYSTEM Cited by 4 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.

Issuance architecture: two certificate forms + cosigners (2026-09-29 deep dive)

The Cloudflare MTC-CA deep dive describes the concrete issuance stack behind the Q1 2027 production commitment. Both MTC forms encode in the standard X.509 format clients already recognize — just with a "funny" signature algorithm — so no new certificate container is needed.

"Issue by logging"

The load-bearing design principle (from the PLANTS WG): "don't log what you issue, issue by logging." Instead of signing a certificate and then submitting it to CT logs, the MTC CA maintains a transparency log backed by a Merkle tree and the act of adding an entry is the issuance. An inclusion proof that the certificate is in the tree serves as the trust anchor. Coupling issuance and logging makes transparency a requirement for operation rather than an add-on — the CA's issuance log is the single source of truth for every certificate it issues, and log consumers fetch just one copy of each.

The issuance flow (standalone example)

1. Server requests a cert via ACME (Boulder fork does domain-control validation).
2. CA serializes the validated data and APPENDS it to its issuance log.
3. CA computes the updated log state and SIGNS a checkpoint over it
   (attesting to every entry up to that point).
4. CA sends state + checkpoint to a mirroring cosigner, which durably stores a
   copy and verifies the new state is append-only, consistent, correctly formed,
   then returns a cosignature.
5. CA constructs the MTC from the cosignature(s) + server public key + inclusion
   proof and delivers it to the server for use in TLS.

Standalone vs landmark-relative

Form Signature value carries PQ signature on the wire? When used
Standalone cosigned tree head + inclusion proof Yes (heavyweight) Fallback — client is new, offline, or lacks the relevant landmark
Landmark-relative only the inclusion proof None Common case — client already has the cosigned tree heads out-of-band

Landmark-relative certificates are where the real efficiency lives. A CA designates a sequence of subtrees covering all active certificates as a landmark and distributes those subtrees (plus authentication data) to clients out-of-band via a browser update service. At handshake time the browser checks that the server's certificate data (domain + public key) appears in a trusted subtree of the CA's log; if the inclusion proof connects it to a cosigned landmark and the key proves possession during the handshake, the client knows it's talking to the right server — with no post-quantum signature transmitted at all. A small set of MTC batch signatures can efficiently cover billions of certificates for a given CA.

Landmarks do not eliminate the need for standalone MTCs — a client may be newly installed, offline, or missing the relevant landmark update — so servers must retain a standalone fallback.

Cosigners and the ≥2-cosignature rule

A mirroring cosigner durably stores a copy of the CA's issuance log, verifies its append-only consistency, and returns a cosignature. This gives clients and monitors confidence that another trusted party observed the same log state — the defense against a CA presenting different views of issuance to different parts of the ecosystem (split-view) — and keeps issued certs available for monitoring even if the CA's log is down. Chrome's Quantum-resistant Root Program draft policy mandates at least two cosignatures: one from a Chrome-recognized Mirroring Cosigner run by a distinct organization, plus one from the issuing MTC CA itself. Cloudflare implements its cosigner in Azul (its open-source Rust transparency log) using c2sp's tlog-mirror protocol, will operate mirrors for other pilot CAs, and requires ≥1 independent cosignature on its own certs. Issuance itself forks Boulder (Let's Encrypt's ACME software).

Chrome experiment results

A prior experiment served MTCs (backed by a traditional cert chain, using classical signatures) to 50% of Chrome Beta 146 for free-plan Cloudflare domains, serving billions of MTCs. A landmark-relative handshake transmits just one public key, one signature, and one inclusion proof of <1 kB; where a landmark-relative cert couldn't be negotiated, Cloudflare fell back to the traditional cert chain. Result: 9% faster at median with landmark MTCs vs a classical signature chain — though most of that gain is intermediate elision, and the benefit is expected to be larger with post-quantum signatures (which the experiment did not yet use). Wound down August 2026. (Source: sources/2026-09-29-cloudflare-building-a-post-quantum-certificate-authority-with-merkle-tr)

Production issuance milestone (Q1 2027)

The MTC transition moves from roadmap to a concrete production issuance commitment: the Cloudflare Certificate Authority plans to be one of the first CAs to issue production MTCs, with the first certificates in Q1 2027, targeting Chrome's Quantum-resistant Root Program (Chrome having named MTCs the preferred path for post-quantum authentication). (Source: sources/2026-09-29-cloudflare-building-a-certificate-authority-for-the-whole-internet)

The load-bearing design decision from that announcement: classic certificates and MTCs live in one service, under one lifecycle and one set of guarantees. Because the PQ transition is expected to span years (much of the Internet stays on classic Web PKI for a long time), carrying both under one CA lets customers adopt at their own pace without picking a side of a multi-decade migration, running two systems, or rebuilding when the balance shifts. This positions MTC not as a standalone product but as one issuance mode of a general-purpose public CA.

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 · 766 distilled / 2,225 read