Post-Quantum Signatures and the Next Shift in PKI Trust
Google published a proposal last month that may signal an interesting direction for the future of internet trust infrastructure.
Merkle Tree Certificates.
Read the announcement directly before continuing:
https://security.googleblog.com/2026/02/cultivating-robust-and-efficient.html
To understand why this matters, start with a number.
A typical RSA-2048 certificate chain, end-entity certificate, intermediate, and root, runs somewhere between 3,000 and 4,500 bytes. ECC P-256 brings that down to roughly 2,000 to 3,000 bytes. Those numbers have shaped how TLS handshakes are engineered for nearly two decades. They are baked into assumptions about connection overhead, throughput, and latency at scale.
Now look at ML-DSA-87, one of the post-quantum signature algorithms standardized by NIST in FIPS 204 (https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf).
The public key alone is 2,592 bytes.
The signature is 4,627 bytes.
A certificate chain using post-quantum signatures at each level is likely to land somewhere in the tens of kilobytes, often in the 15,000 to 25,000 byte range depending on encoding and chain depth.
That is five to eight times the size of the RSA chain it replaces.
And it lands inside every TLS handshake.
On every connection.
At scale.
That overhead is not theoretical. It becomes measurable latency and bandwidth cost. At modern internet traffic volumes, that cost compounds quickly.
Merkle Tree Certificates exist to address that problem.
Instead of transmitting a full chain of signatures during every handshake, the certificate itself is accompanied by a compact proof that it exists within a larger signed structure representing many certificates. A certificate authority signs a single Tree Head representing that population, and clients validate inclusion proofs rather than reconstructing a full chain of signatures.
The cryptographic strength remains.
The per-connection overhead drops dramatically.
The browser ecosystem appears to be exploring one possible direction.
The implications for enterprise PKI are harder to ignore.
What Is Actually Changing
This is not simply a performance optimization layered on top of existing PKI.
The unit of trust is changing.
Today, trust is expressed per certificate and per chain. A relying party validates a certificate because it chains to a trust anchor it already recognizes. The certificate is the artifact. The chain is the proof.
Under a Merkle Tree Certificate model, trust is expressed as membership in a signed set.
The CA is no longer attesting to an individual binding through a chain of signatures. It is attesting that a certificate exists inside a population represented by a signed tree head. The relying party validates a proof of inclusion in that population.
That difference is not cosmetic.
It changes how inventory works.
It changes how revocation works.
It changes how lifecycle management works.
That distinction changes what it means for organizations operating private PKI to maintain a governed trust posture.
The Timeline
Google is not describing a distant research concept.
The proposal includes a staged rollout with experimentation already underway.
That does not guarantee the ecosystem will follow this path. Standards processes still matter, and alternative approaches to post-quantum handshake overhead are actively being explored.
But browser vendors have historically had an outsized influence on the direction of internet trust infrastructure.
The last time Google signaled a major shift in certificate policy, reducing the maximum lifetime of publicly trusted certificates, the idea moved quickly from proposal to ecosystem change. Apple joined the push. Certificate authorities adjusted issuance policies. What began as a browser position eventually became part of CA/Browser Forum policy.
This proposal may or may not follow the same trajectory.
But it is a development worth watching.
Phase 1 introduces Merkle Tree Certificates in live internet traffic experiments, with every MTC connection backed by a traditional X.509 certificate as a failsafe. Cloudflare is participating in the initial deployment.
Google describes a Phase 2 target around Q1 2027. Certificate Transparency log operators with strong operational histories would begin supporting the infrastructure necessary for broader MTC deployment.
Phase 3 is described with a target around Q3 2027. Chrome would introduce a quantum-resistant root store operating alongside the existing Chrome Root Program.
These timelines suggest the browser ecosystem is exploring how such a model could operate in practice.
The Private PKI Carve-Out
One line in Google’s announcement deserves careful attention.
Google states that traditional X.509 certificates using quantum-resistant algorithms will remain supported for use in private PKIs that are not part of the Chrome Root Store.
That statement suggests the migration paths for public trust and private PKI may diverge.
Public internet trust may move toward models like Merkle Tree Certificates if the proposal gains adoption. Private PKI environments may continue operating traditional X.509 hierarchies using post-quantum algorithms.
The result is likely a bifurcated environment.
Public trust anchored in emerging structures such as Merkle Tree Certificates.
Private trust anchored in X.509 hierarchies, potentially using different cryptographic primitives.
For organizations whose systems interact with both environments, which is most organizations of meaningful size, the operational model becomes more complex.
Two trust models.
Two lifecycle strategies.
Two governance considerations running in parallel.
The Governance Questions This Shift Raises
Technical experimentation is moving quickly. Operational and governance questions tend to follow later.
Who inside an organization owns the evaluation of Merkle Tree Certificate readiness?
Is it the PKI team, if one exists as a defined function?
Is it the security architecture group?
Or does responsibility fall somewhere else?
What does certificate inventory look like across services that interact with publicly trusted endpoints?
Which of those systems might eventually interact with MTC-based validation models?
What does revocation look like in the current environment?
In traditional PKI, revocation is expressed through mechanisms like CRLs or OCSP responses tied to individual certificates.
In a Merkle tree model, revocation can become a function of tree updates and proof freshness rather than the status of an individual certificate. Removing a certificate from a population has different propagation characteristics than revoking it through existing status mechanisms.
A service that relies on publicly trusted certificates while also terminating internal traffic through private PKI does not get to choose which validation model applies. It inherits both.
If browsers begin preferring MTC-backed connections while internal systems remain anchored to traditional X.509 validation paths, organizations may find themselves operating two parallel validation models without realizing it until interoperability problems appear.
Load balancers, proxies, and inspection systems often implement their own certificate validation logic. If that logic assumes traditional chain validation, it may not evaluate proof-based trust models the same way browsers do.
These are operational questions worth thinking about early.
What This Is Not
This is not a reason to panic.
Google is intentionally rolling the proposal out in phases to reduce ecosystem risk. The Phase 1 failsafe, backing every Merkle Tree Certificate connection with a traditional X.509 certificate, exists precisely because an immediate cutover would break real systems.
This is also not the only possible solution to post-quantum handshake overhead. Certificate compression, hybrid signatures, and other optimizations remain active areas of research.
But Merkle Tree Certificates are one of the few approaches currently being explored with concrete implementation work and public deployment timelines.
Which makes it worth understanding before the ecosystem moves without you.
This is also not a problem confined to browser-facing services.
Trust architecture decisions in the public internet ecosystem tend to propagate. Certificate Transparency began as a browser enforcement mechanism and is now a foundational operational control across many enterprise PKI environments. Changes made for the public web rarely stay confined there.
The practitioners who understand those operational realities, inventory challenges, revocation gaps, and lifecycle complexity will likely play an important role in how these architectures evolve.
The trust model behind internet PKI continues to evolve.
The governance layer does not build itself.
Someone in every organization needs to understand what post-quantum PKI readiness means for their environment before the architecture makes that decision for them.
