The WebPKI’s Post-Quantum Problem
The race to build a practical quantum computer presents a dual threat to Internet security. Beyond the well-known “harvest now, decrypt later” attack — where encrypted traffic is stored today and decrypted once a quantum computer exists — there is a second, equally serious concern: quantum computers could crack the signatures that authenticate TLS certificates, enabling impersonation of servers.
Post-quantum (PQ) algorithms already exist to address this. The catch is that they are dramatically larger than today’s standards. ML-DSA-44, a NIST-standardized PQ signature scheme, produces 2,420-byte signatures and 1,312-byte public keys, versus 64 bytes each for ECDSA-P256. With multiple keys and signatures exchanged per TLS handshake, the overhead climbs into tens of kilobytes — enough to measurably degrade performance. Deploying PQ certificates today, before Q-day arrives, means paying that cost for no immediate security gain.
Waiting is not an option. Migrations on the scale of the Web Public-Key Infrastructure (WebPKI) take years, and delaying until the threat is imminent risks the security of the entire Internet. The challenge, then, is to make PQ authentication cheap enough to become the default for everyone.
Introducing Merkle Tree Certificates
With industry partners, Cloudflare has brought a proposal to the IETF to redesign the WebPKI for a smooth transition to PQ authentication — one with no performance penalty and potentially even a net improvement. The centerpiece is a mechanism called Merkle Tree Certificates (MTCs). The goal is to strip the TLS handshake down to only the absolute minimum number of public keys and signatures required.
The core idea is to replace the current chain of certificates — each carrying its own public key and signature — with a single Merkle tree commitment. Instead of validating each certificate in a chain individually, a client can check one compact proof against a tree root that attests to the authenticity of the server’s key. This collapses the accumulated cryptographic material in a handshake to a near-constant size, regardless of how many certificates are involved.
A Practical Experiment
Theory only gets so far; changes to the Internet’s foundational protocols require real-world testing. Cloudflare knows from past experience with TLS 1.3 and Encrypted Client Hello that early deployment is essential. Today, the company is announcing its intent to deploy MTCs experimentally in collaboration with Chrome Security.
This experiment is designed to answer practical questions: how do MTCs behave under real traffic conditions, what integration issues surface, and does the performance story hold up outside a lab? The deployment will be scoped carefully to ensure safety, with both Cloudflare and Chrome monitoring for breakage and unintended side effects. The findings will guide next steps toward a broader rollout of PQ authentication — one that is fast enough to be the default, not just for those who can absorb the performance cost.
Why the TLS handshake keeps adding keys and signatures
At its base, TLS authentication is simple: a server proves its identity by signing the handshake messages with a secret key, and the client checks that signature against a public key it already knows. That would require just 1 signature per connection. But on a web with roughly a billion TLS servers, no client can be pre-provisioned with every server’s public key, and key rotation would make such a scheme unmanageable anyway.
So the WebPKI solves the scaling problem by introducing certificates. A certificate binds a server’s public key to its identity, and is itself signed by a Certification Authority (CA) whose key the client trusts. That adds +1 signature and +1 public key, for a total of 2 signatures and 1 public key per handshake.
The chains have grown longer since then. CAs rotate their own keys, and because updating trust stores across billions of clients takes time, they often bridge the gap by using the old key to issue a certificate for the new one, appending it to the chain. That brings the count to 3 signatures and 2 public keys.
Transparency comes at a cost
Certificate Transparency (CT) is the ecosystem’s answer to mis-issued certificates — ones a CA issues to someone who doesn’t control the domain, allowing impersonation. It works by requiring every CA-issued certificate to be added to a public log. Browsers like Chrome, Safari, and Firefox only trust certificates that appear in at least two logs they recognize.
That policy is easy to state but hard to implement. CT logs ingest billions of certificates, and under load or during incidents, entries may not be promptly available to auditors. Clients also can’t audit logs directly without revealing their browsing history to log operators. The compromise is that each log attaches a signature to the certificate, attesting that it will be included within 24 hours.
Those log signatures add +2 signatures — one per log — bringing a typical TLS handshake on the public web to 5 signatures and 2 public keys. That was acceptable when conventional signatures were cheap, but it will not survive the switch to larger post-quantum (PQ) signature algorithms.
Merkle Tree Certificates: batch signing replaces individual signatures
Merkle Tree Certificates (MTCs) is a proposal, currently implemented experimentally at Cloudflare, that rearranges where signatures live in the WebPKI. In MTC, everything a client needs to validate a certificate can be disseminated out-of-band. If the client is current, the TLS handshake needs only 1 signature, 1 public key, and 1 Merkle tree inclusion proof — a size that remains manageable even with PQ algorithms.
The core idea is that a Merkle Tree Certification Authority (MTCA) issues signatureless certificates in batches. Instead of a signature, each certificate carries an inclusion proof showing it is part of a batch. The MTCA arranges the unsigned certificates as leaves of a Merkle tree; each inner node is the hash of its children. To sign the batch, the MTCA signs only the tree head with its secret key. Any alteration to a leaf would change the tree head and invalidate the signature.
An inclusion proof is the sequence of sibling hashes along the path from a certificate to the tree head. With a validated tree head, that sequence proves the certificate is in the tree. The key efficiency is that signed tree heads can be fetched and validated offline by clients, then reused for any certificate in the corresponding batch.
During the handshake, the client tells the server which tree heads it already has. If the server holds a signatureless certificate covered by one of them, it can authenticate with just 1 signature, 1 public key, and 1 inclusion proof.
The full MTC specification is more elaborate than this simplified sketch. Instead of creating a separate Merkle tree per batch, it grows a single large tree for better transparency. Periodically, subtree heads — called landmarks — are selected and shipped to browsers. In the common case, browsers fetch the latest landmarks and servers wait for batch issuance. MTC also supports immediately issued certificates that don’t require landmarks for validation; these are larger and serve as a fallback. Servers provision both types, so the common path stays fast while the exceptional case remains functional.
Trialing MTCs Without Weakening Trust
Merkle Tree Certificates are still in the design phase, and the team behind the proposal is eager to test them in the real world. Following the IETF’s “running code” principle, they believe implementation is the best way to iron out design flaws. However, any experiment must not compromise user security. To that end, the plan is to test MTC components without altering any existing trust relationships.
The experiment is designed to answer several open questions:
- What breaks? Protocol ossification—where existing bugs make it hard to upgrade protocols—is a constant threat. TLS 1.3 rollout took years due to middleboxes rejecting unfamiliar traffic, and the recent post-quantum key exchange caused similar issues when Client Hellos split across packets. Testing MTCs in the wild will reveal whether they hit similar roadblocks.
- What is the performance impact? MTCs are expected to shrink the handshake compared to today’s non-PQ certificates. Since ML-DSA verification is roughly as fast as ECDSA and MTCs require fewer signatures, the hope is to measure a tangible latency reduction.
- How current will clients stay? MTCs are designed with short lifetimes—around a week. If a client’s newest landmark is older than that, servers would need to fall back to larger certificates. Tracking fallback rates will help tune MTC parameters to minimize that scenario.
The experiment will see MTC support added to the TLS stack and certificate issuance infrastructure on the server side, with Chrome handling the client side, including landmark dissemination infrastructure.
For the trial, MTCs will be enabled for a subset of free customers. Chrome will control the rollout, ramping up gradually, measuring results, and rolling back if bugs appear.
Bootstrap Certificates for the MTCA
Establishing a fully trusted Merkle Tree CA is a multi-year process. To avoid that lengthy timeline, the experiment will "mock" the MTCA role. The plan calls for running an MTCA (built on Workers and StaticCT logs), but for every MTC issued, the system will also publish a matching certificate from an existing, trusted CA—the bootstrap certificate.
Chrome’s infrastructure pulls updates from the MTCA log and checks these bootstrap certificates for agreement. Only if they match will Chrome push the corresponding landmarks to its clients. In effect, Cloudflare is merely re-encoding existing domain-validated certificates as MTCs, with Chrome using certificate transparency to verify the honesty of the process.
The Leap to Post-Quantum Certificates
About half of Cloudflare’s traffic is already protected by post-quantum encryption, but that’s the easier half. Migrating to post-quantum certificates is significantly more difficult. A straight swap for current certificates would hurt performance without adding any immediate security benefit before Q-day—a hard sell for default enablement.
Yet waiting is risky. Migrations take longer than anticipated, which is why a performant, default-eligible solution is needed today. MTCs aim to fill that gap by reducing the number of signatures and public keys to the minimum while retaining the WebPKI’s core security properties.
Rollout to a fraction of free accounts is planned for early next year. Visitors not part of the Chrome experiment will see no change; those in the experiment will benefit from the bootstrap certificate system, which maintains the same trust level.
