| June 27th, 2026
On June 24th, I gave a talk at the Troopers conference
discussing post-quantum cryptography and some lessons
from Akamai's rollout of PQC to our global Content
Delivery Network. While the industry's immediate
focus has been on deploying support for hybrid
Key Agreement for TLSv1.3 (specifically: Post-quantum certificates have been discussed to some degree in various other blog posts, but doing the research in preparation of my talk lead me to some considerations I didn't see called out explicitly. You can, of course, just skim the slides or watch the talk, if you like, but I figured there's some value in writing things down here as well. ## Size MattersWithin the context of TLS certificates, size matters. Specifically, the size of the public keys and signatures. (Key generation, encap/decap, and signing performance of the PQC algorithms is either on par (for EC) or much better (for RSA), so not a bottleneck here.) The table below shows the respective sizes for the ECDSA, RSA, and ML-DSA algorithms:
When a client connects to a server, how many bytes do we need for the public key and signature bits of the TLS handshake? Let's take a look: That is, the server has to send a leaf certificate, which contains a public key and a signature by the intermediate certificate as well as (at least) two Signed Certificate Timestamps (SCTs) from the Certificate Logs; an intermediate certificate, again with a public key and a signature by a root cert; as well as the transcript hash signature.
So for a typical ECDSA P-256 leaf cert with, say, an
ECDSA P-384 intermediate, that adds up to:
If we use ML-DSA-44 certificates instead, then we end
up with ## Merkle Tree Certificates
Now the main goal of MTCs is to avoid having to send
multiple large signatures. How we try to accomplish
this is interesting and with many parallels to Certificate
Transparency logs. These MTCs come in two flavors:
## Standalone MTCs
To issue a new 1 TLS transcript hash signature:
So that's a bit better than the 14,724 bytes
from the traditional cert, but still not great. But
do note that the ## Landmark-relative MTCsInstead of signing each certificate individually, a CA produces "signatureless" certificates in batches, entering the information into logs and periodically signing the inclusion proofs relative to a given "landmark". Landmarks (trust anchors) from trusted co-signers are updated by clients periodically and the client signals the availability of given landmark to server, which then can return only: 1 TLS transcript hash signature: (The size of the inclusion proof depends on the landmark presented and grows logarithmically based on the number of hashes covered; the 736 bytes used here is based on the draft's example of a landmark being allocated by the given CA every hour, covering perhaps 4,4M certificates with 23 hashes in the inclusion proof.) ## No Free LunchOk, so 4,468 bytes is a lot better than 14,724 bytes, and likewise a lot better than the 11,376 bytes of a standalone MTC, but it's a far cry from the 544 bytes of an ECDSA cert. But alright. Let's roll with MTCs. What does that mean? ## Issuance delay
Clearly, we'll want to use landmark-relative MTCs, but
those are only signed in batches, so issuance is not
## Landmark Discovery
However, in order to use the landmark MTC, the client
needs to know which landmark to send to the server.
These landmarks are the
Well, I suppose we can do what we always do when we
need a client to discover some information prior to
making a connection to a server: we stuff it into the
DNS. So we may end up with TLS
Trust Anchor Identifier discovery mechanisms via
SVCB
DNS records. (Support for ## Multiple MTCs Required
Alright, cool, but what if the client doesn't offer
any or only an outdated landmark? Well, in that case,
the server can fall back to serving the standalone
MTC, but that also means that the server has to (a)
have both the standalone as well as the landmark MTC
available, and (b) must have the added complexity to
handle this scenario, including the logic to
atomically update ## Updating LandmarksAnd talking about the client perhaps having no or only outdated landmarks -- how does the client get those landmarks anyway? We currently have our trust bundles either baked into the browser or provided by the OS or hard coded into the app or strewn across the file system in various locations, and we currently do not really do a good job of keeping those up to date. Sure, browsers already update all sorts of internal data, but what about other clients, libraries, and tools? Currently, these rely on external trust anchors, meaning we would need, e.g., a separate, OS-wide landmark-updater of some sort. That suggests a fairly significant change to how common TLS libraries currently work, including a new external dependency. Instead, what I fear is a bifurcation of the larger ecosystem into browsers on the one hand (and likely only the current set of the big three, by which I mean: Google Chrome and, uhm, yeah, the other ones will do whatever Google says), and everything else. I'm not a fan of that trend. ## MTC and ML-DSA AdoptionGiven the current developments, what direction is the industry taking? Who is moving towards MTCs, who's doing ML-DSA? ## MTC AdoptionWe know that Google and Cloudflare are engaging in collaboration to test the feasibility of MTCs, and just a few weeks ago, Let's Encrypt joined them and announced a plan to have support for MTCs to be production-ready in 2027, with a staging environment landing in late 2026. As per their blog post, Google has "no immediate plan to add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store" and instead will use a "new Chrome Quantum-resistant Root Store (CQRS) and corresponding Root Program that only supports MTCs."
Talking about CAs and browsers... you'd think that
perhaps the CA/B
Forum might have some thoughts on MTCs, but it
seems that so far there's only been a very small
number of comments suggesting that participants are
"investigating" MTCs. This is another instance of
Now whether you agree that ultimately a very small number of people at maybe three organizations ought to be able to set the direction for the entire internet or not, with Google, Cloudflare, and Let's Encrypt being committed, it's safe to say that MTCs are coming, and it's only a question of time when the other browsers, CAs, and us mere mortals follow suit. ## ML-DSA Adoption
Google is adding support for ML-DSA certificates
In the mean time, the financial industry has been working on standing up a new, dedicated X9 Financial PKI, operated by DigiCert, with support for ML-DSA. So it seems that here, too, we are moving into different directions: use of MTCs for the public Web-PKI, and at the same time use of ML-DSA certificates for private PKIs. Again, this adds complexity and means that TLS and HTTPS stacks need to implement (and correctly use) several ways of doing x.509 certificates. :-/ ## SummaryMost of the above isn't really new -- at least not for those who are following the developments of the emerging standards in detail. But I think some of the aspects of post-quantum certificates are not quite obvious and carry some long-term consequences:
Post-quantum certificates are coming, but your primary
concern (from a Cryptography is typically bypassed, not penetrated. This won't be any different for post-quantum cryptography, and it looks like we're adding a significant amount of accidental complexity here. Not sure that's going to be all that fetch. June 27th, 2026 Footnotes:
[1] RSA-2048 only provides 112-bit
security, but is the by far most
widely used size for certificates.
[2] The number of cosignatures is
not fixed. In theory, you could
get away with just one cosignature,
thus reducing the size. However, to
approach parity with CT logs, a minimum
quorum of two additional cosignatures
seems expected.
Related links: | ||||||||||||||||||||||||||||||||
errno(2) values]