Mental model
In the previous lesson you measured how much a certificate chain grows with PQC. This lesson covers how that growth affects two neighbouring mechanisms (OCSP and CRL), and the real current status of a solution developed against that growth (Merkle Tree Certificates). The main message, in the original brief’s own framing: “PQ certificates are not yet a production problem, agility is.”
OCSP and CRL: the same growth, a different effect
An OCSP response’s size is almost entirely determined by the responder’s signature; moving from RSA-2048 to ML-DSA-65, the signature-driven overhead is about 3053 BDERIVED. That cost repeats on every single OCSP query, because OCSP by definition produces one real-time response per query.
A CRL (Certificate Revocation List) is different: it carries a list of revoked certificates (each entry small: serial number + date + reason), with a single signature at the end. In a large CRL with thousands of revocation entries, the list itself dominates the volume; the growth of the signature with PQC is a relatively small overhead compared with the total. So the same algorithm change has a proportionally large effect on OCSP (each response is one signature) and a relatively small effect on a large CRL (one list plus one signature). When presenting this to an architect, instead of passing over it with one sentence like “PQC enlarges certificate revocation mechanisms”, separate which mechanism is affected and by how much.
Why it is a problem: real connection failures
The strongest evidence that this growth is not abstract is Let’s Encrypt’s own announcement of 3 June 2026: “Replacing those with ML-DSA equivalents would push a single TLS handshake well past 10 kilobytes. Cloudflare’s research has shown that, at that scale, a meaningful share of TLS connections fail on real-world networks, and the rest get slower.” (Let’s Encrypt’s own calculation here rests on the sizes of ML-DSA-44, the smallest of the three ML-DSA sets; this course’s own chain measurement, as you saw in the previous lesson, uses the larger ML-DSA-65, so the real total may be even larger than 10 KB, not smaller.) This is a warning about the total size of the whole handshake (certificate chain included), beyond the ClientHello overhead you saw in M6 (and will measure in M8); the certificate chain itself (which you measured in the previous lesson) is a significant part of that total.
MTC: shrink the proof instead of the certificate
Merkle Tree Certificates (MTC) attack the problem from a different angle: instead of each certificate carrying its own large signature, a CA adds certificates to a Merkle tree (a kind of cryptographic digest structure) that it publishes periodically, and each certificate carries, instead of its own large signature, a small proof (an inclusion proof) that it is “included” in that tree. This is a structure similar to the Merkle tree idea behind LMS/XMSS in M2 (all leaves below can be verified from one root digest), but here the goal is not to limit the number of signatures but to shrink the amount of data each certificate carries.
Its standard is draft-ietf-plants-merkle-tree-certs from the IETF’s PLANTS (PKI, Logs, And Tree Signatures) working group; as of September 2026 the draft has DRAFT2026-07-06 status at revision 5SOURCED, with no RFC status assigned yet.
Why it is not a 2026 problem: the real timeline
Let’s Encrypt’s own target is clear: “We are targeting late 2026 for a staging environment that issues MTCs, and 2027 for a production-ready environment.” Chrome’s pace is similar: according to Google’s own February 2026 announcement, Chrome’s new root program plan (Chrome Quantum-resistant Root Store, CQRS) has three phases: the first (ongoing) is a feasibility study with Cloudflare, using traditional X.509 certificates as a fallback; the second (Q1 2027) invites CT log operators; the third (Q3 2027) settles requirements for onboarding additional CAs. Google’s own wording is also clear: “Chrome has no immediate plan to add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store.” So neither MTC itself nor the infrastructure for a major browser to accept it will be in production before 2027.
This shows exactly why the original brief’s framing “PQ certificates are not yet a production problem, agility is” is right: what is urgent today is not moving to PQ certificates immediately (there is no production-ready solution (MTC) yet, and major root programs do not accept traditional PQC certificates), but deploying the hybrid key exchange you saw in M5 (deployable today, reducing the harvest-now-decrypt-later threat today), and building an architecture that can adapt quickly whichever algorithm or certificate mechanism finally reaches production (crypto-agility).
Update, October 2026
Two announcements since this lesson was written point in the same direction. On 21 September 2026 the Apple Root Program published a draft position on Merkle Tree Certificates for TLS (three cosignatures including ML-DSA and ECDSA, a 7-day maximum validity, annual audits, operator applications expected from late summer 2027) and said it will accept composite ML-DSA roots for S/MIME. On 29 September 2026 Cloudflare announced plans to run a public CA issuing free Merkle Tree Certificates. Neither changes the conclusion above: MTCs are converging as the answer for the web, and production use is a 2027 story. Sources and details are on the news desk.