Patents Wiki
Back to briefings
InfoCryptography

Let's Encrypt's Post-Quantum Plan: Merkle Tree Certificates, Explained

For most of the last decade, the post-quantum conversation has been about encryption. The threat model was simple: record TLS traffic today, decrypt it later when a cryptographically relevant quantum computer shows up. That meant the priority was swapping out key exchange, not signatures. Authentication was the part of TLS that only had to be secure right now, not decades from now, because a quantum attacker would need to forge a signature in real time. The 2022 NIST selections and the 2024 transition guidance reflected that framing. So did the deployment of hybrid post-quantum key exchange (X25519MLKEM768) across browsers and servers over the past 18 months.

Then 2026 happened. Google announced it would migrate its services to post-quantum authentication by 2029. Cloudflare followed. Go 1.27 added ML-DSA, the NIST-standardized post-quantum signature scheme, to the standard library. The NSA's CNSA 2.0 timeline, NIST's draft deprecation of RSA-2048 and P-256 after 2030, and the EU's coordinated roadmap all point to the same place: the post-quantum signature transition is no longer optional, and the Web PKI is the hardest place to do it. On June 3, 2026, Let's Encrypt published the most concrete public roadmap so far for solving that problem. The answer, they say, is Merkle Tree Certificates.

The publication at a glance

  • Publication type: Engineering roadmap and public specification direction post
  • Title: "A Post-Quantum Future for Let's Encrypt"
  • Author: Andrew Gabbitas (Let's Encrypt)
  • Published: June 3, 2026
  • Publisher: Internet Security Research Group (ISRG)
  • Technical approach: Merkle Tree Certificates (MTCs), a new certificate format under IETF standardization
  • Referenced partners: Chrome (Google), Cloudflare, IETF PLANTS working group
  • Source / Venue: letsencrypt.org blog

The problem it is trying to solve

Authentication in the Web PKI today is small. RSA-2048 signatures are 256 bytes. ECDSA-P256 signatures are 64 bytes. A typical TLS handshake carries five signatures and two public keys, plus a couple of Signed Certificate Timestamp (SCT) signatures that attest the certificate was logged to a Certificate Transparency log. All told, a normal handshake is two to four kilobytes of authentication overhead. People do not notice two to four kilobytes.

The post-quantum signature schemes NIST standardized do not look like that. ML-DSA-44, one of the smaller options, produces 2,420-byte signatures and 1,312-byte public keys. A single TLS handshake using ML-DSA-44 would carry five of those signatures and two of those keys, which is roughly thirteen kilobytes of authentication overhead on every connection. Cloudflare's measurements, cited in the post, show that at that scale a meaningful share of TLS connections start to fail on real-world networks, and the rest get noticeably slower. The Web is not a place where you can quietly add thirteen kilobytes to every handshake by default.

There is a second problem hiding inside the first. Certificate Transparency is bolted on. Certificates are issued by CAs, then logged separately, and the SCTs that prove a certificate was logged ride along in the TLS handshake as extra signatures. If you switch to ML-DSA-44, the SCTs become post-quantum-sized too, which makes the handshake even larger. The Web PKI pays the post-quantum cost twice, once for the cert and once for the transparency proof.

The core idea

Merkle Tree Certificates flip the structure. Instead of signing each certificate individually, the CA batches certificates into a Merkle tree, signs the root of that tree once, and publishes the tree. The signed root is called a "landmark." Browsers fetch landmarks out of band, on a schedule that is not tied to the TLS handshake. When a server presents a certificate during a TLS handshake, the server also sends a short Merkle inclusion proof that the certificate is a leaf in a recent landmark's tree. The client checks the proof against the landmark it already has. The cert is authenticated.

In the common case, the entire authentication path is one batch signature (the landmark the client already has), one public key, and one inclusion proof. That is smaller than a current Web PKI handshake, even though the cryptography underneath is post-quantum. The CA does the expensive work once per batch. Every cert in the batch reuses that work.

Because the cert lives inside the Merkle tree by construction, Certificate Transparency stops being a separate logging step. The CT log and the issuance log are the same log. There are no SCT signatures riding along in the handshake, because the proof of inclusion is the SCT. The double cost disappears.

How it works

Core Architecture/Flow

Let's Encrypt has been running append-only Merkle-tree Certificate Transparency logs in production since 2019. MTCs reuse that exact data structure for issuance itself. The pieces line up like this:

  • Batch issuance. A CA collects certificates into a Merkle tree. The CA holds a long-lived key whose only job is to sign the Merkle root of each batch. That signature is the landmark.
  • Landmark distribution. Browsers and other relying parties pull recent landmarks from the CA's transparency log directly, or receive them through CDN distribution, on a schedule that is independent of any individual TLS connection. This is the "out of band" channel.
  • TLS handshake. During a TLS handshake, a server presents its certificate plus a Merkle inclusion proof. The proof is a short path from the certificate hash up to a specific landmark's root. The client already has the landmark, so it can verify the proof without contacting the CA or doing extra fetches.
  • Standalone fallback. If a client is offline, or has a stale landmark view, the server falls back to a slightly larger handshake that includes a per-certificate signature plus the inclusion proof. It is bigger than the common case but still smaller than a full ML-DSA-44 TLS handshake with separate SCTs.
  • CT by construction. Every certificate in an MTC batch is a leaf in a published Merkle tree. There is no separate transparency step. The audit log is the issuance log.

Cloudflare and Chrome have been running a feasibility experiment with MTCs against live internet traffic. Chrome has stated publicly that MTCs are its preferred path for adding post-quantum certificates to the public web. The IETF PLANTS working group is standardizing the design.

The core claims in plain English

Let's Encrypt makes a small set of concrete claims in the post, and they are worth reading closely:

  • A common-case MTC handshake is smaller than today's Web PKI handshake, even though it uses post-quantum signatures. The math works out because the post-quantum signature is paid once per batch rather than once per cert, and inclusion proofs are short.
  • A standalone MTC handshake is larger than the common case but smaller than a naïve ML-DSA-44 handshake with separate SCTs. The fallback exists so that clients without recent landmarks (think: cold-start, offline, very new installations) can still authenticate.
  • Certificate Transparency becomes a property of issuance, not a bolt-on. Every MTC is in a published Merkle tree by construction. There is no way to issue a cert outside the log, which is exactly what CT was supposed to guarantee.
  • The transition is multi-year and starts now. Let's Encrypt is targeting a staging environment that issues MTCs in late 2026, and a production-ready environment in 2027. ACME clients, browsers, and the broader Web PKI ecosystem have to land changes too.
  • MTCs are complementary to ML-DSA, not a replacement for the math. The post tracks RFC 9881 (ML-DSA in X.509) and the TLS-side draft alongside MTC work, because the Web PKI's transition needs both to land. The choice is about how post-quantum signatures are amortized and structured, not which algorithm is used.
  • Nothing changes for current users. Existing ACME-driven certificates continue to issue and renew exactly as before. The transition is opt-in at the issuance level and, eventually, at the client level.

Why it matters

If you have ever spent a week debugging a TLS handshake failure on a flaky mobile network, you already know why the Web PKI cannot casually double or triple its handshake size. The post-quantum migration has always had a deployment economics problem: the algorithms work, the standard bodies are done, but the network cost of using the algorithms at Web scale is what would actually break things. MTCs are the first design I have seen that takes that constraint seriously and turns it into an architecture choice rather than a deployment footnote.

The second reason it matters is the structural one. MTCs unify two things that have been separate for a decade: certificate issuance and certificate transparency. Every cert is a leaf in a public Merkle tree, and the tree is the issuance log. The CT log ecosystem that Let's Encrypt already operates shrinks, the SCTs disappear from handshakes, and the audit guarantee becomes a mathematical property of the format rather than a process layered on top of it. That is a quieter win than the byte savings, and possibly a bigger one long term.

The third reason is timing. With Google's 2029 target, Cloudflare's parallel commitment, the CNSA 2.0 mandate, the EU's roadmap, and the standardization of ML-DSA in Go 1.27, the post-quantum signature transition has moved from "someday" to "this decade." Let's Encrypt is the organization that has issued more free DV certificates than any other CA in history, and their plan is one of the most concrete public commitments to a specific design so far. Chrome and Cloudflare have publicly aligned on it.

Limits, uncertainties, and what to watch next

A few things are worth being clear-eyed about:

  • MTCs are not yet a finished standard. The IETF PLANTS working group is still finalizing the design. Several open questions (revocation, root program requirements, ACME extensions, browser cache policies for landmarks) need to settle before production rollouts.
  • The TLS ecosystem has work to do. ACME clients need to support the new issuance flow. Browsers need landmark fetching and storage. CDNs and origin servers need to serve the right artifacts. None of that lands overnight.
  • Standalone handshakes exist for a reason. If landmark distribution breaks, or if a client is misconfigured, the fallback path is bigger. Operators will need to monitor both forms.
  • CT log operators see a structural change. Existing log infrastructure has to evolve. MTCs subsume the SCT workflow, which means the ecosystem that runs CT logs today has to decide what it runs tomorrow.
  • This is a plan, not a finished deployment. The 2026 staging and 2027 production targets are the right way to manage a transition of this size, but they are not guarantees. The most likely slip mode is standards-and-ecosystem pace, not cryptographic surprises.

The most useful thing to watch over the next six months is whether Cloudflare and Chrome expand the existing feasibility experiment, whether the IETF PLANTS working group produces a stable draft, and whether the ACME working group commits to specific protocol changes for MTC issuance. If those three line up by the end of 2026, the 2027 production target becomes plausible.

Sources