# Post-Quantum Certificates > Source: > Published: 2026-06-27 16:17:41+00:00 | June 27th, 2026 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 ## 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 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 ## Standalone MTCs To issue a new ``` 1 TLS transcript hash signature: 2,420 bytes + 1 public key: 1,312 bytes + 1 inclusion proof: 384 bytes + 2(+) cosignatures: 2 * 2,420 = Total: 8,956 bytes ``` So that's quite 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: 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 LunchOk, so 4,468 bytes is a lot better than 14,724 bytes, and is still better than the 8,956 bytes of a standalone MTC, even if 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 ## 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 Adoption We know that As per their Talking about CAs and browsers... you'd think that perhaps the 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 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 June 27th, 2026 Related links: | `errno(2)` values