Google has unveiled a detailed roadmap to protect Chrome HTTPS certificates from post‑quantum attacks, centered on a new scheme called Merkle Tree Certificates (MTC). The approach, already under experimental deployment in Chrome and Cloudflare’s infrastructure, aims to deliver quantum‑resistant TLS without the severe performance penalties typically associated with post‑quantum cryptography.
Why post‑quantum TLS certificates threaten HTTPS performance
Today’s HTTPS ecosystem is built on X.509 certificates and cryptographic algorithms such as RSA and elliptic‑curve signatures (ECDSA). A typical browser–server certificate chain is compact—around 4 KB—allowing TLS handshakes to complete quickly, even over high‑latency or mobile networks.
Post‑quantum cryptography (PQC) changes this equation. Candidate algorithms like ML‑DSA (one of the digital signature schemes emerging from the NIST post‑quantum standardization process) use public keys and signatures that can be tens of times larger than current elliptic‑curve equivalents. For a full certificate chain, this can result in payloads that are roughly 40 times larger than today’s TLS certificate data.
Such growth directly impacts TLS handshake latency. Larger certificate chains mean more data must be transmitted and processed before an HTTPS connection is established, increasing page load times and degrading user experience. Cloudflare has observed in practice that slower handshakes can cause users—especially on constrained networks—to abandon secure connections or use less secure workarounds, which in turn increases security risk.
Oversized post‑quantum certificates also stress existing network infrastructure. Many middleboxes—such as firewalls, IDS/IPS systems, and legacy load balancers—are tuned for current TLS record sizes. Extremely large certificate chains can trigger bugs, timeouts, or outright failures in these devices, creating a compatibility and reliability problem on top of the performance issue.
How Merkle Tree Certificates reduce post‑quantum TLS overhead
To address these challenges, Google and Cloudflare propose moving from per‑certificate signatures to Merkle Tree Certificates, leveraging the well‑known Merkle tree data structure widely used in blockchains, transparency logs, and distributed storage systems.
Tree‑based PKI vs. classical X.509 chains
In the classical PKI model, each step in an X.509 certificate chain is individually signed and transmitted in full during every TLS handshake. With MTC, a certificate authority (CA) instead builds a very large Merkle tree where each leaf represents an individual certificate. The tree’s root hash—called the Tree Head—is then signed once using a post‑quantum digital signature algorithm.
When a browser connects to a website, the server does not transmit the entire chain with large PQC signatures. Instead, it sends the site’s certificate plus a compact proof of inclusion in the Merkle tree. This proof consists of a logarithmic number of hashes that allow the browser to verify that the certificate is covered by the signed Tree Head, without needing the full tree or repeated large signatures.
This design effectively decouples cryptographic strength from data size. Even when using “heavyweight” post‑quantum signatures, the total TLS certificate data that must be sent during the handshake can be kept close to today’s benchmark of about 4 KB. For users, that means post‑quantum‑safe HTTPS with minimal impact on page load performance and far fewer compatibility issues with legacy network equipment.
Chrome Quantum‑resistant Root Store (CQRS) and quantum‑safe PKI
To support Merkle Tree Certificates at scale, Google is introducing a dedicated Chrome Quantum‑resistant Root Store (CQRS). This new root store will exist alongside, rather than replace, the existing Chrome Root Store.
A key policy decision is that CQRS will not accept traditional X.509 certificates using post‑quantum signatures. In the Chrome ecosystem, quantum‑resistant certificates will initially be supported only in the MTC format. This avoids a proliferation of incompatible certificate formats, simplifies trust management, and allows Chrome to apply consistent, predictable security policies to quantum‑safe certificates.
Deployment roadmap, Cloudflare pilot, and IETF PLANTS
Field testing of Merkle Tree Certificates in Chrome is already under way, with Cloudflare operating around one thousand TLS certificates using MTC on live traffic. For now, Cloudflare maintains the experimental MTC logs, but over time this role is expected to move to independent certificate authorities and Certificate Transparency (CT) log operators.
Google’s rollout plan comprises three phases:
Phase 1 (in progress): joint Google–Cloudflare research and experimentation. This phase assesses performance, compatibility, and robustness of MTC‑based TLS, including effects on handshake latency, certificate size, and behavior of middleboxes.
Phase 2 (Q1 2027): onboarding of existing and new CT log operators to host public MTC logs. Transparent logging is essential for detecting mis‑issued quantum‑resistant certificates and maintaining accountability in the post‑quantum PKI ecosystem.
Phase 3 (Q3 2027): finalizing technical and policy requirements for certificate authorities seeking inclusion in CQRS. At this stage, the quantum‑resistant certificate ecosystem for Chrome is expected to open to a broader range of PKI providers.
Coordination across the industry is being led by the IETF PLANTS (PKI, Logs, And Tree Signatures) working group. Its mandate is to define standards and protocols for Merkle‑tree‑based signatures and related mechanisms so that quantum‑resistant certificate schemes can be adopted not only by Chrome, but also by other browsers, operating systems, and enterprise security solutions.
The transition to post‑quantum cryptography is moving from theory to large‑scale engineering. Organizations operating public websites or internal PKI should begin by inventorying current cryptographic algorithms, monitoring browser and CA requirements, and testing post‑quantum and hybrid solutions in controlled environments. Preparing early for quantum‑resistant TLS—through architecture reviews, performance testing, and vendor engagement—reduces the risk of a “cryptographic cliff” where legacy algorithms are no longer acceptable, yet infrastructure cannot yet support quantum‑safe certificates at scale.
