Written August 2026. Everything in this post describes the requirements, designs, and ecosystem trajectory as of that date. The WebPKI changes quickly, by design. The Merkle Tree Certificates specification is an active Internet-Draft and its details will shift. Treat this as a snapshot of the architecture that is emerging and the reasons it is emerging, not as a final specification.

This post is the sequel to A Deep Dive on the Classical WebPKI. That post describes the system of X.509 certificates, certificate authorities, root programs, and governance machinery built up over the last thirty years, and it is organized around a single observation.

The WebPKI has two structures, and they are not the same shape. The cryptographic structure is a graph of signed delegations recording which key authorized which other key. The governance structure is a hierarchy of accountability that explains why the browser accepts that authority at all. Nearly every interesting failure in the history of the WebPKI is a story about the gap between them.

The subject here is what happens when one of those structures gets torn down and rebuilt while the other stays standing. You do not need to have read the companion piece to follow this one; where its material is load-bearing here, I restate it briefly. But if you want the full history of how the classical system came to work the way it does, and the failures that shaped it, start there.

The classical model conveys trust as a chain of signed certificates, built and validated per connection, with each signature carried on the wire. At the scale of the public web, with billions of handshakes a day and hard latency budgets, post-quantum signature sizes make that model untenable. The architecture taking its place is built on Merkle Tree Certificates, currently being standardized as draft-ietf-plants-merkle-tree-certs in the IETF's PKI, Logs, And Tree Signatures working group (PLANTS), whose name is not an accident. Cloudflare and Chrome have published their own accounts of the design and the live experiment (Cloudflare, Chrome), and this post covers enough of that ground to stand alone while spending its energy where those posts do not, on the thirty years of history that explain why the redesign looks the way it does, on what the new design means for the governance hierarchy, and on the new failure modes and governance questions it creates.

The wire format changes. Nearly all of the governance carries forward. And the transition is being used, quite deliberately, to fix things that had nothing to do with quantum computers.

The post runs in four parts, covering the forcing function that makes the redesign unavoidable, the machinery that replaces the chain, the operation of the new system from revocation through governance, and the questions of power and boundary the redesign sharpens.

1Why the Classical Model Cannot Absorb Post-Quantum Signatures

Public-key cryptography can prove exactly one thing, that an operation was performed by the private key corresponding to a particular public key. Everything else, who controls the key, what names belong with it, whether the binding remains valid, why anyone should accept it, is answered outside the mathematics, by people, organizations, policies, and software.

The classical WebPKI answers those questions with a chain of signed certificates, and it is worth counting exactly what that chain costs on the wire, because the count is the entire forcing function.

When a browser connects to a public website today, the server proves possession of its private key with a handshake signature. That is one signature and one public key, and if the browser somehow already knew every server's key, that would be the whole story. It does not, so the server also sends a certificate binding its key to its DNS names, signed by a certificate authority. That is a second signature. To keep root keys offline and to bridge trust store update cycles as CA keys rotate, the chain typically includes an intermediate certificate, adding a third signature and a second public key. Finally, because relying parties learned the hard way that they need visibility into what CAs actually issue, browser policy requires evidence that the certificate was submitted to Certificate Transparency logs, in the form of Signed Certificate Timestamps from at least two independent logs. That is two more signatures.

Five signatures and two public keys, in the common case, on every full handshake on the public web.

With classical algorithms this is a rounding error. An ECDSA P-256 signature is 64 bytes and a public key is about the same. With the post-quantum algorithms NIST has standardized, it is not. ML-DSA-44, the most performance-oriented of the standardized lattice signatures, uses 1,312 bytes per public key and 2,420 bytes per signature, roughly a twenty-fold increase. ML-DSA-65 is larger still at 1,952 and 3,309 bytes. The MTC draft's own arithmetic is blunt. Even in an aggressively slimmed-down classical deployment, with the intermediate directly trusted and removed from the wire, a post-quantum leaf signature plus two post-quantum SCTs adds 7,260 bytes of authentication overhead with ML-DSA-44 and 9,927 bytes with ML-DSA-65. A full chain is worse, on the order of fifteen kilobytes of signatures and keys where the classical equivalent is under one.

Those bytes do not degrade performance smoothly; they hit a cliff, and the cliff has a name. A TCP sender may only have a bounded amount of unacknowledged data in flight, and on a fresh connection that bound, the initial congestion window, starts at roughly ten packets, about fourteen kilobytes, because the server has not yet learned what the path can carry. QUIC's constraint on the first flight is stricter still. Until the client's address is validated, a server may send at most three times the bytes it has received, to prevent the handshake from being weaponized as a traffic amplifier. Either way the consequence is the same. A handshake that fits inside the window completes in one round trip; a handshake that exceeds it must stop, wait for acknowledgment, and continue, and on a high-latency mobile path that extra round trip costs more than all the cryptography combined. Cloudflare has measured this directly by padding real handshakes. Around nine kilobytes of added data slowed handshakes by roughly 15 percent, and crossing the window boundary made them dramatically worse. Their traffic data sharpens the point. For half of the non-resumed QUIC connections they serve, the median data transferred from server to client over the connection's entire life is under eight kilobytes, of which the certificate chain is already more than 40 percent. For a large fraction of real web traffic, a post-quantum classical chain would mean the connection exists mostly to move signatures.

Nor can the ecosystem arithmetic its way out with a better algorithm or a cleverer encoding. Certificate compression is already deployed, and it cannot rescue these numbers; they are dominated by signature and key bytes, which are high-entropy by construction and do not compress. FN-DSA, the other lattice signature NIST selected, still working its way toward a final standard, offers 666-byte signatures, but its signing operation requires constant-time floating-point arithmetic that is notoriously difficult to implement without timing side channels that leak the private key, and even a successful FN-DSA deployment still adds several kilobytes across five signatures. Hash-based schemes are conservative and well understood, but the stateless variant, SLH-DSA, starts at nearly eight kilobytes per signature, and the stateful variants fail catastrophically if a signer ever reuses state, which is exactly the kind of operational assumption that breaks at web scale. Trimming the chain, suppressing SCTs, and caching intermediates have each been proposed, and the draft's 7,260-byte figure already assumes the most aggressive versions of them. Every door out of the room has been tried. The remaining option is to stop sending most of the signatures at all, which requires changing what a certificate is rather than what algorithm signs it.

The timing problem compounds the size problem. Drop-in post-quantum certificates provide no security benefit until a cryptographically relevant quantum computer exists, but they impose their performance cost immediately. That makes them nearly impossible to turn on by default today, and waiting until Q-day is a year out is how migrations fail. The only viable path is a design where post-quantum authentication costs no more than classical authentication does now, so that it can be deployed universally before it is needed.

Private PKIs do not share this constraint. Their operators control the relying parties, which means they can pre-provision trust state, coordinate algorithm deployment, and accept a few extra kilobytes per handshake between systems they own. The forcing function is specific to the public web, which needs a different way to convey an attribute binding once the signatures themselves no longer fit comfortably on the wire.

2The Debt Certificate Transparency Left Behind

That forcing function coincides with a second, older pressure, and understanding it requires a short detour through how transparency got bolted onto the classical system in the first place.

Certificate Transparency was never the ideal design. It was the pragmatic response to DigiNotar-class failures, the 2011 compromise in which a Dutch CA was breached and used to issue fraudulent certificates for Google and others that were deployed against Iranian users, and to the broader recognition that relying parties had almost no visibility into what CAs were actually doing. The insight was correct. Mis-issuance cannot be prevented by policy alone, so it must at least be made detectable. Every certificate gets published to append-only, cryptographically verifiable public logs; domain owners and monitors watch the logs for certificates they did not request. The ecosystem that grew up around this is documented at transparency.dev and certificate.transparency.dev, and it works. The value of that visibility was demonstrated in 2025, when independent monitors discovered unauthorized certificates for Cloudflare's 1.1.1.1 resolver, issued as far back as February 2024, because Fina CA had submitted them to public Certificate Transparency logs (Cloudflare's incident report). That the earliest of them sat in public logs for well over a year before anyone noticed is its own lesson, and one the monitoring economics later in this post return to.

But the deployed design carries a compromise at its core. The original CT concept treated the log as primary. The signed tree head was the assertion, and the certificate was meant to carry an inclusion proof demonstrating actual presence in the log. The Signed Certificate Timestamp was the concession required to get CA adoption and to preserve the sub-second issuance latency that the first wave of automation already expected. An SCT is not proof of inclusion. It is a log's signed promise to include the certificate within twenty-four hours, a countersignature on a certificate that already exists as a fully formed, signed object independent of any log. Eric Rescorla's A hard look at Certificate Transparency examines this history and what was lost. The deployed system has the operational complexity of public verifiability with the security properties of a promise.

The compromise was correct for 2013 through 2015. It was also expensive in ways that accumulated. Issuance and observability stayed separate, so transparency remained a post-issuance obligation that could in principle fail independently. Logs accepted submissions from anyone, so they grew with the whole ecosystem's issuance and every monitor had to download every certificate from every log it might appear in, repeatedly. And every certificate on the wire carried two extra signatures forever, which was tolerable only because signatures were small.

The gap between issuance and transparency could not be closed while the classical system worked well enough, because redesigning issuance itself was politically and operationally prohibitive. The post-quantum size problem removes that barrier. An internet-scale upgrade of the authentication layer is required anyway, so the deeper architectural correction finally becomes the lower-friction path. This is the single most important thing to understand about the Post-Quantum WebPKI. It is not merely a cryptographic migration. It is the ecosystem cashing in a forced upgrade to fix a decade-old design debt.

That is the situation the rest of this post works through. Signatures that no longer fit inside the windows the transport gives us, a transparency layer that works but was never finished, and a rare alignment in which the expensive fix and the necessary fix are the same project. Part II describes the machinery that results.

3The Primitive That Makes It Work

Before describing the new architecture, the data structure it is named after deserves a few paragraphs, because the entire economic argument of the Post-Quantum WebPKI reduces to one property of Merkle trees. A single signature can vouch for millions of certificates, and any one of those certificates can prove it is covered by that signature using nothing but a few dozen hashes.

Start with the hash function. A cryptographic hash takes an input of any size and produces a short, fixed-size fingerprint, 32 bytes for SHA-256, with the property that nobody can find two different inputs producing the same fingerprint. Hashes are also cheap, orders of magnitude cheaper to compute than signatures are to create or verify. Those two properties, binding and cheapness, are all the construction needs.

A Merkle tree turns a list of items into a single fingerprint that commits to all of them. Hash each item to get the leaves. Pair the leaves and hash each pair together to get the next level. Pair and hash again, and repeat until one hash remains. That final hash is the tree head, and because every level is built from the one below it, changing a single bit of any item changes its leaf, which changes its parent, and so on up, producing a different tree head. Sign the tree head once, and you have signed a commitment to every item in the tree.

The second half of the trick is the inclusion proof. Suppose you hold certificate C and want to convince someone who knows only the signed tree head that C is in the tree. You do not need to send the other certificates. You send C plus the sibling hash at each level of C's path to the top, here H(D) and then H(A,B). The verifier hashes C to get H(C), combines it with H(D) to get H(C,D), combines that with H(A,B), and checks that the result equals the tree head they already trust. If any step was forged, the final hash will not match. The proof's size is the height of the tree, which grows logarithmically. Four certificates need two hashes, a thousand need ten, four million need twenty-three, and four billion need only thirty-two. That logarithm is why the numbers later in this post come out so small.

This is not exotic machinery. It is the same construction Certificate Transparency logs have used since 2013, the same one behind Git's object model and every blockchain's block structure. What is new is where it sits. The classical WebPKI used Merkle trees to observe issuance after the fact, and the new design uses them to perform it.

Which brings us to batching. A classical CA signs each certificate individually, so its signing costs, and the wire costs of its signatures, scale linearly with issuance. A Merkle Tree CA instead accumulates issuance into a single, ever-growing tree, its issuance log, appending an entry for each certificate as it validates the request. On a short cadence, every couple of seconds in the draft's worked examples, the CA signs the current tree head, a snapshot called a checkpoint. That one signature covers every entry ever added, including the few thousand that arrived since the previous checkpoint. The certificates issued in that interval are the batch, and each one gets an inclusion proof to the freshly signed state instead of a signature of its own.

One subtlety makes the proofs short and will matter later. Rather than proving inclusion all the way to the head of a tree containing the CA's entire history, the design lets the CA also sign subtrees, interior nodes of the big tree that cover just the recent interval. A proof to a subtree covering a few thousand entries needs about a dozen hashes; the subtree itself is anchored to the full log. And because the log is append-only, any two snapshots of it can be connected by a consistency proof, a similarly short bundle of hashes demonstrating that the newer tree contains the older one unmodified, that history was extended and not rewritten. Consistency proofs are the tool the system's auditors use, and they are what makes the cosigner roles in the next section cheap enough to run.

That is the entire toolkit. Signed tree heads amortize one signature across a batch, inclusion proofs let individual certificates ride that signature for a few hundred bytes of hashes, and consistency proofs keep everyone honest about history. Everything below is these three pieces, arranged.

4Issue by Logging

In the classical model a CA validates a request, signs a certificate, and, for public TLS, submits a precertificate to external CT logs to obtain SCTs. Logging is a post-issuance obligation attached to an already-complete signed object.

Merkle Tree Certificates invert the order, and the inversion is the central architectural move from which everything else follows. Each CA maintains its own issuance log, an append-only Merkle tree containing an entry for everything it certifies, operated as a numbered series of logs so a damaged one can be closed and a successor opened under the same CA identity.

To issue is to log.

The CA adds an entry describing the binding it has validated, then signs views of the log asserting it stands behind every entry those views contain. Independent parties called cosigners verify correct log operation and add their own signatures over the same views. A certificate is assembled afterward, from an inclusion proof showing the entry sits in a signed view, together with whatever signatures the relying party's policy requires.

There is no longer a signed certificate that exists prior to, or independent of, its appearance in a publicly auditable structure. Inclusion in the CA's log is the act of certification. Transparency stops being a sidecar and becomes the issuance mechanism itself, which is why the working group is named PKI, Logs, And Tree Signatures rather than anything about algorithms.

The details reward attention, because several of the classical system's cost centers quietly disappear inside them.

An issuance log is not a CT log. It has no public submission interface; only the CA appends to it, so it grows only with that one CA's issuance rather than the whole ecosystem's. Its entries are deliberately small. A log entry contains the certificate's names, validity, extensions, and a hash of the subject public key rather than the key itself, and it contains no signatures at all. Entry sizes therefore do not scale with post-quantum key and signature sizes, which matters enormously when certificate lifetimes are simultaneously collapsing and issuance volume is multiplying. Long-expired entries can be pruned, so the log's serving cost scales with a retention window rather than the log's lifetime. And because each entry appears in exactly one log, a monitor downloads each certificate once, instead of once per CT log it was submitted to.

The CA's signing profile changes just as fundamentally. A classical CA produces one signature per certificate, which at hundreds of thousands of issuances per hour dictates the entire shape of its HSM fleet and signing infrastructure. A Merkle Tree CA signs checkpoints and subtrees on a cadence measured in seconds, amortizing each signature across the batch as described above, so its signature rate is set by the checkpoint interval rather than the issuance rate. The security-versus-throughput tradeoff that classical CA key ceremonies are built around relaxes accordingly, and a lower signing rate opens the door to slower, more conservative key protection choices.

Cosigners are the new party in the system, though as we will see they are a recognizable evolution of an old one. A cosigner follows a CA's log and signs views of it, attesting to properties determined by its role. The base role, specified in the C2SP tlog-witness work, simply verifies the log is append-only, that the CA is showing everyone the same history; an operational community of such witnesses already runs across today's transparency logs (witness-network.org). A mirroring cosigner additionally serves a full copy of the log, guaranteeing the entries remain available to monitors even if the CA's own infrastructure does not. Relying party policy decides which cosigners, and how many, must vouch for a view before it is trusted. This quorum is the structural defense against a CA presenting different logs to different observers, the split-view attack that is the natural first question about any self-operated log.

If witnessing feels familiar, it should, because the classical ecosystem already adopted the same defense for validation itself. Multi-perspective issuance corroboration, now required by the Baseline Requirements, has a CA confirm domain control from several network vantage points before issuing, because an attacker who can poison the view from one vantage point, a BGP hijack near the CA, cannot poison them all. Witnessing applies that exact logic to log history rather than to a DCV lookup, with one upgrade that changes what the corroboration is worth. An MPIC check is transient and visible only to the CA that ran it; you trust that it happened because an audit says so. A witness's corroboration is a signature over the view it verified, a durable attestation that travels with the system's artifacts and can be checked by any relying party, at any time. The multi-perspective idea graduates from an internal control into a public, cryptographic one.

5What Travels on the Wire

A Merkle Tree Certificate is still an X.509 certificate. The TBSCertificate still binds a public key to names, validity, key usage, and the other attributes applications care about, and most fields and extensions apply exactly as they always have. Two fields repurpose themselves. The serial number is the entry's index in the issuance log, a detail that seems cosmetic until you reach the section on revocation. And the signature field no longer carries a signature in the classical sense; it carries an MTCProof, an inclusion proof plus zero or more cosignatures.

Two certificate profiles exist, and they are complementary rather than sequential. The draft itself directs servers to deploy a standalone certificate alongside any landmark-relative one; the second is the optimization for clients holding current state, the first is the foundation it rides on and falls back to.

A standalone certificate carries an inclusion proof to a recently signed subtree of the log, together with the CA's signature and enough cosignatures to satisfy relying party policy. It works for any client that trusts the CA and cosigners, with no predistributed state beyond their keys, and it can be issued within seconds of the entry being logged. It still carries post-quantum signatures on the wire, but far fewer than a classical chain plus SCTs, because the batch structure means the signatures cover the subtree, not the individual certificate, yet each certificate must still transport its copy of them.

A landmark-relative certificate carries only the inclusion proof. No signatures travel with it at all. The trick is predistribution. On a fixed cadence, the ecosystem designates certain tree sizes as landmarks, and the subtrees those landmarks define are pushed to relying parties out of band, through the same update channels that already deliver root store changes and CT log lists, after the distribution channel has verified them against the cosigner quorum. A client that holds a current landmark subtree hash can validate any certificate in that subtree from the inclusion proof alone. Authentication is the combination of the client's predistributed knowledge and a short hash path connecting the leaf to it.

The optimization has a latency cost that should be stated plainly. A landmark-relative certificate cannot exist until the next landmark is allocated, so the small certificate arrives up to one landmark interval after issuance, an hour in the worked example. The standalone profile exists to cover exactly that hour, issued within seconds, valid for any client that trusts the CA and cosigners, larger on the wire. The ACME alternate URL and its retry-after, covered later, are the operational expression of this gap, and a server simply serves the standalone certificate until the landmark-relative one lands.

The draft's arithmetic makes the payoff concrete. Assume the short-lifetime future the CA/Browser Forum has already scheduled, with seven-day certificates, renewal at 75 percent of lifetime, and a large CA issuing on the order of 4.4 million certificates per hour. If landmarks are allocated hourly, a landmark subtree spans those 4.4 million entries and an inclusion proof needs 23 hashes, 736 bytes. That is less than a third of one ML-DSA-44 signature, and nearly a tenth of the three ML-DSA-44 signatures a post-quantum classical chain would need for a leaf and two SCTs. Proof size grows logarithmically, so 32 hashes, one kilobyte, covers a subtree of over four billion certificates. The client-side state is equally modest. Hourly landmarks with seven-day maximum lifetimes mean at most 169 active landmarks, at most two subtrees each, roughly eleven kilobytes of hashes per CA.

The window is the calcification argument in miniature, and it is worth pausing on the picture. Nothing in the client's landmark state is older than the oldest certificate still alive. Trust material enters at the right edge with every update and falls off the left edge on the certificate lifetime's schedule, automatically, with no distrust event required. The classical root store accumulated for thirty years; the landmark window is perpetually about a week deep.

The common-case post-quantum handshake therefore carries one handshake signature, one public key, and one inclusion proof. That is roughly a third of the drop-in post-quantum figure, and the excess over today's classical handshake is almost entirely the irreducible part, the larger handshake signature and public key any post-quantum design must carry. Crucially, the whole thing fits inside the transport's first flight with room to spare, so deploying it before Q-day costs no extra round trip, which is what makes early deployment rational rather than altruistic. The full tally below uses the handshake anatomy from earlier and the common case of an intermediate on the wire.

The last row is the one that matters. Any post-quantum design must pay for the handshake signature and the server's public key; those two rows are the irreducible cost of proving key possession, identical in the second and third columns. Everything above them in the middle column, eleven kilobytes of chain and transparency signatures, is the cost of conveying the attribute binding, and it is exactly the part MTC replaces with 736 bytes of hashes. The tally counts the cryptographic components themselves; certificate encoding and TLS framing add overhead to every column and do not change the comparison. Early measurements from the Chrome and Cloudflare experiment, currently running MTCs re-encoded from classical certificates, already show the size reduction on the wire; the latency gap is expected to widen once the alternative is post-quantum X.509 rather than ECDSA chains.

The negotiation that lets both profiles coexist is TLS trust anchor identifiers (draft-ietf-tls-trust-anchor-ids). Every landmark has an identifier; a client advertises the latest landmark it holds, and the identifier scheme lets a single advertised landmark imply the whole active range. A server holding both certificate profiles sends the landmark-relative certificate when the client's advertisement shows it can validate one, and falls back to the standalone certificate, or to a classical chain from a traditional CA, when it cannot. Stale clients get a slower handshake, not a broken one. The fraction of clients that actually stay current enough for the fast path is one of the central empirical questions the live experiment is designed to answer.

6What the Browser Actually Trusts

In the classical WebPKI, the relying party's trust anchor is a set of long-lived root certificates shipped in a root store. Everything below is signed delegation, root to intermediate to leaf, with path building and path validation as distinct, genuinely non-trivial operations, and cross-certificates creating real complexity. The trust decision is embedded once, often for decades.

In the Post-Quantum WebPKI, the browser's configured trust in a Merkle Tree CA is a bundle made up of the CA's log identity, the set of cosigners whose keys it accepts, a policy for which combinations of cosignatures suffice, the current list of trusted landmark subtrees, and a list of revoked index ranges. The multi-level cryptographic path largely disappears for the common case; there is no chain to build, only a proof to check against predistributed state.

Governance does not disappear with it. Root programs remain the apex decision-makers. They still decide which issuers are accepted, under what constraints, and when they are removed. What changes is the cryptographic object those decisions attach to, and the cadence at which they take effect. Instead of a root key burned into devices for twenty-five years, the browser trusts a set of issuers whose landmark subtrees are refreshed continuously through the vendor's own update channel. The trust decision becomes something the decision-maker can actually operate.

Chrome has made the institutional shape of this concrete. Chrome has stated it has no immediate plan to add traditional X.509 certificates containing post-quantum algorithms to the existing Chrome Root Store at all. Instead it is building a separate, purpose-built trust store, the Chrome Quantum-resistant Root Store, that will support only Merkle Tree Certificates, operated by a corresponding root program alongside the existing one. The published rollout has three phases, beginning with the feasibility study with Cloudflare now underway, in which every experimental MTC is backed by a classical certificate; continuing with an invitation, targeted for the first quarter of 2027, for CT log operators with a usable log in Chrome before February 1, 2026 to bootstrap the public MTC infrastructure, with the CA onboarding requirements for the CQRS finalized early in that phase; and concluding with the establishment of the store itself in the third quarter of 2027, including the ability for sites to opt into downgrade protection so they can refuse to be authenticated by anything less than a quantum-resistant certificate.

Read that second phase again, because it is the governance continuity thesis made explicit by the trust decision-maker itself. The parties being invited to stand up the first issuance logs and cosigning infrastructure are the CT log operators, the organizations that spent the last decade running the transparency layer that MTC absorbs into issuance. The sidecar's operators become the engine's.

Taken together, that is the new cryptographic structure, certification by logging, proofs instead of chains on the wire, and a trust bundle refreshed through the vendor's own channel. Part III turns to what it is like to operate, and to fail, inside that structure.

7Revocation, Finally Rationalized

The classical WebPKI's revocation story is its longest-running embarrassment, and any redesign of issuance has to answer for it. CRLs grew unboundedly and were fetched by almost no one. OCSP leaked browsing history to CAs and failed open, because failing closed would have made every CA outage a partial internet outage. Heartbleed demonstrated that the system could not absorb a mass revocation event even when everyone agreed one was warranted. The ecosystem's actual answer, visible in every Baseline Requirements revision since, has been to shrink the problem rather than solve it. Shorter certificate lifetimes mean less time during which a compromised key matters, until revocation becomes a niche mechanism for the exceptional case rather than a load-bearing one for the routine case.

The Post-Quantum WebPKI completes that trajectory and adds two genuinely new tools.

The first is that short lifetimes stop being a mitigation and become a design assumption. Landmark-relative certificates only work if validity windows are short enough that recently issued and currently valid nearly coincide; the draft's worked examples assume seven-day certificates. At that lifetime, the primary answer to routine invalidation, domain transfers, decommissioning, and authorization changes is simply to stop renewing and let the window drain, a process measured in days rather than the years a classical NotAfter can impose. Key compromise is the exception; an attacker holding the key can use it until expiry, so compromise still demands what it always has, immediate revocation and replacement, a fresh key with a standalone certificate issued in seconds, which is exactly the case the mechanism below is kept for.

The second is revocation by index. Because a Merkle Tree Certificate's serial number encodes its position, the entry index in its low bits and the number of the issuing log above them, a relying party can be configured to reject ranges of entries, efficiently, in bulk, and crucially without knowing what they contain. This is the targeted response to the scenario that most worries anyone reasoning about self-operated logs, a CA that constructs a perfectly consistent tree but withholds some entries from publication, so consistency proofs pass while monitors cannot see what was issued. The indices of the missing entries are still known even though their contents are not, and relying parties can revoke exactly those ranges as a surgical first response while the governance process decides whether full distrust is warranted. Index revocation is also how distrust itself becomes cheaper. Rather than the all-or-nothing removal of a root key, a program can distrust everything after a chosen index while letting existing legitimate certificates age out, the same shape as the SCT-based partial distrusts the classical ecosystem improvised for cases like Entrust, now available as a first-class mechanism. I have watched every revocation scheme the classical web tried strain against the same arithmetic, lists that grow with the ecosystem, checks that fail open, endpoints that add latency; revocation by range is the first whose cost is set by the size of the incident rather than the size of the web.

Classical certificate-level revocation does not vanish; because MTCs are X.509 and their serials are well-defined, CRLs and OCSP apply unchanged where policy wants them. But Chrome has signaled where policy is going. The CQRS program intends to replace legacy CRL machinery with a modern revocation framework whose requirements focus narrowly on key compromise, which is the one scenario short lifetimes cannot fully absorb.

8Failure Modes, Old and New

The classical companion piece argued that a PKI design should be judged by how honestly it accounts for its failures. The same standard applies to the replacement, so it is worth walking the classical failure catalog through the new machinery, along with the failures the new machinery makes possible.

Start with DigiNotar, the defining catastrophe of the classical era, a CA compromised, fraudulent certificates issued in secret, discovered only when they were used in the field. In an MTC world that secrecy stops being free. There is no such thing as an uncommitted Merkle Tree Certificate; a certificate that validates is, by construction, an entry the CA has committed to its log under a cosigner quorum. Commitment is not the same thing as public availability, and the design is candid about the gap; a CA can build a perfectly consistent tree while withholding entries from publication, the scenario treated below. Closing that gap is a relying party policy choice, not an automatic property of the construction, and it is why quorums that require mirroring cosigners matter. Under such a policy, an attacker with full control of a Merkle Tree CA's keys can still mis-issue, but every usable mis-issuance is committed to the CA's log and served by independent mirrors, and monitors watching for the victim's names see it on the same cadence as everything else. The attack that took months to surface in 2011 becomes visible within the issuance pipeline's processing delay. Detection is not prevention, and the response still runs through governance, but the window between mis-issuance and discovery, which is where DigiNotar's victims were harmed, collapses.

The attack that replaces it is the split view, a CA showing one version of its log to the cosigners and relying parties and another to the monitors hunting for mis-issuance. This is the classical gap between issuance and observability reborn inside the new design, and the entire cosigner apparatus exists to close it. Witness cosigners verify append-only consistency, so any fork in the presented history requires the collusion of enough cosigners to meet relying party policy. Mirror cosigners go further and guarantee availability of the entries themselves. The residual risks are exactly the ones the design names. A relying party whose policy accepts consistency-only quorums remains exposed to the withheld-entry variant described above, mitigated by index revocation; and a sufficiently broad collusion of cosigners with the CA defeats the scheme, which is why cosigner independence and diversity become a root program policy surface with the same weight that CT log operator diversity carries today, and why the economics of running mirrors, the question that has quietly strained the CT log ecosystem for years, will shape the cosigner population as surely as any written requirement.

The quieter failures translate too. Validation failures, the BygoneSSL-style confusions and DCV weaknesses that produced most real-world mis-issuance, are unchanged by MTC itself; the certificate is only as good as the validation behind the log entry. What changes is the auditability of that validation. The CQRS program's stated intent to make domain control validation reproducible, with proofs of validation publicly and persistently available so that any party can act as a DCV monitor, extends the issue-by-logging philosophy upstream into the validation step, the layer CT never reached. Cosigner outages replace CT log outages as the availability risk in the issuance path, and redundancy answers them the same way. What is genuinely new is stateful failure. A log that forks, loses data, or strands its mirrors cannot simply be restarted the way a stateless service can; the numbered series of logs exists so a CA can close a damaged log and open a successor, and the reconciliation procedures around it are among the parts of the design still being actively worked. And the landmark distribution channel becomes a new single point whose compromise matters. A poisoned update that installs attacker-chosen subtree hashes is functionally a root store compromise, which is not a new class of risk, since the update channel could always replace the root store, but is a reminder that the design concentrates rather than distributes that particular dependency.

What does not translate is the classical system's signature-shaped forensic trail. In the classical WebPKI, a mis-issued certificate is a self-contained, CA-signed artifact that proves misbehavior on its own. A landmark-relative certificate proves nothing without the log context around it. The draft preserves non-repudiation through the log structure itself, but the evidentiary workflow, the thing you attach to an incident report, changes shape, and incident response tooling will have to change with it.

9Agility and the Calcification Problem

Classical roots were routinely given validity periods of twenty and twenty-five years, often well beyond the credible cryptographic lifetime of their algorithms and key sizes (the guidance tables at keylength.com make the mismatch uncomfortable to look at). The mismatch was tolerated because root rollover was so expensive that nobody wanted to do it more often than absolutely necessary.

A classical root is not merely a key the CA controls. It is a trust decision irreversibly distributed into a vast, only partially updateable installed base. Once the key is present in Android 1.x, a 2014 smart television, a payment terminal, or an industrial controller, the web has calcified around it. You cannot recall the key, and you cannot push a software update to most of those devices. Even after a root is publicly distrusted by every major browser, the key retains residual commercial value precisely because of the long tail that will never learn of the distrust. Root removals are logistically brutal and permanently incomplete, and the companion piece's distrust history, roughly one major distrust action every fifteen months across the classical era, is a history of exactly how brutal.

Merkle Tree Certificates change the trust material a client actually holds from a decades-long root key to a continuously refreshed set of landmarks. The institutional anchor, the CA's identity, its cosigners, the quorum policy, persists on its own slower schedule; the landmark is the relying party's current cryptographic reference within it, and it is the part that used to calcify. Landmarks age out on the certificate lifetime's schedule; clients that stay current only ever hold recent ones. When a root program decides an issuer is no longer acceptable, the operational expression is to stop distributing that issuer's landmarks and, if warranted, revoke index ranges, and then let validity windows measured in days drain. Algorithm retirement follows the same path in the layers this design owns. When the ecosystem needs to move off a signature scheme or a hash function, the trust-state and CA-signature side of the change propagates at update-channel speed to the population that can update, rather than waiting decades for embedded NotAfter dates to expire on devices that will never see another patch. Server software and TLS stacks still move at software-deployment speed, which the coexistence arithmetic later in this post prices in; what disappears is the decades-long anchor at the bottom of the stack that used to set the floor for everyone. The property of being burned into hardware forever is not eliminated, but it is confined to the population that was always going to be a problem.

That long tail of unupdatable devices does not disappear, and what happens to it should be said outright. It stays classical. Devices that cannot receive landmark updates need standalone certificates or classical chains for as long as they exist. The gain is that the mainstream, updateable web is no longer forced to preserve the entire classical calcification in order to serve them.

And staying classical means something sharper than staying slow. With no publicly trusted drop-in post-quantum chain planned for the web, a client frozen on classical chains is not on a degraded path to quantum safety; it is not on a path to it at all. The migration protects exactly the population that was already protectable.

The far side of the boundary is not slower. It is unprotected, indefinitely, and any account of the transition that does not say so is selling something.

10Short Lifetimes and the Common Control Plane

None of this is deployable by hand, and the classical era already settled that argument. The CA/Browser Forum's SC-081 ballot has public TLS certificate lifetimes on a fixed schedule, with a 200-day maximum as of March 2026, 100 days in March 2027, and 47 days in March 2029, with domain validation reuse windows tightening in parallel. At those lifetimes, certificate lifecycle management without automation is not difficult, it is impossible, and the automation layer the ecosystem standardized on is ACME (RFC 8555), which stopped being the Let's Encrypt protocol years ago and became the control plane of the public web.

MTC issuance is designed to ride that control plane rather than replace it. The draft's ACME integration is small and pragmatic. An order becomes valid once the entry is sequenced in the issuance log, the certificate URL serves the standalone certificate immediately, and an alternate URL serves the landmark-relative certificate once the next landmark lands, returning a retry-after in the interim. The same ACME client that fetches alternate chains today can, with modest changes, provision both MTC profiles. Chrome has gone further and stated that the CQRS ecosystem will be ACME-only, turning what the classical system treated as best practice into a condition of participation.

Consider what this looks like from the operator's chair, because the transition asks web servers to do something they have already been doing for a decade. When ECDSA arrived, the ecosystem did not flag-day away from RSA. Operators provisioned both. Apache, nginx, and IIS all grew the ability to hold an RSA certificate and an ECDSA certificate for the same name side by side, and the server selects between them per handshake based on what the client's ClientHello says it supports. ACME clients absorbed the same pattern, managing parallel certificates per hostname with independent renewal. Nobody thinks of dual-certificate deployment as exotic anymore; it is a configuration idiom.

The Post-Quantum WebPKI reuses that idiom wholesale, even though what is being selected is no longer a key type. During the transition, a server holds up to three artifacts for a name, a classical chain from a traditional CA, an MTC standalone certificate, and an MTC landmark-relative certificate, the latter two arriving from a single ACME order against the Merkle Tree CA. At handshake time the selection signal is the client's trust anchor advertisement rather than its signature algorithm list, but the mechanical shape is identical. The client declares what it can validate, and the server picks the best certificate it holds that matches, falling from landmark-relative to standalone to classical as capability declines. The operator's mental model, several certificates for one name, chosen per connection by negotiation, transfers without modification.

This is also the payoff of a decision in the MTC design that is easy to read past. Merkle Tree Certificates are X.509 certificates, not a new envelope. The subject, the subject alternative names, the validity dates, the key usage extensions, the public key encoding, all of it parses with existing tooling; Cloudflare's example certificate decodes with stock OpenSSL, which balks only at the unfamiliar signature algorithm identifier. The consequence for the installed base is that everything in a server built around the certificate as an object, configuration directives, SNI matching, certificate storage, inventory and expiry monitoring, the ACME client's renewal bookkeeping, continues to work. On the server, the lift concentrates in one place, the TLS library, which must learn the trust anchor negotiation and the new signature verification procedure. That is a real change, but it is a change in a handful of actively maintained codebases rather than in every deployment's operational fabric, and confining migrations to the layers that can actually be migrated is a lesson the WebPKI has paid for repeatedly.

How long does the dual deployment last? The classical era's own transitions are the only guide there is, and none of them were quick. SHA-1 took roughly a decade to move from serious collision warnings to final browser distrust, with a long tail after that. ECDSA has been broadly supported for well over a decade and RSA certificates are still issued in volume today. TLS 1.0 survived twenty years before the browsers removed it. Every one of those was a smaller change than replacing what a certificate is, so the sober planning assumption is that the Merkle Tree WebPKI, the classical WebPKI, and the Certificate Transparency ecosystem that serves it will operate side by side for fifteen years or more. That coexistence has costs the ecosystem should price in now rather than discover later. CAs run both issuance stacks, CT logs must be funded and operated at full rigor even as cosigning infrastructure grows up beside them, root programs govern two parallel regimes, and operators carry the dual-certificate configuration not as a transition sprint but as a steady state. Chrome's own framing says as much, committing operational resources to the existing root program and its classical CA partners in parallel with the CQRS, explicitly as a risk-managed transition rather than a cutover.

This matters more than it first appears, because the deployment cost of any new authentication architecture is dominated by the installed base of clients and the operational habits around them. The classical WebPKI spent fifteen years forcing automation into existence; the Post-Quantum WebPKI inherits it as a launch asset. The assumptions MTC makes, relying parties continuously updated by their vendors, trust material distributed through the decision-maker's own channels, validity short enough that issuance and validity nearly coincide, are assumptions the classical ecosystem was already ratcheting toward for its own reasons. MTC is less a departure from the classical trajectory than its logical conclusion.

11Continuity of Governance

A caution before the mapping. None of these rules is settled. The CQRS policy framework has not been published, the working group is still arguing over structures as basic as cosigner negotiation, and every governance claim in this section describes a trajectory rather than a ratified regime. The working group has deliberately kept auditing, monitoring policy, and revocation improvements outside its current scope; those questions live in root program policy, which is exactly where this section reads them from, Chrome's stated direction rather than protocol text. But the signals available today, the draft's role definitions, Chrome's phase plan, and the stated direction of the root program behind it, all point the same way. Much of the governance continuity holds between the two systems, the mapping from old roles to new is close enough to draw as a table in prose, and where the new regime departs from the old, the departures look deliberate, chosen to pay down the existing ecosystem's accumulated debt rather than carry it forward.

Root programs remain the apex. They decide which Merkle Tree CAs are accepted, which cosigners count toward quorum, what the landmark distribution requirements are, and when acceptance is withdrawn; the CQRS is a root program in every institutional sense, merely one whose decisions execute through update channels instead of shipped key material. CA organizations remain the accountable parties for validation, keys, lifecycle, and the answers they owe the programs; what changes is that their issuance behavior is now legible in their own log, while the organizational controls behind it, key management, access control, change management, remain the root program's to assess by other means. Cosigners are CT log operators evolved, coupled into the issuance path instead of alongside it, a lineage Chrome's phase two makes literal. Monitors still watch for unexpected bindings, with their job made cheaper by single-log entries and made more complete by issue-by-logging. The relying party's final decision still sits in browser and OS policy.

One classical role disappears outright rather than mapping forward. The externally operated subordinate CA, an intermediate signed by one organization's root and run by another, was the classical system's mechanism for delegating issuance authority, and it produced some of its least legible governance, with audit scope, blast radius, and accountability all blurring at the boundary between parent and operator. MTC has no equivalent construct because there is nothing to sign a subordinate with. An issuer is a log, the log is the accountability boundary, and an organization that wants to issue either operates its own Merkle Tree CA, entering through the same admission pathway as everyone else, or is a customer of one. The intermediate's legitimate technical functions are absorbed by the design itself. Keeping the anchor key away from per-certificate online signing is answered by the checkpoint signing model, whose per-interval rather than per-certificate signature rate relaxes the key protection tradeoff, and bridging trust store cycles across key rotation is answered by continuously refreshed trust bundles and the draft's provision for a CA to run multiple signing keys against the same log in parallel.

A whole class of delegation opacity the classical governance machinery spent years chasing simply has no place to live.

The companion piece spent a full part on how root program governance actually works, the policy documents, the CA/Browser Forum baseline beneath them, the audit regimes, the incident-response expectations, the inclusion and removal processes. All of that machinery has a direct successor here, and Chrome has been public about its shape. The CQRS will be governed by its own root program with its own policy framework, published for community review, operating alongside the existing Chrome Root Program rather than amending it. The requirements will be separate because the system is a different shape. A policy written for chains of signed certificates spends its pages on root key ceremonies, intermediate constraints, cross-certification, CT log submission, and CRL profiles; a policy for Merkle Tree CAs has to govern things that document has no vocabulary for, issuance log operation and availability, retention and pruning, cosigner selection and quorum, landmark allocation and distribution. You cannot get from one to the other by redlining.

But separate does not mean unrelated, because a large fraction of what a root program demands was never about the certificate's shape at all. What it takes to be trusted to assert that someone controls a domain, how validation must be performed and evidenced, how keys must be generated and protected, how incidents must be disclosed and remediated, what organizational accountability looks like, none of that changes because the signature became an inclusion proof. Expect the CQRS policy to read as a new document with a familiar core. The requirements that follow from the system's nature will be new, and the requirements that follow from the job's nature will be recognizably the ones the classical program spent thirty years sharpening.

And the transition is being used to renovate the governance machinery itself, in ways that have nothing to do with quantum computers and everything to do with thirty years of accumulated lessons. The CQRS program's stated direction reads like a checklist of the classical system's known governance weaknesses, with ACME-only workflows as a participation requirement rather than a norm; revocation requirements rebuilt around key compromise instead of legacy CRL machinery; reproducible domain control validation, so that the validation step itself becomes publicly auditable and any party can serve as a DCV monitor; a CA admission pathway in which prospective MTC CAs first demonstrate operational competence as mirroring cosigners and DCV monitors, replacing paper-based inclusion with a verified track record; and continuous, externally verifiable monitoring positioned to replace the annual third-party audit as the primary oversight instrument. That last item deserves a moment of appreciation; I have lived inside WebTrust audit cycles, on both sides of the table, and continuous observation retiring the annual attestation sample is the change I would have asked for first. The proposal is to move oversight of everything the log can show, issuance, logging, revocation, and eventually validation evidence, from an annual reconstructive exercise to assessment of a continuously observed system, because the design finally makes that observation possible for the behaviors that matter most.

In the classical system the two hierarchies were different shapes and the interesting failures lived in the gap. In the Post-Quantum WebPKI the cryptographic structure is redesigned so that the most expensive parts of that gap, the sidecar nature of transparency, the irreversible calcification of roots, the mismatch between root validity and cryptographic lifetime, the unauditability of validation, are closed or closing, while the governance hierarchy that actually decides whom to trust continues to do its job over machinery it can finally operate at the tempo its decisions require.

So the machinery changes and the institutions persist, with the transition doubling as a renovation of the very requirements they enforce. Who that system serves, and who is left outside it, is the subject of the final part.

12The User Agent Question

There is a reading of all this that casts the browser as the villain of the story, quietly completing a decades-long accumulation of power and wiring it into the protocol itself. I reject that reading, and the reason is in the name. A browser is a user agent. That phrase is not a euphemism; it is the job description, written into the web's earliest standards, and the classical era's record shows the power being exercised in exactly that capacity. DigiNotar was distrusted to protect users. Symantec and Entrust were distrusted to protect users. Lifetimes were shortened over the objections of nearly every other party in the chain because shorter lifetimes protect users. The ratchet the companion piece documented was not a seizure of territory. It was an agent doing its job with tools that were slower than the job required.

The design does put the agent's hand on more levers, and they should be named. Relying parties are continuously updated by their vendors, so the update channel is no longer just how trust decisions are corrected but how trust functions at all. The set of acceptable cosigners is root program policy, and so are the landmark distribution requirements and the CQRS admission pathway. A root program could always, in principle, remove a CA; a root program can now, in practice, modulate an issuer's usefulness on a weekly cadence without any removal at all. But every one of those levers is the machinery of the same duty. The classical system exercised the user's interest slowly and deniably through shipped root stores. The new system exercises it quickly and legibly through update channels, and quick, legible, and accountable is a better shape for an agent's power than slow and deniable. MTC does not create the browser's authority. It gives the user's agent, for the first time, machinery that can act at the speed its responsibility has always demanded.

The genuine open question is not about the clients that have an agent. It is about the ones that do not. A curl, a language runtime, an embedded HTTP client, or an air-gapped system lacks the uniform, high-frequency update channel the landmark cadence assumes, and, more to the point, has no one negotiating on its behalf. Nothing prevents an operating system, a distribution, or an enterprise management system from shipping landmark state, and distributing landmarks outside the browser channel is being discussed; until those channels exist, these clients live on standalone certificates or classical chains and consume trust policy produced for and by the browser ecosystem, from the outside. The classical fiction that a root store was a neutral artifact any relying party could adopt was always mostly fiction, but it papered over this gap, and the new design retires the paper. How relying parties without a user agent get represented, when trust decisions execute at update-channel speed through channels only the largest vendors operate, needs as much sustained attention as the hash paths and proof sizes the working group threads are full of. That is not an argument against the design. It is the next problem the design makes visible.

13What Remains Classical

Merkle Tree Certificates are the path for the public web's authentication layer under post-quantum algorithms. They are not a universal replacement for every PKI, and the boundary is worth drawing precisely because both sides of it are being built right now.

Private PKIs, enterprise TLS, device identity, workload identity, and most code-signing and document-signing systems have different constraints. Their operators control the relying parties, so they can pre-provision trust state and coordinate deployment on their own schedule, and the classical chain model updated with post-quantum algorithms remains viable and in many cases preferable, with governance evolving on its own schedule. Nothing here says private PKIs cannot use MTC; profiles of the construction without public transparency are being explored, and some environments will adopt them. The point is that private operators get to choose, because the forcing function that removes the choice is specific to the public web. The vendors have drawn their own products' boundary in the same place. Chrome expects to support traditional X.509 with quantum-resistant algorithms specifically for private PKIs outside the Chrome Root Store, and Cloudflare's deployment of post-quantum authentication for its origin pulls, classical-style ML-DSA certificates between parties with a pre-existing relationship, is a working illustration that where trust is already established and scale is bounded, the classical shape survives the algorithm change intact (Post-quantum authentication to origins).

The public web is different because of scale, because of client heterogeneity, and because encryption must remain on by default for people who will never know any of this happened. That is the environment in which the per-connection signature chain becomes untenable and the combined transparency-and-issuance design becomes the practical path.

14Closing the Gap

The classical WebPKI diagnosed its own problem with unusual clarity. The cryptographic structure and the governance structure are not the same shape, and nearly every interesting failure is a story about the gap between them. Certificate Transparency narrowed the gap by making issuance visible. It could not close it, because the political and operational cost of redesigning issuance was prohibitive while classical signatures remained small.

The post-quantum transition forces the redesign, and the same transition removes the barrier that kept the deeper fix on the shelf. What emerges is a Post-Quantum WebPKI in which

• transparency is intrinsic to issuance rather than bolted on afterward,
• the common-case handshake carries an inclusion proof instead of a chain of signatures, and is smaller than what it replaces,
• the trust material a client holds is refreshed on the certificate lifetime's schedule rather than embedded for decades,
• revocation is finally sized to the problem it can actually solve, and
• the governance hierarchy that decides whom to trust continues to operate, now over a system the user's agent can update at the speed its duty has always required, with representation for agentless relying parties as the open question.

PKI does not eliminate the need to decide whom to trust. It makes those decisions scalable. The certificate graph, or the issuance log and its landmarks, records how authority is delegated. The governance hierarchy determines whether relying parties accept that authority, and when they withdraw it. Judge any PKI, and any proposed change to one, by how honestly it accounts for the gap between the two.

The classical system made the gap visible. The forced upgrade is what finally lets us close the most expensive parts of it, and what obliges us to watch closely the new gap it opens, between the relying parties the new system serves natively, and everyone else.