Google’s Merkle Tree (MTC) Gambit to Quantum-Proof HTTPS

28 Feb 2026 – Google will not put post-quantum signatures into traditional X.509 certificates for Chrome. Instead, the company announced in February 2026 a fundamentally different architecture – Merkle Tree Certificates (MTCs) – that shrinks quantum-resistant TLS authentication data from roughly 14,700 bytes down to as little as 736 bytes, making post-quantum HTTPS potentially smaller than today’s classical certificate chains. The approach, developed jointly with Cloudflare and now being standardized through the IETF’s newly formed PLANTS working group, integrates Certificate Transparency directly into the issuance process, replaces per-certificate signatures with compact hash-based inclusion proofs, and proposes an entirely new Chrome Quantum-resistant Root Store (CQRS) that accepts only MTCs.

If it succeeds, this could define how billions of TLS connections authenticate in the post-quantum era – but it also concentrates significant power in browser vendors and leaves non-browser clients navigating an uncertain path.

The signature size crisis that forced Google’s hand

Post-quantum key exchange is already deployed at scale. Roughly half of Cloudflare’s traffic uses ML-KEM, adding only ~2 KB to handshakes. Post-quantum signatures, however, remain the hard unsolved problem for TLS certificates.

A typical TLS handshake today transmits five signatures and two public keys across the certificate chain and Certificate Transparency SCTs – totaling about 1,248 bytes of authentication data. Replacing these with NIST-standardized ML-DSA-44 (FIPS 204) would balloon that figure to 14,724 bytes (five signatures at 2,420 bytes each, plus two public keys at 1,312 bytes each). That represents an ~12× increase that pushes well past TCP’s initial congestion window of roughly 14.5 KB, triggering additional round trips that Cloudflare’s empirical measurements show can cause 60%+ slowdowns in TLS handshake latency.

Google’s own threshold analysis frames the problem starkly: adding ~2 KB to TLS handshakes is “very painful, but plausible”; adding ~7 KB is “implausible unless a cryptographically relevant quantum computer is tangibly imminent.” No currently standardized post-quantum signature scheme can stay under 7 KB for a full TLS certificate chain. ML-DSA-65 pushes past 20 KB. SLH-DSA (SPHINCS+), the hash-based fallback if lattice cryptography fails, adds tens of kilobytes per signature. As security researcher David Adrian put it bluntly: “We should not be sending over 1% of a 3.5-inch floppy disk purely in signatures and public keys.“

Compounding the size problem is a parallel regulatory tightening that most enterprises are only beginning to reckon with. The CA/Browser Forum’s Ballot SC-081v3 sets a schedule that shrinks maximum publicly trusted TLS certificate validity from today’s 398 days to 200 days (starting March 15, 2026), then 100 days (March 2027), and ultimately 47 days (March 2029) – with domain validation data reuse periods tightening to just 10 days by the end of that timeline. Shorter lifetimes mean more frequent issuance, which means paying the PQ overhead tax more often. For CT logs, it means storing and mirroring dramatically more entries per year. The combination of larger certificates and higher issuance velocity is what makes a naive PQ drop-in not merely painful but potentially unsustainable at internet scale.

How Merkle Tree Certificates actually work

The core insight behind MTCs is architectural: instead of every certificate carrying its own large post-quantum signature, a Certification Authority signs a single cryptographic commitment (the Merkle tree head) representing potentially millions of certificates at once. The “certificate” transmitted during a TLS handshake is then just a compact proof of inclusion in that tree – a chain of hash values logarithmic in tree size.

The IETF draft defines five roles – authenticating party (TLS server), CA, relying party (browser), cosigners (mirrors and witnesses), and monitors – and operates through two certificate types that offer different tradeoffs:

Landmark certificates are the efficiency breakthrough. Periodically (roughly every hour), the CA designates certain tree sizes as “landmarks.” The corresponding subtree hashes are pre-distributed to browsers out-of-band, much as browser updates deliver root certificates today. When a client already possesses the relevant landmark hash, the TLS server presents a signatureless certificate containing only the inclusion proof – a sequence of sibling hashes from leaf to root. For a batch of ~4.4 million certificates, this proof is just 23 hashes × 32 bytes = 736 bytes. No signature at all travels over the wire. The proof grows only logarithmically: even a tree of 4.3 billion certificates requires just 1,024 bytes.

Standalone certificates serve clients whose landmarks are stale. These carry the inclusion proof plus cosignatures from the CA and external cosigners (mirrors that independently verify the log’s append-only property). They’re larger but still far more compact than a naive PQ X.509 chain. A standalone certificate anchored to a checkpoint covering ~2,500 entries requires only 12 hashes (384 bytes) plus the cosignatures.

The CA’s post-quantum signature exists only once, on the tree head checkpoint – and critically, Google and Cloudflare have indicated this will use a hybrid approach combining classical and post-quantum algorithms (e.g., ECDSA + ML-DSA), so an attacker would need to break both to forge a tree head. Because batched signing means the CA’s hardware security module signs infrequently, the computational cost of expensive PQ signing operations becomes negligible. And crucially, as Cloudflare’s engineering analysis details, log entries store hashes of public keys rather than the full keys themselves, achieving a 100× size reduction for post-quantum log entries compared to storing full PQ keys – a property that keeps the transparency infrastructure manageable even as algorithm sizes grow.

A critical clarification, given the discussion this announcement has generated: MTCs do not replace or bypass NIST-standardized post-quantum algorithms. ML-DSA still signs the tree head checkpoints. The cryptographic primitives are standard. What changes is purely architectural – how those signatures are applied (once per batch, not once per certificate) and how the resulting trust is distributed to clients (via compact Merkle inclusion proofs rather than serialized signature chains). Google is not charting a proprietary cryptographic course; it is redesigning the plumbing that delivers standardized cryptography to billions of browsers without choking the pipes.

Certificate Transparency becomes a first-class protocol property

One of MTCs’ most elegant features is how they handle Certificate Transparency. Today, CT is bolted onto certificate issuance: CAs send certificates to independent third-party logs, which return Signed Certificate Timestamps (SCTs) that browsers verify. This works, but it adds overhead to every TLS handshake (two SCT signatures), creates a separate attack surface (SCTs use classical signatures vulnerable to quantum forgery), and has proven difficult to enforce for non-browser clients.

MTCs invert this model. Because the CA certifies entries by logging them, the act of signing a checkpoint constitutes certification of everything in the tree, transparency is a fundamental, structural property of issuance rather than an afterthought. It becomes impossible to issue a certificate without including it in a public, auditable tree. Monitors watch the CA’s issuance log directly, and cosigners (external mirrors and witnesses) independently verify the log’s append-only behavior before cosigning checkpoints.

This eliminates two separate problems simultaneously. First, it removes the SCT signatures from the TLS handshake entirely, further reducing transmitted data. Second, it closes the quantum vulnerability in today’s CT system, where Shor’s algorithm could forge SCTs to make browsers believe a rogue certificate has been logged when it hasn’t. David Benjamin, the lead author of the IETF draft, described the design philosophy at the Chromium CT policy group: “Merkle Tree Certificates integrates CT into the certificate issuance process, rather than bolting it on after the fact.“

Three phases toward a quantum-resistant Chrome Root Store

Google’s rollout plan proceeds in three phases, each progressively shifting trust from classical X.509 to MTCs:

Phase 1 (underway since early 2026) is a live feasibility study conducted jointly with Cloudflare. Approximately 1,000 TLS certificates have been enrolled. Cloudflare is operating in a “mock MTCA” role – it re-encodes existing certificates from trusted CAs as MTCs and publishes them in a tiled transparency log built on Cloudflare Workers. Every MTC-based connection is backed by a traditional X.509 certificate as a fail-safe, allowing Chrome to measure real-world performance without risking security. Chrome is already shipping preliminary MTC support. As of Feb 2026, Google’s security blog confirms that this feasibility study remains ongoing, with no reported issues in real-world performance measurements.

Phase 2 (targeted Q1 2027) will invite existing CT Log operators – specifically those with at least one “usable” log in Chrome before February 1, 2026 – to bootstrap the public MTC infrastructure. Google’s rationale is that these organizations already possess “the operational excellence and high-availability infrastructure required to run global security services,” and the architectural similarities between CT logs and MTC issuance logs make them natural operators.

Phase 3 (targeted Q3 2027) will launch the Chrome Quantum-resistant Root Store (CQRS), a separate, purpose-built trust store that supports only MTCs. It will operate alongside the existing Chrome Root Store during the transition. Sites will be able to opt into “downgrade protections” ensuring they serve only quantum-resistant certificates. Google also plans to support traditional X.509 certificates with PQ algorithms, but only for private PKIs – not in the Chrome Root Store.

Alongside MTCs, Google is proposing sweeping modernization of certificate practices: ACME-only workflows for all issuance, a revocation framework focused solely on key-compromise events (replacing legacy CRLs), “reproducible” Domain Control Validation where proofs are publicly verifiable, and a shift from annual third-party audits to continuous, externally verifiable monitoring.

How MTCs compare to every other PQ signature approach

The landscape of potential solutions highlights why Google chose MTCs despite their complexity:

Composite certificates – bundling classical and PQ signatures in a single X.509 cert — are the most mature alternative, nearing RFC status in the IETF LAMPS working group. They work as drop-in replacements for existing infrastructure. But at 17–20 KB overhead per TLS handshake, they exceed Chrome’s viability threshold by a wide margin. Cloudflare’s testing found “steep increases in client and middlebox failures” past 10 KB.

FN-DSA (Falcon/FIPS 206), with 666-byte signatures at Level 1, is the most compact draft-standardized PQ signature scheme – 3.6× smaller than ML-DSA-44. But as Cloudflare’s analysis of PQ signature candidates details, its signing algorithm requires floating-point arithmetic that is extremely difficult to implement without timing side channels, making it better suited for infrequent CA-level signing than high-volume leaf certificate issuance. A full FN-DSA chain still adds 5–8 KB.

KEMTLS elegantly eliminates the handshake signature by using KEM-based authentication, but requires changes to the TLS state machine and CAs issuing certificates with KEM keys rather than signature keys – infrastructure that doesn’t yet exist.

Intermediate certificate suppression (browser-side preloading of known intermediates) is the most deployable near-term optimization, saving roughly 4–5 KB per handshake. Firefox already preloads over 1,400 intermediate CA certificates. This is likely to coexist with MTCs as a transitional measure.

The bottom line is that no standardized drop-in PQ signature scheme can meet Google’s 7 KB viability threshold for a full TLS certificate chain with CT. MTCs sidestep the problem entirely by architectural innovation rather than algorithmic improvement.

The centralization debate and non-browser blind spots

The most substantive criticism of MTCs centers on what they mean for the broader internet ecosystem beyond Chrome. A widely cited comment from Hacker News user “crote” captures the concern: “It worries me how we are increasingly making browser vendors a critical part of the TLS ecosystem – first with CRL bloom filters, now with signature Merkle trees. […] How are we supposed to use this in curl, or in whatever HTTP library your custom application code is using? How about email clients? Is it even possible with embedded devices? ‘The internet’ is a hell of a lot bigger than ‘some website in Google Chrome’…”

The concern is structurally valid. Landmark certificates require clients to regularly fetch tree head updates through an out-of-band channel – trivial for an auto-updating browser, difficult for command-line tools, embedded systems, or IoT devices. The IETF draft itself acknowledges this, stating MTCs “are not intended to replace existing PKI mechanisms” and that servers “SHOULD additionally provision certificates from another PKI mechanism, such as X.509.” Bas Westerbaan of Cloudflare suggested that operating systems could populate tree heads at the system level (“there is no reason that we can’t have a system service populating /etc/ssl/treeheads, which openssl can read”), but this requires OS-level infrastructure that doesn’t exist yet.

Enterprise middleboxes represent an immediate, practical threat to deployment. Corporate networks are riddled with TLS inspection proxies, next-generation firewalls, and data loss prevention appliances that are hardcoded to parse and validate standard X.509 certificate chains. MTCs fundamentally alter the structure of what travels inside a TLS handshake. Unless security vendors update their inspection engines to understand the IETF PLANTS specification – and enterprises update the firmware – Chrome traffic using MTCs could break silently or be blocked outright. For security teams that depend on TLS inspection for compliance and threat detection, this isn’t an abstract concern; it’s a procurement and vendor management problem that needs to land on roadmaps now.

Issuance latency introduces a new operational constraint for DevOps teams. In traditional PKI, a CA can sign and deliver a certificate in milliseconds. Under the MTC model, certificates are issued in batches: the CA accumulates requests, builds the tree, and signs the checkpoint periodically. Depending on the batch window, this could introduce delays of minutes to hours between requesting a certificate and receiving one anchored to a signed landmark. Organizations running microservice architectures that spin up ephemeral containers with just-in-time certificates may need to rethink their issuance workflows, pre-provisioning certificates or maintaining parallel X.509 issuance for latency-sensitive cases.

Privacy and fingerprinting represent another real concern. During TLS negotiation, the client must communicate which tree heads it possesses so the server can select the right certificate type. Without Encrypted ClientHello (ECH), this information is visible to any network observer and can fingerprint clients by how recently they fetched updates. Westerbaan acknowledged the issue but argued the leakage would be “minimal, perhaps only a minute or two” for a client that was briefly offline.

Ecosystem pace is also contentious. InfoQ reported a Let’s Encrypt engineer estimating 10–15 years for full ecosystem rollout due to OS, distribution, and client update cycles. Google’s Phase 3 timeline of Q3 2027 for the CQRS is aggressive – it essentially tells the CA industry that if they want Chrome trust for PQ certificates, MTCs are the only path.

The revocation model remains partially defined. Traditional CRLs and OCSP don’t map cleanly to the MTC architecture. Google proposes focusing revocation only on key-compromise events with index-based revocation (revoking by log entry index without needing certificate details). Cryptographer Phillip Hallam-Baker pushed for more sophisticated revocation integration using Bloom filters or revocation trees in the Chromium CT policy discussion, but the current design takes a more minimalist approach.

What this means for the post-quantum migration

Google’s MTC initiative represents the clearest signal yet that the post-quantum transition for web authentication will not be a simple algorithm swap. The Web PKI – which evolved over decades of incremental patches, from MD5 to SHA-256, from RSA-1024 to ECDSA – faces a discontinuity where the old approach of embedding progressively stronger signatures in X.509 certificates simply doesn’t scale.

The path forward is almost certainly a split ecosystem: MTCs for browser-to-server HTTPS authentication (where the browser’s update channel provides the infrastructure for tree head distribution), and composite or FN-DSA-based X.509 certificates for enterprise PKI, S/MIME, VPNs, code signing, and other non-browser contexts. Intermediate suppression and trust anchor negotiation will serve as bridging mechanisms during the transition. For enterprises running private PKIs – internal application meshes, Active Directory Certificate Services, device authentication – Google itself signals that standard X.509 with PQ algorithms remains the appropriate path. An internal gigabit network doesn’t care about 15 KB certificates.

But for any organization whose business depends on customer-facing web services, the operational pressure is already arriving – and it’s not MTCs. It’s the certificate automation imperative created by the CA/Browser Forum’s lifetime reductions. By March 2029, every public TLS certificate will need renewal at least every 47 days, with domain validation data reusable for just 10 days. Organizations that can rotate certificates fast are the ones that can migrate cryptography fast when the quantum deadline arrives. Update cadence is becoming a core security control – not just an IT operations metric – and the enterprises that internalize this now will be best positioned regardless of whether their external PKI ultimately runs on MTCs, composite certificates, or something not yet invented.

The IETF PLANTS working group (established after a successful BoF at IETF 124 in Montreal) provides a multi-stakeholder standardization venue, preventing this from being purely a Google-driven specification. The team behind the draft – David Benjamin and Devon O’Brien from Google, Bas Westerbaan and Luke Valenta from Cloudflare, and independent cryptographer Filippo Valsorda – bridges the key players in web infrastructure.

But the fundamental tension persists: MTCs are optimized for a world where browsers mediate trust, receive frequent updates, and maintain background connections to transparency services. This works for Chrome’s 3+ billion users. For the rest of the internet’s TLS consumers – from Python scripts to smart fridges – the post-quantum signature problem remains conspicuously open. Google has chosen to solve the problem where it can, for the users it can reach, with the architecture it controls. Whether that creates a blueprint or a schism for the broader ecosystem will likely take the better part of a decade to resolve.