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: X25519MLKEM768), I also covered
the current developments with respect to post-quantum
certificates.
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 Matters
Within 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:
| Algorithm | Public Key | Signature |
| ECDSA P-256 (128-bit) | 64 | 64 |
| ECDSA P-384 (192-bit) | 96 | 96 |
| RSA 2048 (112-bit)1 | 256 | 256 |
| RSA 3072 (128-bit) | 384 | 384 |
| ML-DSA-44 (NIST PQC Category 1 / 128-bit) | 1,312 | 2,420 |
| ML-DSA-65 (NIST PQC Category 3 / 192-bit) | 1,952 | 3,309 |
| ML-DSA-87 (NIST PQC Category 5 / 256-bit) | 2,592 | 4,627 |
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: 64 (leaf public key) + 2 * 64 (SCT sigs) + 64 (transcript hash signature) + 96 (intermediate public key) + 2 * 96 (intermediate and root signature) = 544 bytes. (For RSA-2048: 7 * 256 = 1,792)
If we use ML-DSA-44 certificates instead, then we end up with 2 * 1,312 + 5 * 2,420 = 14,724 bytes. 2 Ouch. This increase in size is why we need a different approach, and why people have suggested to use Merkle Tree Certificates (MTCs). (Obligatory Merkel Tree pun.)
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 and landmark-relative certificates.
Standalone MTCs
To issue a new standalone MTC, the given CA will, somewhat simplified, log the information, construct and sign subtree heads (called "landmarks"), and then collect 2+ co-signatures. So the breakdown of the number of bytes we need for such a certificate is:
1 TLS transcript hash signature: 2,420 bytes + 1 public key: 1,312 bytes + 1 inclusion proof: 384 bytes + 1 CA checkpoint signature: 2,420 bytes + 2(+) cosignatures2: 2 * 2,420 = Total: 11,376 bytes
So that's a bit better than the 14,724 bytes from the traditional cert, but still not great. But do note that the inclusion proof is quite small here, and what we'd like to do is get away with fewer of those large signatures. So to that end, if you were able to just hand the client an inclusion proof relative to a landmark the client already has, then you won't need to send the co-signatures at all. Enter landmark-relative MTCs.
Landmark-relative MTCs
Instead 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: 2,420 bytes + 1 public key: 1,312 bytes + 1 inclusion proof: 736 bytes + Total: 4,468 bytes
(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 Lunch
Ok, 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 immediate. It's not clear to me how much time might elapse between requesting a cert and receiving it, but let's assume that time is still short, so not a major issue.
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 trust anchors similar to your root cert bundle, meaning different servers will use different landmarks. How does the client know which landmark to send to which server without incurring the cost of multiple round-trips (e.g., by asking the server)?
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 SVCB DNS records is, by the way,
still lacking
significantly. You'll want to work on adding /
enabling support for these as part of your
post-quantum migration.)
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 two certificates.
Updating Landmarks
And 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 Adoption
Given the current developments, what direction is the industry taking? Who is moving towards MTCs, who's doing ML-DSA?
MTC Adoption
We 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
browsers Chrome moving faster than,
say, the traditionally more change averse CA industry.
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 for private PKI use in Chrome 150. Microsoft has signaled support for ML-DSA certificates at CA/B Forum meetings, possibly with an eye towards ML-DSA-87 (here, here, and here). The CA/B Forum Baseline Requirements for the Web-PKI do not yet allow ML-DSA, but those for S/MIME do allow ML-DSA now.
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. :-/
Summary
Most 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:
- Size matters. Sure. But most sizes have been discussed only for ML-DSA-44 certificates, not for any of the higher bit-level certs. What's more, while Merkle-Tree Certificates are an obvious improvement to this problem, they are still pretty damn big: over 8 times as large as ECDSA certs (4.5KB vs. 544B).
-
MTCs come in two flavors. Servers will
need to support both standalone and landmark-relative
certificates and be able to select which one to
offer based on the initial
ClientHello. - Clients need to frequently update landmarks. In order to be able to use the much smaller landmark-relative certificates for all TLS clients, operating systems will likely need to provide a landmark-updating daemon or some such. What that may look like hasn't been described in much detail yet.
-
Clients need to know which landmark to signal to
which server. That is, clients will need to have
a way to identify TLS specific information
prior to initiating the TLS handshake. This
will likely take the shape of
SVCB / HTTPSDNS records, which is a non-obvious new dependency for PQC adoption. (We may, of course, also bake this into the handshake, but it seems to me that would likely incur additional round trips and/or further increase the size of the handshake, which we just spent a lot of effort in decreasing here.) - The Web-PKI and private PKI are separating. There's bound to be more confusion if different clients use different trust stores for different use cases. More confusion around this will lead to more users / developers doing what they always do: go the path of least resistance and disable certificate validation.
Post-quantum certificates are coming, but your primary concern (from a security perspective, albeit certainly not a compliance perspective) is once again not going to be cryptography. As Adi Shamir noted a long time ago in his Turing Lecture:
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: