{"slug": "post-quantum-certificates", "title": "Post-Quantum Certificates", "summary": "Post-quantum certificates, specifically Merkle Tree Certificates (MTCs), reduce TLS handshake sizes from 14,724 bytes to as low as 4,468 bytes by batching signatures and using landmark-relative proofs, but introduce issuance delays and require client-side landmark discovery via DNS.", "body_md": "|\nJune 27th, 2026\nPost-quantum certificates have been discussed to some\ndegree in various other blog posts, but doing the\nresearch in preparation of my talk lead me to some\nconsiderations I didn't see called out explicitly.\nYou 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:\nWhen 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:\nThat is, the server has to send a leaf certificate,\nwhich contains a public key and a signature by the\nintermediate certificate as well as (at least) two\nSigned Certificate Timestamps (SCTs) from the\nCertificate Logs; an intermediate certificate, again\nwith a public key and a signature by a root cert; as\nwell as the\nSo for a typical ECDSA P-256 leaf cert with, say, an\nECDSA P-384 intermediate, that adds up to:\nIf we use ML-DSA-44 certificates instead, then we end\nup with ## Merkle Tree Certificates\nNow the main goal of MTCs is to avoid having to send\nmultiple large signatures. How we try to accomplish\nthis is interesting and with many parallels to ## Standalone MTCs\nTo issue a new \n\n```\n1 TLS transcript hash signature: 2,420 bytes +\n1 public key: 1,312 bytes +\n1 inclusion proof: 384 bytes +\n2(+) cosignatures: 2 * 2,420 =\nTotal: 8,956 bytes\n```\n\nSo that's quite a bit better than the 14,724 bytes\nfrom the traditional cert, but still not great. But\ndo 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: \n\n```\n1 TLS transcript hash signature: 2,420 bytes +\n1 public key: 1,312 bytes +\n1 inclusion proof: 736 bytes +\nTotal: 4,468 bytes\n```\n\n (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\nClearly, we'll want to use landmark-relative MTCs, but\nthose are only signed in batches, so issuance is not\n## Landmark Discovery\nHowever, in order to use the landmark MTC, the client\nneeds to know which landmark to send to the server.\nThese landmarks are the\nWell, I suppose we can do what we always do when we\nneed a client to discover some information prior to\nmaking a connection to a server: we stuff it into the\nDNS. So we may end up with ## Multiple MTCs Required\nAlright, cool, but what if the client doesn't offer\nany or only an outdated landmark? Well, in that case,\nthe server can fall back to serving the standalone\nMTC, but that also means that the server has to (a)\nhave both the standalone as well as the landmark MTC\navailable, and (b) must have the added complexity to\nhandle this scenario, including the logic to\natomically 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\nWe know that\nAs per their\nTalking about CAs and browsers... you'd think that\nperhaps 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\nGoogle is adding support for ML-DSA certificates\nIn the mean time, the financial industry has been\nworking 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:\nPost-quantum certificates are coming, but your primary\nconcern (from a Cryptography is typically bypassed, not penetrated.\nThis won't be any different for post-quantum cryptography,\nand it looks like we're adding a significant amount of\nJune 27th, 2026 Related links: |\n\n`errno(2)`\n\nvalues", "url": "https://wpnews.pro/news/post-quantum-certificates", "canonical_source": "https://www.netmeister.org/blog/pqc-certs.html", "published_at": "2026-06-27 16:17:41+00:00", "updated_at": "2026-06-27 16:34:24.278074+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-research", "ai-safety", "ai-policy", "ai-infrastructure"], "entities": ["ML-DSA", "ECDSA", "RSA", "TLS", "Merkle Tree Certificates", "Certificate Logs", "DNS"], "alternates": {"html": "https://wpnews.pro/news/post-quantum-certificates", "markdown": "https://wpnews.pro/news/post-quantum-certificates.md", "text": "https://wpnews.pro/news/post-quantum-certificates.txt", "jsonld": "https://wpnews.pro/news/post-quantum-certificates.jsonld"}}