Google’s Merkle Tree Certificates: How Chrome Plans to Quantum‑Proof HTTPS Without Turning TLS Handshakes into 2.5KB Speed Bumps

AI generated image for Google’s Merkle Tree Certificates: How Chrome Plans to Quantum‑Proof HTTPS Without Turning TLS Handshakes into 2.5KB Speed Bumps

On February 27, 2026, Google’s Chrome Secure Web and Networking Team published a post that can be summarized as: “Yes, we’re taking post-quantum crypto seriously, and no, we don’t want your web browsing to feel like dial-up.” The proposal is ambitious: make the WebPKI (the machinery behind HTTPS certificates) resistant to future quantum attacks without shipping multi‑kilobyte certificate blobs in every TLS handshake.

The catalyst is simple math with nasty networking consequences. Post-quantum (PQ) signature algorithms can require signatures measured in thousands of bytes. Cloudflare cites ML‑DSA‑44 signatures at 2,420 bytes versus 64 bytes for the widely deployed ECDSA‑P256 signature, with similarly inflated public keys. If you multiply that by the several signatures and keys that a typical WebPKI handshake drags along (CA chain plus Certificate Transparency proofs), you get “tens of kilobytes per handshake” — a performance tax that would show up everywhere, especially on constrained networks and devices. Google’s response: don’t send all that per connection. Send a compact proof instead.

Enter Merkle Tree Certificates (MTCs), a design being developed in the IETF’s newly approved PLANTS working group (“PKI, Logs, And Tree Signatures”). The elevator pitch: a Certification Authority signs a single “tree head” representing potentially millions of certificates; a website then sends the browser a small proof that its certificate is included in that signed tree. In other words: one signature can vouch for a huge batch, and the TLS handshake carries a lightweight inclusion proof rather than a bulky chain of PQ signatures.

This article expands on the Ars Technica report, “Google quantum-proofs HTTPS by squeezing 2.5kB of data into 64-byte space,” by Dan Goodin (Ars Technica). That story spotlighted the core challenge — post-quantum certificate material ballooning from ~64 bytes to ~2.5KB — and the industry’s push to avoid breaking the internet while upgrading its cryptographic foundations.

Now let’s unpack what Google and Cloudflare are actually doing, why it matters, what could go wrong, and what web operators and security teams should start planning for.

Why quantum threatens HTTPS certificates (and why this is different from “harvest now, decrypt later”)

If you’ve followed post-quantum cryptography even casually, you’ve likely heard the phrase “harvest now, decrypt later”: attackers can record encrypted traffic today and decrypt it in the future if they ever get a powerful quantum computer. That primarily targets key exchange (confidentiality). Cloudflare notes it already protects a large portion of its edge traffic against that near-term risk with post-quantum key agreement techniques. citeturn5view0

But HTTPS has another pillar: authentication. When your browser connects to a site, it needs to verify the site’s identity using a certificate chain anchored in a trusted root. That authentication relies heavily on classical public-key cryptography (RSA and elliptic curve algorithms like ECDSA). A sufficiently capable quantum computer running Shor’s algorithm could break those schemes — meaning an attacker could forge signatures, impersonate websites, or undermine parts of the certificate ecosystem.

Here’s the uncomfortable nuance: authentication upgrades are hard to “bolt on” late. A rushed switchover would be chaotic, and the WebPKI is not a system you want to hot‑patch during an emergency. It’s more like global infrastructure… because it is global infrastructure.

The performance problem: post-quantum certificates are big, and the WebPKI already carries a lot of baggage

Modern TLS handshakes rarely involve just a single signature and a single key. In an idealized world, a browser would already know every website’s public key, and the handshake would be tiny. In reality, the web has roughly “a billion TLS servers” (Cloudflare’s framing), and keys rotate. So the system relies on trusted intermediaries: Certification Authorities, intermediate certificates, and — increasingly — Certificate Transparency. citeturn5view0

Cloudflare provides a clear “count the signatures” walkthrough:

  • A server signs the handshake with its own key (+1 signature verification).
  • The server’s certificate is signed by a CA (+1 signature).
  • Chains are often longer due to CA key rotations (+1 signature and +1 key).
  • Certificate Transparency requires additional proof, commonly two Signed Certificate Timestamps (SCTs), adding yet more signatures to validate. citeturn5view0turn2search0

In Cloudflare’s estimate, that totals roughly 5 signatures and 2 public keys being dragged into the validation story for a typical public-web handshake. citeturn5view0

That’s manageable with classical signatures (64-byte ECDSA‑P256 signatures), but it’s a problem with PQ signatures. Cloudflare highlights the size jump explicitly: ML‑DSA‑44 signatures are 2,420 bytes and public keys are 1,312 bytes, versus 64 bytes for classical ECDSA. citeturn5view0

Multiply those bigger signatures across multiple components and you end up with the sort of handshake overhead that makes network engineers reach for the “disable feature” button — which is exactly what security teams don’t want.

Merkle Tree Certificates, explained like you’re on call and it’s 2 a.m.

Merkle trees are a classic data structure used to prove that an item is included in a larger set, using only a small “path” of hashes instead of the entire dataset. Certificate Transparency already uses Merkle trees for its append-only logs; RFC 9162 describes how CT logs use Merkle trees to provide efficient proofs and detect log misbehavior. citeturn2search0

MTCs take that idea and move it closer to the center of issuance. Cloudflare’s description is blunt and helpful: if the client is sufficiently up to date, the TLS handshake needs only 1 signature, 1 public key, and 1 Merkle tree inclusion proof — small enough to remain practical even with post-quantum algorithms. citeturn5view0

Here’s the conceptual flow:

1) Batch issuance, not one-off signing

Instead of signing each individual end-entity certificate with a costly PQ signature, the CA (or a specialized “Merkle Tree CA”) issues many certificates in a batch and creates a Merkle tree from those unsigned (or differently structured) certificate objects.

2) Sign the tree head once

The CA signs the tree head (also called a “tree root” in some Merkle contexts). That single signature now commits the CA to the entire batch.

3) Send inclusion proofs to servers

Each certificate gets an inclusion proof: the sibling hashes along the path from that leaf to the tree head. With the signed tree head and that proof, a client can verify the certificate is in the signed batch.

4) Ship tree heads out-of-band

The efficiency comes from distribution. Rather than sending a big signature chain every time, clients can receive and cache signed tree heads (Cloudflare calls certain selected heads “landmarks”) out-of-band. citeturn5view0

Cloudflare even shows an example certificate that looks like a normal PEM file, but with a twist: OpenSSL doesn’t recognize the issuer signature algorithm OID, and the reason is delightfully counterintuitive — the MTC “does not have a signature in it at all”. Instead, it contains an inclusion proof. citeturn5view0

Google’s plan: don’t shove PQ X.509 into the existing root store (yet)

Google’s February 27, 2026 post makes a key policy statement: Chrome has no immediate plan to add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store, specifically to avoid scaling and performance issues. Instead, Chrome is developing an evolution based on MTCs, aligned with the IETF PLANTS effort. citeturn4view1

That’s a big deal. It’s effectively Google saying: “Yes, we’ll do post-quantum authentication, but not by simply swapping algorithms inside the same old envelope.” The envelope itself (the issuance + transparency + delivery model) must change.

A phased rollout, with dates that matter

Google outlines a three-phase approach:

  • Phase 1 (underway): feasibility study with Cloudflare using real traffic; every MTC-based connection is backed by a traditional trusted X.509 certificate as a fail-safe. citeturn4view1
  • Phase 2 (Q1 2027): invite existing Certificate Transparency log operators that meet Google’s criteria (including having at least one “usable” log in Chrome before February 1, 2026) to bootstrap public MTCs. citeturn4view1
  • Phase 3 (Q3 2027): finalize requirements for onboarding additional CAs into a new Chrome Quantum-resistant Root Store (CQRS) and root program that only supports MTCs, operating alongside the existing Chrome Root Program to manage risk during transition. citeturn4view1

Two immediate takeaways for operators: (1) this is not a one-quarter switch, and (2) Google is explicitly planning a parallel trust store era — classic roots plus quantum-resistant MTC roots — for a while.

The IETF angle: PLANTS is now an official working group

Sometimes standards work is described as “glacial,” and sometimes that’s unfair. In this case, there’s a lot of urgency. The IETF charter for the PLANTS working group (approved and active, last updated January 8, 2026) is explicit: the goal is to trim the costs of large post-quantum signatures in PKIs that use Certificate Transparency, particularly for interactive protocols like TLS. citeturn1search0

PLANTS aims to integrate transparency log construction into certificate issuance and reduce the data in both log entries and the TLS handshake. The charter notes that techniques like signing Merkle tree hashes can allow a single signature to cover multiple key/identifier bindings. citeturn1search0

The charter also includes a practical safeguard that should make implementers breathe easier: it will not ship specs to the IESG for publication until there are two interoperable implementations. citeturn1search0

Certificate Transparency: why it exists, and why it’s central to this redesign

Certificate Transparency (CT) became a core part of web security after a series of CA failures and compromises demonstrated that “trust us” wasn’t enough. One of the most infamous incidents was the 2011 DigiNotar compromise, in which fraudulent certificates (including for Google domains) were used in man-in-the-middle scenarios affecting users in Iran, prompting widespread distrust actions and public post-mortems. citeturn3search0turn3search6

CT logs are append-only Merkle trees, and they provide signed timestamps (SCTs) as evidence that a certificate has been submitted to a log. RFC 9162 describes how clients can require SCTs and later demand proofs of inclusion, using Merkle tree properties to ensure append-only behavior. citeturn2search0

But CT has a side effect in a PQ world: it adds more signatures to validate, which multiplies the size problem. Cloudflare calls CT “trust but verify,” and notes that current browser policy often means two CT log signatures per handshake. citeturn5view0

MTCs attempt to make transparency a fundamental property of issuance: Google says “it is impossible to issue a certificate without including it in a public tree,” removing the bolt-on nature of CT and avoiding extra handshake overhead. citeturn4view1

So how do you squeeze “2.5KB into 64 bytes” without breaking physics?

Let’s be precise: nobody is compressing post-quantum signatures into 64 bytes like a cryptographic zip file. The trick is architectural: you stop sending the heavy stuff per connection and instead send a compact proof that references heavy stuff distributed elsewhere.

In today’s model, each TLS handshake carries a certificate chain (and often CT-related artifacts) that must be validated on the spot. In the MTC model, the client already has (or can fetch and cache) signed tree heads “out-of-band.” Then the server only needs to send the inclusion proof to connect its certificate to a trusted, signed landmark. citeturn5view0turn4view1

This matters because Merkle inclusion proofs scale logarithmically with the number of leaves. If a tree contains millions of certificates, the proof still consists of a relatively small number of hashes — not millions of certificates’ worth of data.

What Cloudflare is testing with Chrome (and why the fail-safe matters)

Cloudflare’s October 28, 2025 post is refreshingly candid: “Talk is cheap,” and the internet punishes untested protocol changes. Cloudflare says it plans to deploy MTCs experimentally in collaboration with Chrome Security, and that the goal is a transition to PQ authentication with no performance impact — potentially even a performance improvement compared to today. citeturn5view0

Google’s post clarifies the safety belt: during the experiment, every MTC-based connection is backed by a traditional trusted X.509 certificate, so users aren’t exposed to brittle new trust paths if something goes wrong. citeturn4view1

That dual-stack approach is a common pattern in cryptographic transitions: deploy new mechanisms in parallel, measure, iterate, and only then begin tightening requirements.

Security implications: what improves, what shifts, what becomes a new attack surface

1) Stronger resilience against future signature-forging

The primary win is straightforward: the ecosystem can adopt PQ signatures for authentication without making handshakes massive. Cloudflare frames it as making PQ certificates “cheap enough to deploy today by default for everyone.” citeturn5view0

2) Transparency becomes harder to bypass

Google argues that with MTCs, transparency is not an extra requirement enforced by browsers, but a property of the issuance model itself — “impossible to issue a certificate without including it in a public tree.” citeturn4view1

3) New reliance on out-of-band distribution

The biggest shift is operational: clients need access to recent tree heads/landmarks. That raises questions about update cadence, caching behavior, and how clients behave when they’re stale or offline.

Cloudflare acknowledges this and describes a fallback: MTC supports certificates that can be issued immediately and don’t require landmarks to be validated, but these are not as small. The idea is that servers provision both types so the common path is fast and the exceptional path is slow-but-works. citeturn5view0

4) “Middleboxes” and ecosystem brittleness

Even without direct access to the Ars article text (Ars blocks automated fetches), the theme is familiar: the internet contains many boxes that assume “TLS looks like X.” Whenever you change the shape of certificates, extensions, or handshake flows, some of those boxes panic. The MTC approach attempts to minimize handshake bloat, but it still introduces new structures and potential interoperability headaches.

5) Implementation security still matters (a lot)

Post-quantum algorithms may be mathematically strong while being tricky to implement safely. Side-channel resistance, constant-time code, and secure key handling remain critical. The industry has already seen research demonstrating side-channel risks against some PQ schemes in embedded contexts (for example, academic work analyzing side-channel leakage in Falcon implementations). The MTC architecture doesn’t eliminate that class of risk; it changes what has to run where and how often.

Industry context: the cloud providers are already getting their PQ houses in order

One reason this MTC push is credible is that it’s not happening in isolation. Major cloud providers have started offering standardized PQ algorithms in security products, especially for signatures (code signing, artifact signing, long-lived verification workflows) where “update later” is not always realistic.

For example:

  • AWS announced support for FIPS 204 ML‑DSA in AWS KMS (June 13, 2025), adding key specs such as ML_DSA_44/65/87. citeturn2search2
  • Google Cloud announced quantum-safe digital signatures in Cloud KMS (preview), aligning with NIST’s FIPS 204/205 direction and outlining a broader post-quantum strategy. citeturn0search1

That matters because deploying PQ authentication on the public web will require ecosystems of libraries, HSMs, KMS APIs, certificate tooling, and compliance frameworks. If the primitives aren’t widely available in mainstream platforms, the web can’t migrate — regardless of how elegant the protocol design is.

What web operators should do now (even if MTCs aren’t “mandatory” yet)

MTCs are in an experimental and standardization track, not a universal requirement today. But the web’s certificate ecosystem changes slowly, and the operational work tends to be the long pole. Here are pragmatic steps that pay off regardless of whether your organization adopts MTCs in 2027 or later.

1) Audit your certificate automation

Google’s post emphasizes ACME-only workflows as a direction for reducing complexity and ensuring agility. If you still have manual certificate issuance steps, the PQ era is a great time to stop treating that as “fine.” citeturn4view1

2) Inventory TLS termination points (yes, all of them)

Between load balancers, CDNs, service meshes, API gateways, and “temporary” appliances that became permanent, most organizations terminate TLS in many places. You’ll want a list of:

  • Where certificates are stored
  • Who renews them
  • What libraries validate them (OpenSSL, BoringSSL, NSS, custom stacks)
  • Which devices might be sensitive to handshake changes (IoT gateways, legacy proxies)

3) Watch the standards work (PLANTS) and vendor roadmaps

PLANTS is explicitly tasked with producing interoperable mechanisms for construction and consumption of these certificates, potentially extending PKIX and integrating with ACME and TLS as needed. If you operate at scale, you’ll want early visibility into what the drafts require. citeturn1search0

4) Prepare for parallel trust stores and transitional policy

Google is planning a Chrome Quantum-resistant Root Store operating alongside the existing root program. That suggests a multi-year era where “supported” may mean “supported in two different ways.” Security and compliance teams should anticipate policy complexity — and the need to keep both worlds healthy during the transition. citeturn4view1

Potential criticisms and open questions (because it’s the internet, and we love those)

MTCs are promising, but there are legitimate questions worth tracking:

  • How will clients stay up to date? Out-of-band distribution sounds easy until you consider offline devices, enterprise policies, and mobile constraints.
  • Who operates the logs/trees? Cloudflare’s design pushes toward each CA operating its own log; Google’s rollout involves CT log operators and later CA onboarding. The governance and reliability expectations will be intense. citeturn5view0turn4view1
  • What happens under partial adoption? If only some browsers, some CAs, or some CDNs support MTCs early, sites may need dual provisioning for a long time (which is manageable, but not free).
  • How will revocation evolve? Google explicitly mentions upgrading revocation communications and replacing legacy CRLs with streamlined requirements focused on key compromise events. That’s directionally good, but details will matter. citeturn4view1

Bottom line: a realistic path to quantum-safe web authentication requires changing the packaging, not just the algorithm

Post-quantum TLS discussions often focus on the cryptographic primitives: which KEM, which signature scheme, which parameters. But the real blocker for web-scale authentication is not just algorithm choice — it’s delivery economics. If PQ certificates make every handshake heavier, users and operators will push back, and the migration will stall until the threat is imminent (which is the worst time to migrate).

Google and Cloudflare’s MTC approach is a pragmatic attempt to keep the web fast while making authentication quantum-resistant. It leverages a structure the ecosystem already uses (Merkle trees in CT), formalizes it deeper into issuance, and sets a multi-year rollout plan that acknowledges the operational reality of the public web. citeturn4view1turn5view0turn1search0

Whether MTCs become the dominant post-quantum certificate format or merely an influential stepping stone, the direction is clear: the WebPKI is being redesigned for a world where signatures are expensive, bandwidth is precious, and attackers may one day bring quantum computers to a certificate fight.

Sources

Bas Dorland, Technology Journalist & Founder of dorland.org