Quantum-Safe Certificates: How ML-DSA Is Bloating the Web's Trust Chain

Key exchange got the headlines, and it earned them. The session key your browser negotiates today is already hybrid. But a key exchange only protects the conversation. The thing that tells your browser the server really is your bank is a certificate signature, and that signature still rests on RSA or ECDSA, both of which a large enough quantum computer could forge. Replacing those signatures with ML-DSA is the harder job, and Chrome and Windows are where it stops being a whitepaper.

Before you read: The NIST standards and the ‘store now, decrypt later’ threat are covered in The Quantum Time Bomb: Why NIST’s New Encryption Standards Can’t Wait. The browser key exchange rollout is in Your Browser Already Went Quantum-Safe. This piece is about the other half: the signatures.

Table of contents

• Forgery Runs on a Different Clock
• The Passenger Gets Heavier
• The Anti-Amplification Trap
• Chrome’s Escape Hatch: Merkle Tree Certificates
• Windows Has to Speak It Too
• Where the Migration Stalls
• Sources

Forgery Runs on a Different Clock

Key exchange has a retroactive threat. Record the traffic today, decrypt it in 2035. Signatures don’t work that way. A forged certificate only matters at the moment it is used to impersonate a server, which means an attacker needs a working quantum computer at that moment, not a decade earlier. That makes the deadline look later, and that is exactly the trap. Nobody gets fired for postponing an authentication migration, right up until the day someone needs to break it.

The Passenger Gets Heavier

A TLS certificate is basically two things: a public key, and a signature from whoever vouched for it. Classic ECDSA P-256 keys are 64 bytes and its signatures land around 70. ML-DSA-44, the smallest NIST parameter set, ships a 1,312-byte public key and a 2,420-byte signature. ML-DSA-65 climbs to 1,952 and 3,309 bytes. The envelope is the same size as before. Someone swapped the postage stamp for a shipping crate.

Did you know that an ML-DSA-44 public key plus its signature comes to about 3,700 bytes? The RSA-2048 pair they replace is 512. That is roughly seven times the payload for the same job.

A real chain has at least a leaf and an intermediate, and each carries its own key and its issuer’s signature. One ML-DSA-44 leaf is already more than 3 KB before you count names and extensions. Add an intermediate and the chain passes 6 KB before the server has said anything useful.

The Anti-Amplification Trap

QUIC has a rule meant to stop servers from being abused as traffic cannons for spoofed packets. Until a client’s address is validated, a server may send no more than three times the bytes it received. A client’s first packet is at least 1,200 bytes, so the server gets about 3,600 bytes to answer before it has to wait. Classic certificate chains fit in that budget. ML-DSA chains do not, and the handshake stalls for another round trip (RFC 9000, section 8.1).

Certificates were always the most dramatic part of a TLS handshake. Now they are also the heaviest, and round trips are the one thing the internet cannot buy more of by laying more fiber.

Chrome’s Escape Hatch: Merkle Tree Certificates

The obvious fix is to keep X.509 and swap the algorithm. The less obvious fix, which Cloudflare and Chrome have been testing in public experiments, is Merkle Tree Certificates. Instead of every certificate carrying its own signature, a CA batches certificates into a large tree and signs only the root, on a schedule. The server then sends an inclusion proof: the sibling hashes that link its certificate to that root. For a tree with about two billion entries, that is 31 hashes of 32 bytes, around a kilobyte, with no per-certificate ML-DSA signature in sight.

Here is a fun fact that makes the design feel less exotic: Certificate Transparency logs, which the web already depends on, are built on the same kind of Merkle tree (RFC 6962). The idea is not a stranger to the web’s plumbing.

The catch is trust. The browser now has to accept a new kind of object, and Chrome’s root program becomes the gatekeeper for which trees count. I think this is where the migration turns political. Whoever defines the post-quantum trust object decides who can issue certificates for the next twenty years.

The clock is already moving. Under CA/Browser Forum ballot SC-081, maximum validity for public TLS certificates drops to 200 days on March 15, 2026, then to 100 days in 2027 and 47 days by 2029. Shorter lifetimes mean more issuance, more signatures, and more chances for a heavy ML-DSA chain to land in your logs. Forty-seven days sounds like a sensible number until you realize it is a renewal roughly every six weeks, forever.

Windows Has to Speak It Too

Windows’ crypto stack, CNG, dates to Windows Vista in 2007, and Microsoft has been adding post-quantum primitives to it, including ML-KEM and ML-DSA, through 2025 updates to Windows 11 and Windows Server. Having the algorithm in the library is the easy part. The certificate chains a company actually runs are a different story: internal PKI, Active Directory Certificate Services, smart cards, driver signing, VPN appliances. Each has its own parser, its own assumptions about key sizes, and a vendor that ships firmware once a year if you are lucky.

Anyone who has watched an internal certificate expire on a Friday afternoon already knows how this goes. Nobody has a complete list of every certificate their company issued, and the spreadsheet that claims to be that list is always wrong.

Where the Migration Stalls

The easy critique of ML-DSA is that it is fat. The harder critique is that the alternatives are not clean either. Falcon, being standardized as FN-DSA, produces signatures around 660 bytes at its smallest level, which would fix much of the bloat. But Falcon’s signing depends on floating-point arithmetic, and constant-time floating point is exactly the kind of detail that goes wrong on small embedded chips. SLH-DSA, the hash-based option in FIPS 205, is conservative and well understood, yet its smallest signatures run close to 8 KB. Every option buys you something and charges you somewhere else.

My honest take: the first wave of ML-DSA certificates will be large, slow, and mostly invisible, living in private PKI and in firmware that never gets updated. The public web will probably get through it, thanks to Merkle trees and shrinking lifetimes. The smart thermostat on your wall will not, and that is the part nobody is budgeting for.

Sources

• NIST FIPS 204, Module-Lattice-Based Digital Signature Standard (ML-DSA), August 2024: public key and signature sizes for ML-DSA-44 and ML-DSA-65
• NIST FIPS 205 (SLH-DSA) and draft FIPS 206 (FN-DSA, based on Falcon)
• RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport, section 8.1 (address validation and the 3x amplification limit)
• RFC 6962, Certificate Transparency (Merkle tree hash construction)
• CA/Browser Forum Ballot SC-081: maximum certificate validity reduction schedule
• Chrome and Cloudflare Research publications on Merkle Tree Certificates and post-quantum certificates (2025)
• Microsoft Windows Developer Blog and Windows release notes on CNG post-quantum algorithms (2025)
• Microsoft documentation on CNG (Cryptography API: Next Generation), introduced with Windows Vista (2007)