Skip to content

CLOUDFLARE 2026-09-29 Tier 1

Read original ↗

Building a post-quantum certificate authority with Merkle Tree Certificates

Summary

The architecture-deep-dive companion to Cloudflare's 2026-09-29 public-CA announcement. Where that post argued why Cloudflare is becoming a CA, this one describes how the CA will issue Merkle Tree Certificates (MTCs) — the compact, post-quantum certificate form Chrome named the preferred path for PQ authentication. The core idea, from the Web PKI side: naively swapping post-quantum signatures into today's certificates at Internet scale would bloat certificate transparency logs by an estimated 40× and degrade TLS-handshake performance, because PQ signatures are roughly 40× larger than classical ones. MTCs, a draft from the IETF PLANTS working group, instead batch certificates into an append-only Merkle tree and sign the root once, so a client verifies a certificate with a compact inclusion proof against a signed tree head rather than validating a full per-certificate signature chain. The design principle: "don't log what you issue, issue by logging" — coupling issuance and logging makes transparency a requirement for operation rather than an add-on. Cloudflare's MTC CA forks Let's Encrypt's Boulder ACME software for issuance and implements its mirroring cosigner in Azul, its open-source Rust transparency log. A prior experiment with Chrome served billions of MTCs to 50% of Chrome Beta 146 and measured 9% faster median handshakes with landmark-relative MTCs over a classical chain.

Key takeaways

  1. The post-quantum scaling problem is the whole motivation. To authenticate ~a billion TLS servers without preloading every server's key into every client, the Web PKI historically used certificate chains as a trust-distribution mechanism — but a typical TLS handshake now carries five signatures and two keys (leaf + intermediate + revocation + CT). PQ signatures are ~40× larger than classical, and Cloudflare estimates PQ signatures will balloon CT-log storage by 40×. That storage cost makes it hard to sustain a diverse set of log operators — the incentive misalignment "at the heart of the post-quantum scaling problem." (Source: sources/2026-09-29-cloudflare-building-a-post-quantum-certificate-authority-with-merkle-tr)
  2. MTCs: batch, commit, sign-once. MTCs (IETF PLANTS WG draft) batch certificates into an append-only Merkle tree; the CA signs the root instead of each certificate. Clients verify with a compact inclusion proof (a sequence of hashes) against a signed tree head — never validating each certificate individually.
  3. "Don't log what you issue, issue by logging." The load-bearing idea: couple issuance and logging so transparency becomes a requirement for operation, not an add-on. The CA's issuance log is the source of truth for every certificate it issues; log consumers fetch a single copy of each certificate, preventing the certificate-explosion that today's CT (frequently-relogged, multi-form, multi-log) suffers.
  4. The CA's responsibilities barely change; the trust anchor does. A CA still validates domain control, binds a domain to a public key, and issues. The difference: instead of signing certificates and then logging them, the MTC CA maintains a transparency log backed by a Merkle tree, and an inclusion proof that the certificate is in the tree is the trust anchor.
  5. Cosigners provide the independent-view guarantee. After adding an entry to its issuance log, the CA computes the updated log state and signs a checkpoint over it, then sends the state + checkpoint to a mirroring cosigner that durably stores a copy of the log and verifies each new state is append-only, consistent with the previous tree, and correctly formed. The cosignature gives clients/monitors confidence the CA is not presenting different log views to different parts of the ecosystem (split-view defense), and keeps issued certs available for monitoring even if the CA's own log is down. Chrome's Quantum-resistant Root Program draft policy mandates ≥2 cosignatures: one from a Chrome-recognized Mirroring Cosigner run by a distinct organization, plus one from the issuing CA itself.
  6. Two certificate forms — standalone and landmark-relative. Both encode in the X.509 format today's clients recognize (just with a "funny" signature algorithm). Standalone: the signature value carries a cosigned tree head + an inclusion proof — self-contained, still ships a heavyweight PQ signature. Landmark-relative: the signature value is only the lightweight inclusion proof, with no post-quantum signatures at all — because clients obtain the cosigned tree heads (landmarks) out-of-band via a browser update service.
  7. The landmark optimization is where the real performance win lives. CAs designate a sequence of subtrees covering all active certificates as a landmark and distribute them (plus authentication data) to clients out-of-band. At handshake time the browser checks the server's cert data (domain + public key) appears in a trusted subtree; if the inclusion proof connects it to a cosigned landmark and the key proves possession, the client knows it's talking to the right server. A small set of MTC batch signatures can cover billions of certificates for a CA. Landmarks do not eliminate standalone MTCs — a client may be newly installed, offline, or missing the relevant landmark — so servers must retain a standalone fallback.
  8. The Chrome experiment worked. Cloudflare ran a "bootstrap CA" (a fake CA stubbing the issuance pipeline, backing MTCs with a traditional cert chain) for free-plan Cloudflare domains, served to 50% of Chrome Beta 146, and served billions of MTCs. Common case: a landmark-relative handshake transmits one public key, one signature, one inclusion proof of <1 kB. Result: 9% faster median with landmark MTCs vs a classical signature chain (admittedly most of the win is intermediate elision) — and because the test used classical signatures, the benefit should be larger with PQ. Wound down August 2026.
  9. Issuance software stack: fork Boulder, mirror in Azul. Cloudflare's ACME infrastructure will be a fork of Boulder (the well-tested software powering Let's Encrypt, which is actively developing MTC support), maintained with Cloudflare-specific changes and contributing back upstream. The mirroring cosigner is implemented in Azul, Cloudflare's open-source Rust transparency log, speaking c2sp's tlog-mirror protocol for interoperability. Cloudflare will also operate mirrors for other pilot CAs and require ≥1 independent cosignature on its own issued certs.
  10. Certificate transparency's role grows, not shrinks. With MTCs the log only needs to carry hashes of public keys — no per-entry signatures, and the tree-head signature covers the whole log. As domains upgrade to PQ authentication, CT monitoring becomes critical for detecting post-quantum downgrades: a domain that has gone PQ should watch CT logs for unexpectedly-issued legacy certificates that would signal a malicious downgrade path. Cloudflare runs the Nimbus CT logs (since 2016) and is launching Raio, a new family of static CT logs.

Systems / concepts extracted

  • Merkle Tree Certificates (MTC) — batch-and-commit certificate form; standalone vs landmark-relative; inclusion proof against a cosigned tree head. IETF PLANTS WG draft.
  • Cloudflare Certificate Authority — the CA operating the issuance-log + mirroring-cosigner stack; Boulder fork + Azul mirror; Q1 2027 production MTC target.
  • Azul — Cloudflare's open-source Rust transparency log; implements the mirroring cosigner via c2sp tlog-mirror. (NEW PAGE)
  • Boulder — Let's Encrypt's ACME server software; Cloudflare forks it for MTC issuance. (NEW PAGE)
  • Certificate Transparency — the audit-log framework MTCs fold into ("issue by logging"); Nimbus + new Raio static logs; PQ-downgrade monitoring role.
  • Let's Encrypt — Boulder's origin; developing MTC support in Boulder.
  • Web PKI — the trust ecosystem MTCs redesign for the PQ era (root programs, CAs, CT, monitors).
  • ML-DSA — representative PQ signature (~40× classical) whose size drives the whole MTC design.
  • concepts/post-quantum-authentication — the migration MTC issuance serves at visitor-facing scale.
  • concepts/downgrade-attack — the PQ-downgrade risk CT monitoring detects for already-migrated domains.

Operational numbers

  • PQ signatures ~40× larger than classical; estimated 40× growth in CT-log storage from PQ signatures.
  • ~a billion TLS servers the Web PKI must authenticate.
  • Typical TLS handshake today: 5 signatures + 2 keys.
  • Chrome experiment: served to 50% of Chrome Beta 146; billions of MTCs served; landmark-relative handshake transmits 1 public key + 1 signature + 1 inclusion proof (<1 kB).
  • 9% faster median handshake with landmark MTCs vs classical chain (mostly intermediate elision).
  • Chrome QR Root Program draft mandates ≥2 cosignatures (1 distinct-org mirror + 1 issuing CA).
  • Nimbus CT logs operated since 2016; new Raio static CT logs launching.
  • Experiment wound down August 2026; production MTCs targeted Q1 2027.

Caveats

  • Announcement + experiment retrospective, not a shipped production CA. The MTC CA issuance stack is being built; production MTC issuance is targeted for Q1 2027. The 9% figure comes from a classical-signature bootstrap experiment, and Cloudflare notes most of that gain is intermediate elision, not the PQ-vs-classical difference.
  • Open ecosystem questions remain, stated explicitly: can independent monitors consume/verify MTC issuance logs at production volume? Will enough CAs and cosigners emerge for resilience? How should browsers balance compact landmark MTCs against the fallback paths needed for clients without fresh landmarks? These require the whole PKI ecosystem to participate.
  • Protocol specifics (batch sizes, landmark cadence, exact tree-head/checkpoint formats, revocation semantics) live in the IETF PLANTS MTC draft and the tlog-mirror spec, not this post.

Source

Last updated · 766 distilled / 2,225 read