Google rolls out Merkle Tree Certificates in Chrome

Google has begun rolling out a new way to deliver “quantum‑resistant” assurances for HTTPS certificates in Chrome, using what it calls Merkle Tree Certificates (MTCs). The approach, developed with Cloudflare, is meant to avoid a looming bandwidth problem: post‑quantum signatures that would replace today’s elliptic‑curve material can expand certificate-related data from roughly tens of bytes to about 2.5 kilobytes per connection, according to Ars Technica.

The immediate target is not the entire TLS handshake, but the plumbing that makes certificate transparency work at Internet scale. Modern browsers increasingly require TLS certificates to be logged in append‑only certificate transparency (CT) logs, so domain owners can detect mis‑issuance. CT was pushed into the mainstream after the 2011 DigiNotar compromise, which produced hundreds of fraudulent certificates, some used to spy on users in Iran. The weak point in a post‑quantum world is that an attacker with a sufficiently capable quantum computer could forge classical signatures used in CT log proofs, including the signed timestamps that tell a browser a certificate was logged when it wasn’t.

Google’s proposal changes what gets signed and what gets sent. Instead of shipping a long chain of signatures and proofs per certificate, a certification authority would sign a single “tree head” for a Merkle tree containing potentially millions of certificates. The browser receives a compact proof that a specific certificate is included in that tree, rather than a bulky bundle of signatures. Google says this lets it add post‑quantum cryptographic material—such as ML‑DSA—without forcing every connection to carry kilobytes of extra data. Cloudflare’s Bas Westerbaan told Ars that making certificates much larger risks slowing handshakes and breaking “middleboxes” that sit between browsers and servers; once users feel the slowdown, they tend to disable security features.

That tradeoff—cryptographic strength versus operational friction—is why the fight over “quantum‑proof HTTPS” quickly becomes a fight over who controls the transition. CT already depends on a small set of browser programs deciding what counts as a valid certificate and what must be logged. MTCs shift even more weight onto log structure and client policy: browsers must decide which tree heads to trust, how frequently to require updates, and what to do when proofs fail. Google is also framing the move as part of a “quantum‑resistant root store” that complements the Chrome Root Store it launched in 2022—another step in moving trust decisions from a diffuse CA ecosystem toward browser‑managed policy.

In the short term, the system is still being tested. Cloudflare is enrolling around 1,000 TLS certificates, and for now Cloudflare is generating the distributed ledger structure behind the proofs, with the expectation that certificate authorities will eventually take over. The Internet Engineering Task Force has formed a working group—PKI, Logs, And Tree Signatures—to standardise the building blocks.

For users, the promised experience is simple: no visible change, no extra latency, and better resistance to a future where classical public‑key signatures can be forged. The operational reality is that the same browser vendors who mandated certificate transparency after DigiNotar are now redesigning the mechanism that proves it.

Google’s first implementation runs in Chrome today, while the rest of the web’s trust infrastructure waits for CAs to start signing tree heads instead of certificates.