On PQC Certificates
Uncharted Territory of PQC: Quantum Certificates
A field briefing on post-quantum TLS, certificate size, Merkle Tree Certificates, and the fork forming between the Web PKI and private PKI — written for professionals entering the industry, by someone who has to make these decisions for a living.
This blog explains where post-quantum certificate infrastructure actually stands today. It is written for people new to the field who need a working mental model before they make their first design decision on a production system.
We cover four things in order. First, why the industry moved on key exchange before it moved on signatures, and why that is not the same problem solved twice. Second, the concrete arithmetic of certificate and handshake size under classical, lattice-based, and Merkle Tree Certificate schemes, with corrected numbers and worked examples. Third, the new operational dependencies — landmark distribution, DNS-based discovery, dual-certificate serving — that nobody fully solved before announcing a roadmap. Fourth, a five-year outlook on where the Web PKI, private PKI, and the algorithms underneath them are likely to diverge, and what that divergence will cost the people running infrastructure.
The themes here are not new. Every cryptographic transition this industry has lived through — DES to AES, MD5 to SHA-2, RSA to ECC — eventually exposed the same lesson: the math is rarely the hard part. We will return to that point throughout.
1. Why Key Exchange Moved First
1.1 The Threat Model Is Asymmetric, and That Asymmetry Drove the Roadmap
Post-quantum migration did not arrive as one project. It arrived as two projects running at different speeds, because the two halves of TLS face different clocks.
Key exchange protects confidentiality. An adversary who records encrypted traffic today and later acquires a cryptographically relevant quantum computer (CRQC) can decrypt that traffic retroactively, because the session key was derived from a key exchange that a CRQC can break after the fact. This is the "harvest now, decrypt later" threat, and it is live today — traffic captured this afternoon is already at risk for whatever its confidentiality window turns out to be. If you operate infrastructure that protects secrets with a shelf life longer than "however many years until a CRQC exists," you have already lost some of those secrets to an adversary patient enough to wait.
Authentication protects integrity, and integrity does not have the same retroactive failure mode. A signature forged after the fact is useless to an adversary that needed to forge it during a live handshake, three years ago, to impersonate a server in real time. You cannot harvest a signature today and use it to retroactively convince a 2023 client that it was talking to a legitimate server. The signature problem only matters once a CRQC actually exists and is used live against a connection happening then.
Confidentiality is broken by a future attacker reading something recorded in the past. Authentication is broken by a present attacker forging something used right now. A CRQC arriving in year N breaks all key exchanges recorded since day one. It only breaks signatures created from year N onward. This is the single fact that explains the entire shape of the current migration.
This is why the industry's immediate deployment focus is the hybrid key exchange X25519MLKEM768, and not certificate signature replacement. It is also why this is correct prioritization rather than an arbitrary choice.
1.2 What X25519MLKEM768 Actually Is, and What It Requires
X25519MLKEM768 is a named group for TLS 1.3 key exchange, standardized through the IETF TLS working group, that concatenates an X25519 elliptic-curve Diffie-Hellman exchange with an ML-KEM-768 key encapsulation exchange. The hybrid approach combines both mechanisms so that the session key is derived from both exchanges — if either algorithm is broken, a classical attack on ML-KEM or a CRQC applied to X25519, the session remains secure because the other exchange is still sound. The IANA codepoint is 0x11ec.
Three things make this deployable immediately, in a way certificate signature migration is not:
- No certificate management. Key exchange happens fresh, in-band, on every handshake. The server does not need a certificate that says "I support ML-KEM" — it just needs a TLS stack that offers the named group. There is no chain of trust to rebuild, no CA to involve, no root store to update.
- No interoperability cliff. A hybrid group degrades gracefully. If one side does not support it, the connection falls back to a classical group. Nothing breaks; you simply do not yet have post-quantum protection on that connection.
- Already shipped. X25519MLKEM768 is the default for Chrome 131+, Firefox 132+, and Edge 131+, accounting for roughly 95% of post-quantum TLS traffic observed today. Server-side, OpenSSL 3.5, NGINX, HAProxy, and the JDK 27 early-access builds all carry support, the last enabling it by default so that TLS clients offer both a hybrid X25519MLKEM768 key share and a traditional x25519 key share without requiring any application code changes.
You can, in fact, turn this on today, on a server you control, and the next browser visit will very likely use it. That is rare in this industry. Treat it as the easy half of the migration, not the whole migration.
1.3 What This Hybrid Does Not Address
It is worth being precise about scope, because vendors are not always precise about scope when they say "post-quantum ready."
- It does not protect authentication. The server's certificate is still signed with ECDSA or RSA. A CRQC that exists at connection time can still forge that signature and run a live man-in-the-middle attack, hybrid key exchange notwithstanding. Confidentiality and authenticity are independent properties; this migration only buys you the first.
- It does not address signed software, code-signing, or document signatures, all of which depend on the same vulnerable signature algorithms and have their own, separately unaddressed harvest-now risk for long-lived artifacts.
- It is not "quantum-proof." ML-KEM is a newer algorithm with a shorter public cryptanalytic record than X25519. The hybrid construction exists specifically because confidence in ML-KEM alone is not yet considered sufficient by the IETF for general deployment during this transition period. You are buying defense in depth against two different failure modes, not certainty against either.
- FIPS compliance has a wrinkle. In the U.S. FIPS validation regime, ML-KEM is FIPS-approved but X25519 is not, which makes SecP256r1MLKEM768 — not X25519MLKEM768 — the strictly FIPS-compliant hybrid, and Chrome does not ship that variant by default. If you are in a regulated environment, check which named group your compliance posture actually requires before assuming "we enabled PQC" closes that box.
The remainder of this paper is about the half of the problem this hybrid does not touch: certificate signatures, and the size, infrastructure, and governance consequences of replacing them.
2. A Short History of "The Last Time We Did This"
Anyone surprised by the current confusion has not been paying attention to how every previous cryptographic transition in this industry actually went. A brief recap, because the present moment rhymes with all of it.
2.1 DSA and the Early X.509 Era
X.509 itself dates to 1988, designed for a world of small, centrally-issued directories, not a billion-endpoint public internet. DSA, standardized by NIST in 1994, was itself a product of a contentious, multi-year standardization process with public disputes over patent claims and design rationale — the pattern of "the algorithm exists before the deployment story does" is not new.
2.2 The RSA-to-ECC Transition Took Over a Decade, and Most of the Delay Was Not Cryptographic
NIST recommended elliptic curve cryptography as early as the late 1990s, and ECC offered smaller keys and faster operations than RSA at equivalent security levels from the start. Yet RSA remained the dominant Web PKI signature algorithm well into the 2010s. The holdup was never "is ECC secure" — it was: hardware support in embedded devices, legacy client compatibility, certificate authority tooling, patent uncertainty around specific curve implementations, and the simple fact that nobody wants to be the first CA to issue a certificate type half the internet cannot validate. ECC adoption accelerated only once browsers, then CAs, then enterprise software all independently decided the compatibility risk had become acceptable — a coordination problem, not a math problem.
2.3 Certificate Transparency Was Bolted On, Not Designed In
Certificate Transparency (CT), and the Signed Certificate Timestamps (SCTs) every TLS handshake now carries, exist because the CA ecosystem suffered real, damaging mis-issuance incidents that public logging was retrofitted to detect. CT was not part of the original X.509 design; it is a patch, applied after the trust model already existed, and it shows: SCTs add bytes to every handshake to solve a governance problem the original certificate format never anticipated. This matters directly to our topic, because Merkle Tree Certificates are explicitly designed to fold CT into issuance from the start rather than bolt it on afterward — a deliberate correction of this exact historical mistake.
In every prior transition, the new algorithm was technically ready years before the ecosystem was operationally ready. The gap was always filled with patches — hybrid modes, transparency logs, deprecation timelines — bolted onto a system that was not designed to anticipate them. We are watching this happen again, in real time, with PQC certificates. The useful skill is not predicting which algorithm wins; it is recognizing which operational dependency is about to get bolted on next.
3. The Size Problem, With Correct Numbers
3.1 Reference Sizes for Classical and Post-Quantum Signature Schemes
Before doing handshake arithmetic, fix the per-algorithm numbers. These are the values specified in FIPS 204 for ML-DSA, and standard reference values for the classical algorithms.
| Algorithm | Security Level | Public Key (bytes) | Signature (bytes) |
|---|---|---|---|
| ECDSA P-256 | ~128-bit classical | 64 | 64 |
| ECDSA P-384 | ~192-bit classical | 96 | 96 |
| RSA-2048 | ~112-bit classical | 256 | 256 |
| ML-DSA-44 | NIST Level 1 (≈128-bit) | 1,312 | 2,420 |
| ML-DSA-65 | NIST Level 3 (≈192-bit) | 1,952 | 3,293 |
| ML-DSA-87 | NIST Level 5 (≈256-bit) | 2,592 | 4,627 |
A few things jump out immediately. Going from ML-DSA-44 to ML-DSA-87 — the natural choice if you actually want 256-bit-class assurance rather than the minimum NIST level — roughly doubles both public key and signature size again, on top of an already roughly 20-to-40-times increase over ECDSA. Almost every public size comparison you will find online quotes ML-DSA-44 numbers, because it is the smallest option, and that quietly understates the cost of higher-assurance deployments. If your organization's risk posture calls for ML-DSA-65 or ML-DSA-87 — and several signals below suggest serious institutions are heading exactly there — multiply the size problem accordingly before you trust a vendor's slide that only shows Level 1 figures.
3.2 What a TLS 1.3 Handshake Actually Needs to Authenticate a Server
To authenticate a server, the client must validate, at minimum:
- A leaf certificate: the server's public key, signed by the intermediate CA.
- Two or more SCTs: each one a signature from a CT log operator, attesting the leaf certificate was logged.
- An intermediate certificate: the intermediate's public key, signed by the root CA.
- A transcript signature: the server's live signature over the handshake transcript, proving possession of the leaf private key — this is what actually authenticates this connection, as opposed to the certificate, which only authenticates the binding between identity and public key.
So the inventory of cryptographic material crossing the wire is: 1 leaf public key + 1 transcript signature + 2 SCT signatures + 1 intermediate public key + 1 intermediate signature (by the root) + 1 leaf-certificate signature (by the intermediate) — that is 2 public keys and 5 signatures, 7 cryptographic objects in total. This matches the figure independently reported in coverage of Let's Encrypt's roadmap announcement: a typical TLS handshake today transmits about 1,248 bytes of authentication data across five signatures and two public keys.
3.3 Worked Arithmetic: Classical Algorithms
Using a P-256 leaf under a P-384 intermediate, the numbers check out:
Leaf public key (P-256): 64
Transcript signature (P-256): 64
2 × SCT signature (P-256): 128
Intermediate public key (P-384): 96
Intermediate→root signature (P-384): 96
Leaf signature, by intermediate: 96
-----
Total: 544 bytesFor an all-RSA-2048 chain, with 7 objects at 256 bytes each: 1,792 bytes. Real-world chains are frequently mixed, so the 544-to-1,792-byte range is a reasonable bound for what the Web PKI costs today in pure authentication material, excluding TCP/TLS record overhead.
3.4 Worked Arithmetic: ML-DSA-44
Checking the structure: 2 public keys (leaf + intermediate) and 5 signatures (transcript, 2 SCTs, intermediate-by-root, leaf-by-intermediate) is exactly right, structurally. The arithmetic: 2 × 1,312 = 2,624, and 5 × 2,420 = 12,100. Sum: 2,624 + 12,100 = 14,724 bytes. The independent figure from industry coverage of Let's Encrypt's announcement lands at the same order of magnitude: replacing today's roughly 1,248 bytes of authentication data with ML-DSA-44 would push that figure past 14,700 bytes.
The consequence is concrete and worth stating in absolute terms. A standard Ethernet MTU is 1,500 bytes. A single round of ML-DSA-44 authentication material alone is roughly ten Ethernet frames. The initial TCP congestion window on many stacks (10 segments, per RFC 6928) is barely enough to carry this handshake's authentication data, before you even add the ML-KEM-768 key exchange material, the TLS record headers, extensions, or anything else. This is not a rounding error. It is a structural problem for TLS as currently engineered, which is exactly why the industry did not simply ship ML-DSA into existing X.509 chains and call the problem solved.
3.5 Higher Assurance Levels Make This Worse, Not Better
If you redo this arithmetic at ML-DSA-65 (2 × 1,952 + 5 × 3,293 = 20,369 bytes) or ML-DSA-87 (2 × 2,592 + 5 × 4,627 = 28,319 bytes), the picture deteriorates further. This is the comparison the industry's size discussions mostly skip, and it is exactly the comparison an organization choosing a long-lived root CA key needs to make, because root keys are typically provisioned for the highest assurance level the organization can justify, not the cheapest one.
4. Merkle Tree Certificates: What They Actually Buy You
4.1 The Core Idea
Under the Merkle Tree Certificate model, a Certification Authority signs a single "Tree Head" representing potentially millions of certificates, and the certificate sent to the browser is a lightweight proof of inclusion in that tree. Instead of paying a full signature's cost for every single certificate, you pay it once, for an entire batch, and every certificate in that batch carries only a small, logarithmically-sized proof that it belongs to the batch the CA already vouched for.
This is the single design idea behind every number improvement described below, and it generalizes a tool the industry already trusts: it is the same Merkle-tree inclusion-proof construction that underlies Certificate Transparency itself, applied to the certificate's own existence rather than bolted on afterward as a separate log.
4.2 Standalone MTCs
A standalone MTC needs: 1 transcript signature (2,420 bytes at ML-DSA-44), 1 public key (1,312 bytes), 1 inclusion proof (384 bytes, for the specific tree depth assumed), and 2 or more co-signatures from independent witnesses (2 × 2,420 = 4,840 bytes). Total: 2,420 + 1,312 + 384 + 4,840 = 8,956 bytes.
This is meaningfully better than 14,724 bytes — a roughly 39% reduction — but it is still over sixteen times the size of the 544-byte classical baseline. The co-signatures are still the dominant cost, because a standalone MTC still has to convince the client, on the spot, that the witnesses actually vouched for this particular tree head.
4.3 Landmark-Relative MTCs
The improvement comes from removing the co-signatures from the live handshake entirely. Replacing per-certificate signatures with compact hash-based inclusion proofs, the architecture shrinks quantum-resistant TLS authentication data from roughly 14,700 bytes down to as little as 736 bytes. If the client already trusts a recent landmark — a periodically co-signed tree head it obtained out of band, independent of this specific connection — the server need only send a transcript signature, a public key, and an inclusion proof relative to that already-trusted landmark.
The numbers — 2,420 + 1,312 + 736 = 4,468 bytes — are internally consistent with this model and with the 736-byte figure reported as Google's headline result for the landmark-relative case. Note that the 736-byte inclusion proof assumes a specific landmark cadence (hourly, on the order of millions of certificates per landmark, roughly 23 hashes deep); change that cadence and the proof size moves logarithmically, not linearly, so this number is sensitive to operational choices CAs haven't all finalized yet.
| Scheme | Auth Bytes | Multiple of Classical (544 B) |
|---|---|---|
| ECDSA P-256 / P-384 chain (classical baseline) | 544 | 1× |
| RSA-2048 chain | 1,792 | 3.3× |
| Traditional X.509, ML-DSA-44 throughout | 14,724 | 27× |
| Standalone MTC, ML-DSA-44 | 8,956 | 16.5× |
| Landmark-relative MTC, ML-DSA-44 | 4,468 | 8.2× |
4.4 The Honest Framing: MTCs Are an Enormous Improvement and Still Not Free
8.2 times the byte cost of a classical handshake is genuinely good engineering, given the constraint that one must use a NIST-standardized post-quantum signature somewhere in the chain. It is not, however, "as small as classical," and treating it as solved would be premature. Every operational dependency described in Section 5 exists specifically to make that 736-byte number achievable in practice, and none of those dependencies are fully built yet.
5. The Bill Nobody Itemized Yet
Reducing a number on a slide and operating a working system at internet scale are different achievements. Here is what landmark-relative MTCs actually require, none of which is optional if one wants the 4,468-byte figure rather than the 8,956-byte fallback.
5.1 Issuance Delay
Landmark-relative MTCs are signed in batches against a periodic landmark, not on demand. That means certificate issuance is no longer instantaneous in the way a same-day Let's Encrypt ECDSA certificate is today. The industry has not yet published hard numbers on what that delay will be in production; "assume it's short" is a reasonable working assumption for now, but it is an assumption, not a specification, and anyone designing automated certificate issuance pipelines (ACME-style, just-in-time, ephemeral) needs to track this number specifically as it firms up.
5.2 Landmark Discovery Without an Extra Round Trip
A client needs to know, before it connects, which landmark a given server's certificate chain will be relative to — different CAs produce different landmarks, the way different root programs trust different root certificates today. Discovering this by asking the server first would cost an extra round trip on every connection, which defeats much of the size win. The mechanism the industry has converged on for this is TLS Trust Anchor Identifiers, advertised via the tls-trust-anchors parameter on HTTPS or SVCB DNS records, so the client can compute the intersection between its configured trust anchors and the server's available ones before initiating the handshake at all.
This is a real new dependency. SVCB and HTTPS DNS record types (RFC 9460) are still inconsistently supported across resolvers, stub libraries, and middleboxes. If an organization's DNS infrastructure does not yet resolve and parse these record types reliably, that is now squarely in scope for any PQC migration plan.
5.3 Servers Need to Support Both Standalone and Landmark-Relative Certificates, Simultaneously
A server cannot assume every client presents a fresh landmark. Clients may have no landmark at all, or an outdated one the server no longer recognizes. The fallback is the standalone MTC — full cost, co-signatures included. That means a production server needs both certificate types provisioned and live at once, plus the logic to atomically pick the right one per ClientHello, plus the operational discipline to rotate and renew both in sync. This roughly doubles the certificate-management surface area compared to a single-certificate world, and it is new complexity, not a simplification, however good the best-case byte count looks.
5.4 Landmark Freshness Becomes an Operating-System-Level Problem
Landmarks function as trust anchors — conceptually adjacent to today's root certificate bundle, except landmarks expire and rotate on a much shorter cycle (the example cadence cited above is hourly). Browsers already have infrastructure for pushing frequent updates to internal trust data; most other TLS clients — embedded devices, IoT firmware, language-runtime TLS stacks, command-line tools, internal microservices — do not, and rely on trust bundles that today are updated rarely, sometimes only at OS or package upgrade time.
Making landmark-relative MTCs work universally implies something close to an OS-level or distribution-level landmark-updating service, running continuously, for every platform that wants the smaller certificate. Google's rollout deliberately keeps the Chrome Quantum-resistant Root Store as an addition alongside, not a replacement for, the existing Chrome Root Store — a sensible hedge, but one that also signals Google itself is not assuming this problem is solved outside the browser. Nobody has published a detailed design for "landmark updates for everything that isn't a browser." That is a gap, and it is worth tracking who fills it.
5.5 The Bifurcation Risk This Creates
Put 5.2 through 5.4 together, and we get a real risk: browsers — practically, a small number of major browser vendors — solve landmark freshness and discovery for themselves, because they control the update channel and the DNS-aware infrastructure to do it. Everything else — libraries, embedded TLS stacks, internal service mesh implementations, IoT — falls back to standalone MTCs or, worse, stays on classical certificates because nobody ships them a landmark updater. The current rollout phases place initial bootstrapping and CA onboarding for the quantum-resistant root store on a 2027 timeline, run by a small number of organizations setting the technical direction for everyone else. That concentration of design authority is a legitimate governance concern independent of whether the cryptography itself is sound, and it is worth professionals entering this field forming their own view on it rather than treating it as someone else's problem.
6. Where the Industry Is Actually Going
6.1 MTC Adoption, With Current Commitments
On June 3, 2026, Let's Encrypt — the nonprofit certificate authority that secures more than 500 million websites — published its post-quantum roadmap and named Merkle Tree Certificates as its chosen path, targeting a staging environment that issues MTCs in late 2026 and a production-ready environment in 2027. This is the single most consequential adoption signal to date, because Let's Encrypt issued 54.4% of all public SSL/TLS certificates in Q1 2026, meaning its adoption of MTCs essentially makes the standard viable for the majority of the encrypted web, independent of what any other CA decides to do.
Google has stated it has no immediate plan to add traditional X.509 certificates containing post-quantum signatures to the Chrome Root Store, and will instead use a new Chrome Quantum-resistant Root Store and corresponding Root Program that only supports MTCs. Field testing is already under way, with Cloudflare operating roughly one thousand TLS certificates in the experiment, and phase two is planned for Q1 2027, inviting Certificate Transparency log operators that already had a usable log in Chrome before February 1, 2026, to help bootstrap public MTCs, with the CA onboarding framework for the new root program targeted around Q3 2027.
The CA/B Forum — the body that, in principle, sets baseline requirements across the entire commercial CA industry — has, by contrast, moved markedly slower. As of this writing there is no MTC-specific baseline requirement; participant commentary so far amounts to early-stage investigation. This is a real asymmetry in the industry's governance, not a rhetorical flourish: a handful of browser-and-CDN organizations are setting de facto technical direction faster than the cross-industry standards body that nominally governs Web PKI baseline requirements.
6.2 ML-DSA Adoption Is Moving on a Separate, Slower, and More Conservative Track
While MTCs target the public Web PKI, ML-DSA itself is being adopted directly — full X.509 certificates, no Merkle tree — in contexts where certificate size matters less than algorithm assurance and where the client population is small and controlled.
Google is adding native ML-DSA support for private PKI use in Chrome, separate from and faster-moving than its public Web PKI plans, which remain MTC-only. Microsoft has signaled support for ML-DSA certificates in CA/B Forum discussions, reportedly leaning toward ML-DSA-87 — the highest, most conservative, and largest-byte-cost security level, consistent with an enterprise posture that prioritizes assurance margin over the byte-count concerns driving the public web's MTC push. The CA/B Forum's Baseline Requirements for S/MIME already permit ML-DSA, ahead of the Web-PKI baseline requirements, which do not yet.
The financial sector has built its own dedicated infrastructure rather than wait: a new X9 Financial PKI, operated by DigiCert, with ML-DSA support built in from the start. This is a sector with both the regulatory mandate and the resources to build bespoke PKI rather than wait for Web PKI consensus, and it has chosen straightforward ML-DSA X.509 certificates over MTCs — a different calculus than Google's, made by a different industry with different constraints (closed client populations, regulatory certainty requirements, less sensitivity to a few extra kilobytes per handshake).
6.3 The Structural Split, Stated Plainly
The public Web PKI is converging on Merkle Tree Certificates, driven by Google, Cloudflare, and Let's Encrypt, optimizing for handshake size at internet scale with an open, heterogeneous client population. Private PKI — enterprise, financial-sector, S/MIME — is converging on direct ML-DSA X.509 certificates, optimizing for implementation simplicity and assurance level, in contexts where the client population is closed and controlled and a few extra kilobytes per connection is an acceptable price.
These are not competing proposals where one will eventually win. They are two different answers to two different constraint sets, and both are likely to persist. That has a direct, practical consequence: TLS and HTTPS stacks going forward will need to correctly implement and select between multiple X.509-adjacent certificate formats, not migrate cleanly from one format to a single successor. Budget engineering time accordingly.
7. Five Years Out: A Forecast, Not a Promise
Treat everything in this section as informed extrapolation from current trajectories, not certainty. Cryptographic migrations have a long history of running later than announced, and PQC certificates are unlikely to be the exception.
Key Exchange Will Be Fully Post-Quantum By Default, Broadly
Hybrid key exchange is cheap, already deployed at scale, and has no certificate-management dependency. Expect near-universal default-on hybrid key exchange across major browsers, CDNs, and server software well before the certificate-signature problem is anywhere close to resolved. This part of the migration is genuinely close to done.
The Public Web PKI Will Be Mid-Transition to MTCs, Not Finished
Given the Q3 2027 target for CA onboarding into Chrome's quantum-resistant root program, and the multi-year history of every prior CA ecosystem transition (the ECC migration took over a decade; CT enforcement took years to reach universal logging), expect partial MTC deployment by major CDN-fronted sites, with the long tail of the Web PKI still on classical or transitional certificates. Full MTC ubiquity in five years is optimistic; meaningful MTC presence among the highest-traffic sites is realistic.
Private PKI Will Have Moved Faster, and More Unevenly, Than the Public Web
Financial services, defense, and other regulated sectors with mandate-driven timelines and controlled client populations will likely have completed ML-DSA migrations for new infrastructure well before the Web PKI's MTC rollout matures, simply because their constraint set is simpler: no anonymous client population, no DNS-discovery problem, often no requirement to interoperate with arbitrary external software.
Landmark Distribution Will Be the Long Pole, and Possibly the Source of the Next Visible Failure
Watch specifically for whether non-browser TLS clients — package managers, IoT firmware, internal service meshes, embedded libraries — get a credible landmark-update mechanism. If they don't, by year five expect either widespread silent fallback to standalone MTCs or, in the worst case, a security incident traceable to stale landmark data being trusted past its intended freshness window. This is the single most under-specified piece of the entire architecture today, and it is worth professionals tracking closely rather than assuming someone else has it handled.
SVCB/HTTPS DNS Record Support Will Become a Quiet Prerequisite for PQC Readiness
Organizations that have not modernized their DNS infrastructure to reliably serve and resolve these record types will find that gap blocking landmark discovery, independent of how ready their TLS stack otherwise is. This is exactly the kind of unglamorous dependency that derails migration timelines, the same way legacy hardware TLS termination quietly delayed the RSA-to-ECC transition for years in some sectors.
The Web PKI and Private PKI Will Not Re-Converge Within Five Years
The constraint sets driving MTCs (public, open, byte-sensitive) and direct ML-DSA (private, controlled, assurance-sensitive) are structural, not incidental, and nothing on the current roadmap suggests they merge. Expect the bifurcation Section 6.3 describes to be a permanent feature of the landscape professionals in this field need to know how to navigate, not a temporary transitional artifact.
8. What This Means Practically
For someone entering information security today, a few concrete, actionable takeaways, separate from the forecasting above:
- Enable hybrid key exchange now. It is low-risk, already supported broadly, and addresses a live threat (harvest-now-decrypt-later) that is accruing cost every day we delay. There is no good reason for a production TLS server to not be offering
X25519MLKEM768today. - Do not conflate "we enabled hybrid key exchange" with "we are post-quantum ready." Authentication is still classical almost everywhere. Be precise about which half of the problem any given deployment has actually addressed when we report status upward.
- If you operate DNS infrastructure, start testing SVCB/HTTPS record support now. This dependency is easy to deprioritize because it looks unrelated to cryptography, and that is exactly why it will be underestimated until it becomes a blocker.
- If you are choosing a security level for a long-lived key (root CA, code-signing, anything provisioned for a decade or more), do the size arithmetic at ML-DSA-65 or ML-DSA-87, not just ML-DSA-44. Most public comparisons quote the smallest, cheapest option; your risk tolerance for a long-lived key is probably not the smallest, cheapest option.
- Track Let's Encrypt's staging MTC environment as the most concrete, observable bellwether. A nonprofit CA issuing the majority of public certificates committing to a late-2026 staging timeline is a far more reliable signal of real progress than any vendor announcement.
- Remember Shamir's observation, because it will be true again here. The largest practical risk in this entire transition is probably not a cryptographic break. It is operational complexity — dual-certificate handling, stale landmarks, misconfigured DNS, a fallback path nobody tested — creating a bypass that has nothing to do with whether ML-DSA or MTCs are mathematically sound.
Cryptography is typically bypassed, not penetrated.
— Adi ShamirQuick Reference Glossary
| Term | Definition |
|---|---|
| Harvest now, decrypt later | Recording encrypted traffic today to decrypt retroactively once a quantum computer capable of breaking the key exchange exists. |
| ML-KEM | Module-Lattice-Based Key Encapsulation Mechanism, FIPS 203, the NIST-standardized post-quantum key exchange algorithm used in hybrid TLS groups. |
| ML-DSA | Module-Lattice-Based Digital Signature Algorithm, FIPS 204, the NIST-standardized post-quantum signature algorithm, formerly CRYSTALS-Dilithium. |
| Hybrid key exchange | A TLS key exchange combining a classical algorithm (e.g. X25519) with a post-quantum one (e.g. ML-KEM-768), so security holds if either alone is broken. |
| SCT | Signed Certificate Timestamp; a signature from a Certificate Transparency log attesting a certificate was publicly logged. |
| Merkle Tree Certificate (MTC) | An experimental certificate format in which a CA signs one tree head covering many certificates, and each certificate is authenticated by a compact inclusion proof rather than its own full signature. |
| Landmark | A periodically co-signed MTC tree head that a client has already obtained and trusts, allowing a server to send only a small inclusion proof relative to it instead of full co-signatures. |
| PLANTS | The IETF working group ("PKI, Logs, And Tree Signatures") standardizing the MTC specification. |
| SVCB / HTTPS DNS records | RFC 9460 DNS record types allowing a server to advertise service parameters — including, via TLS Trust Anchor Identifiers, which certificate trust anchors it supports — before a TLS handshake begins. |
| CQRS | Chrome Quantum-resistant Root Store, Google's planned new Chrome root program supporting only MTCs. |
References
[1] JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3. OpenJDK. openjdk.org/jeps/527
[2] Kwiatkowski, K., Kampanakis, P., Westerbaan, B.E., Stebila, D. Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3. IETF Internet-Draft, draft-ietf-tls-ecdhe-mlkem. datatracker.ietf.org
[3] Hybrid key exchange in TLS 1.3. IETF Internet-Draft, draft-ietf-tls-hybrid-design. datatracker.ietf.org
[4] NIST. FIPS 204: Module-Lattice-Based Digital Signature Standard. nvlpubs.nist.gov
[5] Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-DSA. IETF Internet-Draft, draft-ietf-lamps-dilithium-certificates. ietf.org
[6] Google Develops Merkle Tree Certificates to Enable Quantum-Resistant HTTPS in Chrome. The Hacker News, March 2026. thehackernews.com
[7] Merkle Tree Certificates: Rethinking the WebPKI for the Post-Quantum Era. Encryption Consulting. encryptionconsulting.com
[8] Google's Merkle Tree (MTC) Gambit to Quantum-Proof HTTPS. postquantum.com, April 2026. postquantum.com
[9] Let's Encrypt Commits to Merkle Tree Certificates. postquantum.com. postquantum.com
[10] A Post-Quantum Future for Let's Encrypt. Let's Encrypt, June 3, 2026. letsencrypt.org
[11] Google And Cloudflare Pilot Merkle Tree Certificates To Secure Chrome HTTPS Against Post-Quantum Attacks. cybersecurefox.com, March 2026. cybersecurefox.com
[12] Google tests Merkle Tree Certificates for quantum web. securitybrief.com.au, March 2026. securitybrief.com.au
[13] Beck, et al. TLS Trust Anchor Identifiers. IETF Internet-Draft, draft-ietf-tls-trust-anchor-ids. datatracker.ietf.org
[14] Hybrid Key Exchange Today: Why X25519 + ML-KEM Is the Interim Default. netguardia.com, April 2026. netguardia.com
[15] Post-Quantum TLS 1.3 in Production: Deploying X25519+ML-KEM-768 with OpenSSL 3.5, NGINX, and HAProxy. systemshardening.com, May 2026. systemshardening.com
[16] Schwartz, B., Bishop, M., Nygren, E. Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). RFC 9460, November 2023.
This paper reflects the state of post-quantum certificate infrastructure as publicly documented as of June 2026. Several of the timelines cited are vendor-stated targets, not delivered milestones. Treat dates beyond the current quarter as subject to revision, consistent with the historical pattern this paper describes in Section 2.