The trick isn’t a smaller algorithm. MTCs change how certificates are issued, so that most signatures disappear from the handshake instead of being shrunk.

In our post on quantum-safe key exchange in TLS, we left authentication aside. Encryption was the urgent half, as harvest-now-decrypt-later attackers can record traffic today and decrypt it later. Authentication is different, since it can only be attacked during a live handshake, so nothing recorded today becomes vulnerable afterwards.

That doesn’t make it a secondary concern. Once a cryptographically relevant quantum computer exists, an attacker can recover a website’s private key to impersonate that site, or a CA’s private key to impersonate any site. Even a site with a post-quantum certificate is exposed, as long as browsers still accept classical ones. And once authentication falls, confidentiality follows, because an attacker who can impersonate the server can sit in the middle and read everything, post-quantum key exchange or not.

Changing the Web PKI takes years, which is why the migration is being prepared now rather than on Q-day, the day such a quantum computer arrives.

This fifth and final post in our PQC series looks at MTCs, currently the most plausible path to a quantum-safe Web PKI, and measures what they cost compared with simply switching every signature to a post-quantum scheme.

The weak spot of this model is that browsers trust over a hundred CAs, and any one of them can issue a valid certificate for any domain. Your site is then only as secure as the weakest CA, and incidents have already happened. In 2011, the Dutch CA DigiNotar was compromised and issued hundreds of fraudulent certificates, including one for *.google.com, and the only reason it got caught is that Chrome had pinned the keys Google’s certificates were supposed to use.

To fix this, Certificate Transparency (CT) was introduced in 2013. The idea is that CAs record every certificate they issue in public, append-only logs, so that anyone can see every certificate ever issued for a domain, spot the rogue ones and hold the CA accountable. And to make sure it actually happens, browsers like Chrome and Safari only accept a certificate if it carries signed proofs, called SCTs, from at least two independent logs.

Put together, a typical TLS handshake today carries five signatures and two public keys:

• the root CA’s signature on the intermediate certificate
• the intermediate CA’s signature on the server certificate
• two SCTs, the signed promises from CT logs that the certificate was logged
• the server’s signature on the handshake (CertificateVerify)

The two public keys are the server’s and the intermediate’s. The root’s key isn’t sent, since the browser already has it, and the same goes for the CT logs’ keys.

The problem is that all of these still rely on RSA or elliptic curves, which a cryptographically relevant quantum computer breaks. So the obvious fix is to swap each of them for a post-quantum one, and that’s what we tried first.

For the classical side, we built our chain like most websites have it today, with the CAs using P-384, and the server key and the CT logs using P-256. On the post-quantum side, we used ML-DSA-44 everywhere, as it offers the same 128-bit security level as P-256. But as the table shows, its keys are about 20 times bigger, and its signatures almost 40 times bigger.

The size clearly explodes. With ML-DSA-44, the handshake goes from 5.7 KB to 21.2 KB, almost four times the ECDSA one. Almost all of it comes from the TLS Certificate message, which carries the whole chain and grows from 1.7 KB to 13.5 KB with ML-DSA-44, as the two certificates and the two SCTs now each carry a 2,420-byte signature.

Time is where it gets more interesting. ECDSA takes 47 ms, but ML-DSA-44 jumps to 65 ms, a whole extra round trip. The cryptography isn’t to blame here, as signing and verifying with ML-DSA only costs a few milliseconds of CPU. It comes from TCP’s initial congestion window, which by default stops each side from sending more than 10 packets, about 14 KB, on the first round trip (RFC 6928), to avoid overloading the network. With ECDSA the server’s response easily fits, but with ML-DSA-44 it’s already close to 20 KB, so the server has to wait for the client to acknowledge the first packets before sending the rest, and that costs one more round trip. That’s a step back, since TLS 1.3 was designed to complete the handshake in a single round trip, where TLS 1.2 needed two.

And it isn’t only about a few milliseconds. Bigger handshakes have also been shown to break things on the way, as Cloudflare saw a steep increase in client and middlebox failures once certificate chains grew by more than 10 KB. ML-DSA-44 adds more than 15 KB. We already saw this with post-quantum key exchange, when some servers and middleboxes reset the connection because the ClientHello no longer fit in a single packet. Browsers are just as cautious. Back in 2024, the Chrome team found adding around 2 KB to the handshake “very painful, but plausible”, and around 7 KB “implausible unless a cryptographically relevant quantum computer is tangibly imminent”.

That’s why, for the public web, this path is not the one being taken. Chrome has no immediate plan to add post-quantum X.509 certificates to its root store, and will only support them in private PKIs. Browsers and CAs are betting on something else, which is to get rid of most of the signatures.

This structure has a nice property, as proving that a certificate is in the tree only takes a few hashes, called an inclusion proof, which stays at a few hundred bytes even for millions of certificates.

The CA then signs parts of this tree, and independent cosigners, running a mirror of it, add their own signature, so the CA can’t show a different tree to different people. Every so often, for example every hour, one of these signed parts is picked as a landmark and sent to browsers ahead of time. A certificate covered by a landmark then only needs to carry its small proof, and no signature at all. And since the tree is public, issuing a certificate already means logging it, so Certificate Transparency comes for free.

For browsers that don’t have the latest landmarks yet, a fallback approach called standalone certificate exists. In that case, the certificate carries the signatures itself, from the CA and the cosigners, along with its inclusion proof. A new certificate is also sent this way at first, since it has to wait for the next landmark to reach browsers. That’s why the draft recommends renewing a certificate 75% of the way through its lifetime, so that the new one is already covered by a landmark when the old one expires.

Each browser decides how many cosignatures it requires, both on the landmarks it receives ahead of time and in every standalone certificate. Chrome’s draft policy currently asks for at least two, one from the CA and one from an independent mirror, both in ML-DSA-44.

To know which certificate to send, the server relies on the browser, which lists what it trusts in its first message, using the Trust Anchor Identifiers extension. This list contains both the landmarks it already has and the CAs it accepts standalone certificates from. If one of the landmarks covers the certificate, the server sends the small landmark version, otherwise it falls back to a standalone one from a CA the browser supports.

So we connected to it in order to benchmark the cost of MTCs. All connections were established using a post-quantum secure key exchange, and unlike our previous measurements, this is a live server hosted in China, which explains the longer handshake durations.

The landmark certificate is the smallest of the three, and even smaller than today’s X.509 one, just as Let’s Encrypt announced. Since it carries no signature at all, its certificate drops to about 470 bytes, and the whole handshake shrinks from 7.8 KB with the classical X.509 certificate to 4.8 KB. The standalone certificate is another story. Trustasia uses three ML-DSA-44 signatures, one from the CA and two from cosigners, so the certificate alone weighs 7.3 KB and the handshake reaches 12.5 KB.

These numbers come with three caveats. First, the X.509 handshake is bigger here than in our lab, 7.8 KB instead of 5.7 KB. The browser’s ClientHello is about 480 bytes bigger, as it carries a few more extensions, including the Trust Anchor Identifiers, 186 bytes on their own, which recent Chrome versions send by default, even without MTCs. But above all, the server sends three certificates instead of two, since Trustasia’s root is cross-signed by an older and more widely trusted RSA root. Then, Trustasia issues so few MTC certificates that each one is alone in its part of the tree, so its inclusion proof is empty. On a real CA, the draft estimates it at 384 bytes for a standalone certificate and 736 bytes for a landmark one. Finally, its standalone certificates carry three signatures, where Chrome’s draft policy only requires two.

On time, however, the three are almost identical, between 610 and 623 ms, which is about two round trips. Even with the standalone certificate, the server’s response stays around 9.3 KB, below the 14 KB of the initial congestion window, so it never needs the extra round trip we saw with ML-DSA in our lab.

However, the numbers aren’t post-quantum yet, because the handshake signature is still ECDSA. In every MTC certificate we found in the Trustasia and Let’s Encrypt logs, the server’s key is ECDSA. That’s expected since the CA/Browser Forum Baseline Requirements only allow RSA and ECDSA keys today, and Chrome’s draft policy lists ML-DSA only as optional.

Our measurements still let us estimate what a fully post-quantum deployment would weigh. We swapped the server’s ECDSA key for ML-DSA-44, added the draft’s inclusion proofs, and kept only the two signatures Chrome requires on standalone certificates. A landmark handshake would then reach about 9.1 KB, and a standalone one about 14.1 KB. In both cases, the server’s response would fit in the initial congestion window.

This means the Let’s Encrypt quote only fully holds as long as the server key stays ECDSA. Once it moves to ML-DSA, even a landmark handshake ends up bigger than today’s classical one.

The design itself also raises a privacy question. Since landmarks don’t reach every browser at the same time, the list a browser advertises through the Trust Anchor Identifiers extension varies from one user to another, which gives one more element for browser fingerprinting.

Finally, MTCs were designed for the Web PKI, where browsers take care of distributing landmarks to their users. In a private PKI, you would have to build this distribution yourself, which could be a challenge, especially in OT, where devices are rarely updated or not even connected.

Private PKIs are a different story. Nobody will migrate them for you, but that also means you have more freedom. X.509 with ML-DSA, or with recently standardized composite ML-DSA, is often the most direct option, especially if you don’t need Certificate Transparency and therefore don’t need to carry SCTs. MTCs are still interesting, but the transition takes more work, since you need to distribute the landmarks to every client yourself. With them, logging is built into certificate issuance, which could be useful to build an inventory and track the PQC transition for compliance reasons. In the end, the right choice depends on your infrastructure: Do you need a log of everything you issue? Can you easily push updates to your clients? And do your clients already store your intermediate CAs?

Deploying post-quantum certificates is only half the job, though. Until clients stop accepting classical ones, attackers can simply target those, so you need to be ready to switch them off. And before any of that, you need to know where your certificates and keys are, and which systems issue and check them. It all starts with a cryptographic inventory.