AWS

sgmenda@amazon.com

Security PKI, Logs, And Tree Signatures merkle tree certificates transparency pki webpki Merkle Tree Certificates (MTCs) make transparency logging part of certificate issuance, enabling Internet-scale deployments of short-lived certificates and large post-quantum signatures. In exchange, their security rests on the state, not just the keys, of the certification authority, its cosigners, and relying parties' update services. This document describes the architecture for deploying MTCs and defines the guarantees that a relying party can obtain when it accepts one. These cover who certified and who recorded the certificate, agreement among relying parties on each log entry, the enforcement of revoked ranges, and the validation of the relying party's own configuration. For each guarantee, we state which parties must behave as specified and which keys and state they must keep intact. Our Recommendations are not needed to interoperate, but they affect the guarantees a deployment achieves, especially against adversaries able to compromise a certification authority, a cosigner, or an update service. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at . Discussion of this document takes place on the PKI, Logs, And Tree Signatures Working Group mailing list (), which is archived at . Subscribe at .

Introduction

Transparency and revocation today Today, a website's server asks a certification authority (CA) for a certificate, often using ACME . The CA checks that the server controls the domain name, and issues a certificate binding the name to the server's key. Because a CA can issue a certificate for any name, browsers also require Certificate Transparency (CT) . Before issuing, the CA usually submits a precertificate to independent logs. Each log returns a signed certificate timestamp (SCT), a promise to publish the certificate within a maximum merge delay (MMD), and the CA embeds the SCTs in the certificate. Browsers require SCTs from two or three logs, depending on the certificate's lifetime . When a browser visits the website, it checks the certificate chain and the SCTs. Monitors read the logs and report certificates that the names' owners did not request. shows this flow. In the terms used below, the browser is the relying party, the server is the authenticating party, and the logs are third-party cosigners.

Issuing and accepting a certificate with Certificate Transparency today Server CA CT logs Browser | | | | | 1 request (ACME) | | | |----------------->| | | | | 2 validate the | | | | domain | | | | 3 precertificate | | | |----------------->| | | | 4 SCTs | | | |<-----------------| | | 5 certificate | | | | with SCTs | | | |<-----------------| | | | | | 6 publish it | | | | within the MMD | | 7 TLS handshake | | | |------------------------------------------------------->| | | | 8 check chain | | | | and SCTs |

CT has worked, but its original design scaled poorly with issuance volume, which keeps growing as certificate lifetimes fall from 398 days to 47 days by 2029 , and Let's Encrypt is now issuing certificates valid for only 160 hours . Logging is free and open to every publicly trusted CA, so a log takes in a firehose of issuance from many CAs, not only from its operator. Let's Encrypt's logs, for example, accept certificates from any trusted CA . Let's Encrypt alone had about 682 million active certificates in September 2026 (). In 2024, Let's Encrypt's RFC 6962 logs had grown to several terabytes per shard and used about 10 TB of bandwidth a day . The logs' annual cloud costs were approaching seven figures when Let's Encrypt replaced them with cheaper static logs . RFC 6962 logs have typically had an MMD of 24 hours, which a log must meet whatever its load. That promise is hard to keep. Logs have been frozen or retired after failing to merge entries in time, including Google's Aviator in 2016 , Sectigo's Mammoth2024h1 in 2024 , and two DigiCert logs in 2025 ; surveys such failures. Static logs remove the merge delay by sequencing entries before returning an SCT , and Chrome now admits new logs only with an MMD of at most four hours, or one minute for static logs . Revocation has limits of its own. In October 2026, eMudhra, a CA trusted by all major browsers, turned out to have generated the private keys of eight intermediate CAs so weakly that anyone could recover them . CT could have exposed an attack only afterwards. Browsers that push revocation lists to their users blocked the intermediates, and root programs removed the issuing root , but clients that consume neither stay exposed until a software update or an administrator intervenes . With MTCs, a relying party that takes trusted subtrees from an update service can receive revoked ranges in the same updates. Once cosigner interfaces define a halt, by which cosigners stop signing a CA's log (), cosigners could also bound a compromised CA's new issuance at relying parties not yet updated.

Merkle Tree Certificates Merkle Tree Certificates (MTCs) make logging part of issuance. A CA appends each certificate's contents to its own issuance log and signs views of the log, not individual certificates. Cosigners sign the same views: a mirror after storing the entries, as a static CT log does today, and a witness after checking that the log has not forked. A certificate then carries a proof that its entry is in the log, together with these signatures. A relying party that already holds the relevant part of the log, validated in advance, needs no signatures at all. shows the flow for comparison with . Cosigners sign only after the CA has appended the entry and signed a checkpoint covering it. The server first receives a standalone certificate, which carries the cosignatures and is usable at once. At a regular cadence, the CA also allocates landmarks, points in the log whose subtrees are validated and delivered to relying parties ahead of time, here by the browser's update service. Once a landmark covers its entry, the server can send a landmark-relative certificate, which carries only a proof of inclusion.

Issuing and accepting Merkle Tree Certificates Server CA Cosigners Update Browser service | | | | | | 1 request | | | | |------------->| | | | | | 2 validate, | | | | | append | | | | | 3 checkpoint | | | | |------------->| | | | | | 4 store or | | | | | check | | | | 5 cosign | | | | |<-------------| | | | 6 standalone | | | | | cert | | | | |<-------------| | | | | | 7 landmark | | | | |---------------------------->| | | | | | 8 validate | | | | | 9 subtrees, | | | | | ranges | | | | |------------->| | 10 landmark- | | | | | relative | | | | |<-------------| | | | | 11 handshake | | | | |---------------------------------------------------------->| | | | | 12 check | | | | | proof |

This reduces the costs above. Each CA logs its own issuance, and mirrors copy the log in batches. Log entries carry a hash of the subject's key and no signatures, which keeps them small (Sections and of ). Nothing promises later inclusion, so there is no merge delay to miss: an entry is certified only when the CA signs a view that contains it (). Handshakes shrink. With ML-DSA-44, a certificate that relies on a part of the log the relying party already holds adds about 0.75 kB of proof, where an X.509 leaf signature and two SCTs, all ML-DSA-44, add about 7.3 kB. Standalone certificates with two cosigners besides the CA are no smaller, so the saving depends on how many handshakes are landmark-relative (). Revoking many certificates at once is also cheap. Serial numbers are log positions, so one revoked range can reject every certificate in an interval of the log, such as everything a compromised CA issued after a given point (). MTCs do not solve everything. They do not prove that the CA validated the identifier it certified; monitors still catch misissuance only afterwards. A relying party still learns of a revoked range only when its configuration is updated. And the format alone fixes few guarantees. They depend on which cosignatures relying parties require, on who validates the log in advance, and on whether the CA, the cosigners, and the update services keep their keys and their state intact. As puts it, MTCs "introduce additional state to PKI". The simplest alternative is to keep X.509 chains and CT, and move their signatures to ML-DSA. With ML-DSA-44, a leaf signature and two SCTs alone add about 7.3 kB (7,260 bytes) to each handshake, even when the intermediate is omitted, and every CT log stores each large certificate (). Chrome has said that it has no immediate plan to add such certificates to its root store, for scalability and efficiency, and that its quantum-resistant root store will support only MTCs .

This document This document describes the architecture for deploying MTCs, following the approach of the MLS architecture . We define no protocol. Our Recommendations are non-binding, and each guarantee cites the ones it rests on. A deployment that violates a Recommendation loses only the guarantees that rest on it, not interoperability. We state five guarantees that a relying party can obtain when it accepts an MTC: certification, recording, consistency, revoked ranges, and validated configuration (). For each, we give the premises: which parties must behave as specified, and which keys and state they must keep intact. Every guarantee except the basic form of certification needs intact state at some party, not only intact keys, and all of them trust whoever configures the relying party. Consistency needs every pair of acceptable cosigner sets to share a cosigner that is faithful to the log (). Under a policy of the CA and any one of several mirrors, monitors can detect a rogue CA showing different histories to different relying parties (a split view), but, as with CT today, nothing prevents it. Before the guarantees, we describe the setting and what each service must do (). After them, we cover the deployment choices and who owns them (), how configuration changes over time (), and deployment, security, and privacy considerations (, , and ). sketches why each guarantee holds, and states the limits of those arguments. summarizes the guarantees of , what each tells a relying party at acceptance, what it rests on, and whether it holds against a rogue CA. Each also assumes that the relying party's verifier and configuration are intact and that its configuration arrived under an intact update key (). The trusted-subtree path also rests on G5. The guarantees at a glance

Guarantee	What the relying party learns	Rests on	Against a rogue CA
G1 Certification	the CA key certified exactly this entry	the CA cosigner key, if the policy requires it	holds unless the key is extracted
G2 Recording	a mirror stored the entry before acceptance	a supporting mirror faithful to the log	holds
G3 Consistency	relying parties agree on the entry at each index	a faithful supporting cosigner shared by every pair of acceptances (the intersection condition)	holds
G4 Revoked ranges	an installed range rejects on both paths, and stays installed	the update key, numbered complete updates with a version floor, and the installation check	holds for the positions named
G5 Validated configuration	each trusted subtree was validated under the policy in effect	local validation, or an honest update service; the installation check and retention rule	holds

Terms not taken from are defined where they are introduced: the services and paths in , the failure and premise terms in , the intersection condition in , the version floor in , the bounded-delay form in , the installation check in , the retention rule in , and the halt in . The deployment worked through is TLS 1.3 server authentication, including over QUIC, in the Web PKI with browsers as relying parties. The guarantees apply to any relying party with a cosigner policy and a source of configuration; we have analyzed only this deployment. Root-program policy is out of scope: we name the decisions a deployment makes and who owns each (), and cite root-program documents only as dated examples. We consider only end-entity certificates that a Merkle Tree CA issues itself. A non-MTC subordinate CA that a Merkle Tree CA certifies issues certificates that do not appear in the Merkle Tree CA's log, so the guarantees do not cover them (). This document is meant to be read alongside , revision -08. We use its terms (see ), its formats, and its verification procedure. In the language of , certification refines authenticity, recording is the part of transparency that holds at acceptance, and consistency goes beyond transparency; eventual visibility is not provided (). The C2SP specifications define the log and cosigner interfaces. Five of them carry premises of the guarantees and are normative here. Recording rests on mirrors and tiled logs , consistency on cosignatures and witnesses , and both on the MTC profile . A mirror implements parts of the witness protocol and serves tiles, so a mirror-only policy rests on and too. The checkpoint and signed-note formats they build on are informative. We refer to the tagged versions cited, and later revisions of this document will cite new tags as the specifications are revised, as anticipates for its own references. Trust anchor identifiers supply certificate selection in TLS 1.3 , and ACME supplies enrollment. and explore further applications and mechanisms.

Setting and services A Merkle Tree CA appends entries to an issuance log and signs checkpoints, each a view of the log at some size (). A CA instance is a CA identifier together with its hash algorithm, its CA cosigner key, and its series of issuance logs, each identified by a log number; a CA moves to a new log number after a log failure (). A certificate's serial number encodes the log number and the entry's index (). A cosigner signs checkpoints, or subtrees of the log, under its own key (). The CA signs as the CA cosigner. A witness cosigns a checkpoint after checking that it is consistent with the last one it cosigned . A mirror also stores the entries a checkpoint covers before it cosigns . A monitor reads the log and checks the entries for the names it watches. A relying party, such as a browser, accepts certificates, and an authenticating party, such as a server, presents them. The relying party's cosigner policy says which sets of cosignatures suffice, with each cosigner's ID fixing its key and role: CA, witness, or mirror (). Its configuration in effect is the CA parameters, cosigner policy, trusted subtrees, and revoked ranges it is using at a given moment (). An update service publishes that configuration under its update key. The vendor of the relying party runs it (for a browser, the browser vendor), or an organization does. Delivering what it publishes needs no key and may be left to others (). The installer is the local component that makes delivered configuration effective. shows these services and the evidence that passes between them. Monitors read entries from mirrors, or from the CA where no mirror serves them, read checkpoints from every cosigner, and report to root programs. The update service obtains landmarks and cosigned checkpoints from the CA, as drawn, or the checkpoints from the cosigners themselves. Each box is an abstract service (). One operator may run several, and drawing them as separate boxes does not make them independent. lists which keys and state must stay intact.

Services and the evidence between them +-----------+ reports +--------------+ | Monitors |------------>| Root program | +-----------+ +------+-------+ ^ ^ | policy | | checkpoints v | +--+--------+ +--------------+ subtrees, +---------+ | | Witnesses | | Update | revoked | Relying | | +-----------+ | service |---------->| party | | ^ +--------------+ ranges +---------+ | | ^ ^ | v | landmarks, cosigned | MTC | +-----------+ | checkpoints +-----+-----+ | | CA |--------------+ | Authenti- | +---+ |-------------------------------->| cating | | +-----------+ certificates | party | | ^ +-----------+ | | | v | +-----------+ +---+ Mirrors | +-----------+

Accepting a certificate A relying party accepts a certificate on one of two paths. On the cosigner path, the certificate carries an inclusion proof to a subtree, and cosignatures on that subtree that satisfy the cosigner policy; a standalone certificate is built for this path. On the trusted-subtree path, the inclusion proof leads to a trusted subtree: a log number, an interval [start, end), and a subtree hash that the relying party holds for a CA (). No cosignature is checked at acceptance; a landmark-relative certificate is built for this path. does not prescribe a cosigner policy, so a relying party may require more of the cosigners on the trusted-subtree path than on the cosigner path (). At a regular cadence, the CA allocates a landmark, which records the log's tree size at that moment. Two subtrees cover the entries between one landmark and the next, and relying parties are configured with them as trusted subtrees (Sections , , and of ). Before a landmark's subtrees are configured as trusted, the landmark is validated: each subtree must be consistent with a reference checkpoint, and every cosigner of some set satisfying the cosigner policy must have signed that checkpoint or a larger one consistent with it (). A mirror counts only for subtrees that start at or above its threshold (). Validation is local when the relying party does it and delegated when the update service does (). It records the cosigners whose signatures it verified, with each one's identity, key, and hash bindings (cosigner ID, public key, and hash algorithm): its recorded evidence. Validating a landmark is distinct from the CA's checking of names, which we always call identifier validation. The relying party's configuration, matched against the certificate's log and interval, decides the path. fixes the order; its step numbers are given in parentheses:

1. (Step 4.) If a revoked range in effect covers the certificate's serial number, the relying party rejects the certificate.
2. (Step 11.) Otherwise, if the relying party holds a trusted subtree with exactly the certificate's log and interval, it accepts the certificate if and only if the inclusion proof matches that subtree's hash. A mismatch is final.
3. (Step 12.) Otherwise, it accepts the certificate if the cosignatures satisfy the cosigner policy, and rejects it if not.

The decision replaces only the signature check; the rest of path validation, such as expiry, still applies (). Several guarantees depend on this order. In particular, a trusted subtree constrains only certificates whose interval matches it exactly: a certificate whose interval merely overlaps it, or covers the same entries after the subtree was removed, takes the cosigner path. follows one certificate from issuance to certificate selection.

Certification authority The CA is trusted to validate identifiers (). Three points about its operation are relevant for us. Once an entry is appended, a covering checkpoint follows within seconds, so the append is the last point at which the CA can stop a misissuance. The entry is certified, though, only once the CA signs a view covering it, whether or not its order completes (), and Section 2.4 of treats the first such signature as the point of issuance. So identifier validation and profile checks precede the append, as Section 2.4.4 of asks of linting. The CA cosigner key signs at checkpoint cadence, every two seconds in the example of , so it is an online key. A hardware module protects it against exfiltration (Section 2.6.1 of requires one, and permits encrypted key backups). But a pipeline that can call the module can still sign a fork. The signing service below bounds forks, not what is appended. Recommendation for CAs: The CA cosigner key is usable only through a signing service. That service retains the last signed checkpoint of each log and refuses every log other than the current one. It checks a consistency proof before each checkpoint or subtree cosignature, and persists its record before it uses the key. The service runs inside the module boundary, or is the sole holder of the module's signing authorization. Every module holding the key, including disaster-recovery copies, is unusable without the current record. Advancing the current log needs authorization separate from signing. A synchronously replicated record meets the current-record requirement only if every module serializes its signings against that one record. Restoring a point-in-time snapshot, or loading the key into a fresh module and service, for example from an encrypted backup, does not, and is a log failure (below). Replacing a failed module under the same service and current record is not a log failure. An encrypted backup that no module has loaded is not itself a module holding the key. A log that cannot be rebuilt to exactly the signing service's record has failed. The CA then moves to a new log number (Sections and of ), rather than resuming from an earlier checkpoint (, ).

Witnesses A witness holds no entries. It is relied on for consistency, as a member shared by two acceptable sets (), and for the halt bound, which limits a compromised CA's new issuance once cosigners halt (). and require a cosigner's signatures for a log to stay consistent. A witness that loses its retained checkpoint for a log, and resumes that log under the same key, can break that requirement: it cosigns whichever history it is shown next. Re-learning the checkpoint from published cosigned checkpoints is not recovery, since the adversary chooses which one the witness finds.Editor's note: does not yet say how a witness detects the loss of its retained checkpoint for an origin, or that it stops cosigning that origin under the same key. Recommendation for witnesses: A witness that loses its retained checkpoint for a log does not resume that log under the same key, and one that cannot tell which logs it lost retires the key. A witness never rolls back its record of a log, the last checkpoint it cosigned. One restored from a backup or snapshot treats every log as lost, even log numbers it accepts in advance, unless it confirms that the restore did not roll the log back. It confirms this against a copy of its record kept in another failure domain and updated before each cosignature is released. The witness holds its own record within the key's trust boundary, as the CA does (), and retains it for a log it stops following. If its own record sits outside that boundary, compromise of its host counts as compromise of the witness. A witness that has only lost a log keeps its key and its place in policies. Under a k-of-n policy, the CA can carry on with k of the remaining cosigners. Under a policy that accepts any one of several, it uses another. To regain the witness, the CA moves to the next log number that the witness has not lost (), but only when it cannot otherwise meet its policy. The move has a cost in incidents and log numbers (). A new key would be a new cosigner (), and so a policy change ().

Mirrors A mirror plays roughly the part that a Certificate Transparency log plays today. It is relied on for recording. Because it keeps the log's history, it can also serve consistency. A mirror's minimum index is the lowest index whose entry it stores (). A mirror initialized at a minimum index above zero may sign a checkpoint that covers earlier entries it never stored. already says that log clients "MUST NOT treat the mirror as contributing to a quorum for entries below its minimum index", but no cosignature carries a minimum index, so a relying party cannot apply that rule. What a policy can rely on is the mirror's initial minimum index for a log, not its current one, which rises with pruning, provided two rules hold for each key and log. Single initialization: the mirror is initialized for the log once, and a mirror that loses its state for a log does not resume that log under the same key. Minimum-index bound: the minimum index never exceeds the size of the largest checkpoint the mirror has signed, or, before its first signing, the initial minimum index. Then every index from the initial minimum index up to a signed size was stored before the first signing that covered it (), and later pruning cannot undo recording (). The bound follows from , whose minimum index "MUST be less than or equal to the tree size of the log's current checkpoint", applied to the mirror's copy, and from , except before a mirror's first signing. A new mirror key is a new cosigner. Under , a new cosigner needs at least 100 days to become Usable (Section 3.3). So losing one log's state should not cost the key ().Editor's note: does not yet require single initialization, or bound a mirror's minimum index by its initial minimum index before its first signing and by its largest signed size afterwards. Its quorum rule uses the current minimum index, which no cosignature carries; what a policy can apply is the initial minimum index.

A mirror's initial minimum index m0 and eligibility threshold b index 0 m0 s1 s2 +------------+-----------------+-----------------+ | not stored | stored before | stored before | | (backfill | signing s1 | signing s2 | | later) | | | +------------+-----------------+-----------------+ ^ b >= m0: the policy counts this mirror only for entries at indices i >= b

Recommendation for root programs, mirrors, and validating parties: A program counts a mirror at every index of a log only if the mirror starts at index zero, or at or below a pruning bound, an index below which a revoked range that the program ships covers every entry (). Otherwise, the mirror publishes its initial minimum index for the log, and a policy fixes, per mirror key and log, a threshold b at or above that index and counts the mirror only for indices i >= b. Either way, the mirror follows single initialization and the minimum-index bound. It never rolls back its record for a log, and checks entries restored from elsewhere against that record before its next signing. The record sits within the key's trust boundary, as for a witness (). On the trusted-subtree path, validation counts the mirror for a subtree only if the subtree starts at or above b. Backfill below the initial minimum index does not lower b. A mirror that stops following a log keeps its record for that log, so that resuming is not a second initialization. That record consists of the initial minimum index, the last signed checkpoint, and what the mirror needs to extend the tree. The entries themselves stay prunable under the program's retention rules. Under a policy that requires mirrors, mirror submission is on the issuance path (). An operator running both a witness and a mirror keeps them distinct cosigners (, ).

Monitors A monitor:

• compares the checkpoints of every cosigner that a supported policy trusts, for every log number up to the highest that the policy accepts (), fetched from the cosigners themselves rather than only through the CA (see the Monitor Retrieval Mechanism of );
• parses every entry in its scope ();
• checks entries against its own record of authorized keys (); and
• reports to the subject, the CA, and root programs.

The subject, usually through a third-party service, is the monitor the design relies on (). Detection assumes that monitors reach the cosigners and are not served stale views (). So a policy that counts a witness can require the witness's monitoring endpoint. only recommends that endpoint, and says its delay "SHOULD NOT" exceed an hour. requires mirrors to make cosigned checkpoints and tiles available "within 10 minutes of cosignature issuance" (Section 3.2.3). A monitor alarms when a cosigner's served checkpoint stays smaller than one it has cosigned for longer than the applicable delay after the cosignature's timestamp.

Relying-party configuration For a browser, the root program decides policy, and the browser vendor turns decisions into configuration and ships the verifier. In other deployments, other vendors and organizations play the same parts. Whoever can change the configuration or the verifier decides what the relying party accepts. So the powers to validate subtrees, change policy or ranges, deliver updates, and replace the verifier are best held separately (). A vendor that holds all of them, as anticipates, can still separate them internally, with distinct keys, approvals, and roles.

Authenticating party The authenticating party:

• deploys a standalone certificate alongside any landmark-relative one, for relying parties whose configuration lags ();
• sends the landmark-relative one only when the trust anchor signal shows that the relying party holds its subtree (); and
• renews early enough for a covering landmark to arrive ().

During a renewal overlap, the authenticating party holds, per name, two landmark-relative certificates, a standalone one, and any directly signed (conventional X.509) one (). It obtains the landmark-relative one from the CA, or builds it from the log ().Editor's note: Deploying the TLS integration as intended may need a change to or . Since defines no SignatureScheme for the proof, under a strict reading of and , a server that holds a conventional chain signed with algorithms the client advertises sends that chain instead of the MTC. The recovery of inherits this, and options are under discussion in . (version -07) also does not yet say what a complete certification path is when the trust anchor is a landmark.

Security guarantees This section states what holds at acceptance, as five guarantees, and what each rests on. follows the evidence from issuance to acceptance, with validation delegated to the update service, and marks the stage that each guarantee chiefly concerns. The server, which only forwards certificates, is omitted.

The guarantees along the path from issuance to acceptance +------------------------------+ | CA: appends the entry and | G1 Certification: | signs a checkpoint | the CA key certified +--------------+---------------+ exactly this entry | v +------------------------------+ | Cosigners: a mirror stores | G2 Recording: | the entries, a witness | a mirror stored the entry | checks consistency, and | G3 Consistency: | each cosigns | relying parties agree on +-------+--------------+-------+ the entry at each index | | | v | +---------------+ | | Update | G5 Validated configuration: | | service: | trusted subtrees were | | validates | validated under the | | landmarks | cosigner policy | +-------+-------+ | standalone | trusted subtrees, | certificate | revoked ranges v v +------------------------------+ | Relying party: checks the | G4 Revoked ranges: | ranges, then the trusted | covered serial numbers | subtree or the cosignatures | are rejected on both paths +------------------------------+

Threat model We start from the Internet threat model , in which the attacker controls the network, and add the compromise of named parties. Each guarantee names the parties it relies on. Every other party, including the CA unless a guarantee names it, may act arbitrarily for the attacker, and may be corrupted at any time, adaptively. A premise on a named party must hold up to the acceptance it concerns, or, for consistency, up to the later of the two acceptances. The network attacker presents the certificate. It can impersonate a server with any credential it holds (). It can withhold or replay updates (), set clocks that synchronize without authentication, cut monitors off from cosigners (), and read trust anchor signals (). Its aims are to impersonate a name to chosen relying parties without the certificate being recorded where that name's monitor looks, and to have a relying party accept a certificate that a revoked range should reject, or one that rests on an unvalidated trusted subtree. We assume that a completed TLS handshake shows that the peer holds the private key for the certificate's public key (Appendix F.1 of ), and that the application checks that the certificate is for the name it wants (). With both, G1 and G2 mean that a relying party that completes a full handshake for a name talks to the holder of a key that the CA key certified for that name and that a faithful mirror recorded. This composition is assumed, not proved here (). A key is intact if it has not been extracted, so that it is usable only through its holder's signing interface. State is intact if it changes only through its holder's specified transitions: it is not lost or rolled back, and not modified except by those transitions. We distinguish three kinds of failure. A party, or its key, is compromised when someone other than its holder can use the key, either by holding it or by driving the module that holds it. The two cases differ where noted: an attacker who only drives the module leaves the key intact, and signs through the party's own interface. A party loses state when its retained state is lost, rolled back, or modified while its key stays secret, for example when an old backup is restored. A party whose state an attacker writes without using the key also loses state, unless the record it checks before signing lies inside the key's trust boundary (), in which case writing it requires compromising the party. A party is malicious when its holder deliberately departs from its specified behavior. A party can also err, through a bug or a misconfiguration, without being any of these. The premises ask that named parties be honest, and an erring party may fail them. A rogue CA is a CA under adversarial control: compromised, malicious, or both. It can sign any view of its logs, append any entries, fork its history, and withhold entries. The design trusts the CA as little as it can. Recording holds against a rogue CA, and so does consistency under the intersection condition of . As today, the CA is trusted to validate identifiers. Root programs oversee that validation, and monitors check it after the fact. No guarantee relies on a monitor or on the authenticating party. A deployment still needs monitors and authenticating parties to act on the guarantees. An honest operator that loses state can break a guarantee as surely as an attacker holding its key. The premises below therefore name cosigners that are faithful to the log in question; one cosigner can be faithful to one log and not to another. A faithful cosigner's key is intact, and it takes only its specified actions for that log. Either its state for that log is intact, or, once it loses that state, it signs no further checkpoint for the log under the same key, as the Recommendations of and ask. Either way, every checkpoint it signs for the log lies on one checked history, joined by verified consistency proofs. A checkpoint signing is a timestamped checkpoint cosignature. A subtree cosignature is not one, even over [0, N), and a witness or mirror makes it only within a checkpoint it already signed (). For the configuration parties, honesty is about behavior as well as keys. An honest update service validates what it publishes and numbers its updates for each CA instance in increasing order. For the bounded-delay form (), it also dates no update later than it signs it. An honest relying party installs and verifies as specified, and keeps its configuration and version floor intact. For the bounded-delay form, it also keeps its clock no more than the stated bound behind real time. Each guarantee concerns a relying party that accepts a certificate on either path. It assumes:

• that the relying party's verifier and configuration are intact ();
• that the keys and parameters in that configuration are authentic, which rests on the update key, even under local validation, and on whoever decides the configuration ();
• that a resumed session inherits the original authentication through its resumption PSK (Appendix F.1 of ; limited in );
• that validation and installation are atomic, that each verification reads one configuration, and that installation applies everything an update carries in one step (); and
• the cryptographic assumptions of .

On the trusted-subtree path, certification, recording, consistency, and the halt bound () also rest on validated configuration (). Beyond these, no guarantee is a premise of another. For example, recording holds against a rogue CA, and certification holds with no mirror configured. Whereas states intended guarantees, each guarantee here is an implication: it holds in a deployment that makes its premises true. collects the parties each guarantee depends on, and sketches why each holds.

G1: Certification Suppose the cosigner policy in effect requires the CA's signature, and the CA cosigner key is intact. Then every accepted certificate corresponds to an entry that the key certified, at exactly that log and index, with exactly the accepted subject, public key, and other fields. The entry is included in a subtree the key signed or, on the trusted-subtree path, in a subtree validated against a checkpoint the key signed (). This holds against a malicious CA, which has certified every entry of every subtree it signed (Sections and of ). It also holds against an attacker who drives the CA's signing module without extracting the key; the entry is then attributed to the key, not to its holder's decision. The entry, its proof, and the signature are evidence that anyone with the CA's public key can check (). G1 also has a stronger form. If, in addition, the CA signs only views of its own append-only log, and its log state is intact, then the accepted entry is the one the CA itself appended at that index. The Recommendation for CAs in describes a signing service that provides these conditions. The entry is the one the CA's certification process approved only if the appending pipeline follows that process. Certification attributes an entry to the key, and so to whoever held it. Once the key may have been compromised, a signature first seen afterwards attributes nothing, unless other evidence shows that it existed earlier, such as an independent cosigner's timestamped checkpoint cosignature (). The CA's own cosignature timestamp is only its claim. Whether the CA validated the identifier, and whether its holder authorized the key, lie outside certification ().

G2: Recording Under a policy that requires a mirror, and given the premises below, a CA cannot have a certificate accepted that no mirror has written down. Suppose the cosigners supporting an acceptance include a mirror that is faithful to the log and follows the two rules of , and that the accepted index is at or above that mirror's initial minimum index, as the Recommendation of arranges. Then that mirror durably committed the exact accepted entry () before its earliest checkpoint signing covering that index, and so before acceptance (). This holds against a rogue CA. Against a malicious CA operator, the operator's own mirror cannot be assumed faithful to the log. Independence from the operator is how a deployment obtains the faithfulness premise in that case. Against a stolen CA key alone, a mirror that the operator runs, with its own intact key, still records. gives one program's test of independence. The supporting cosigners are those whose signatures were actually checked, at acceptance or at validation. A signature that is present but unused does not count, and a witness's signature cannot stand in for a mirror's.Editor's note: No published root-program policy yet sets a threshold per mirror key and log, and no specification yet has a mirror publish its initial minimum index when it is added to a policy (). Recording is in the past tense. It does not say that the entry is still stored, retrievable, seen by a monitor, or authorized. Later loss of the entry does not falsify recording. A mirror's signature does state that the mirror made the entries accessible (), so a later failure to serve them is attributable to the mirror.

G3: Consistency Suppose two relying parties accept entries at the same CA, log, and index, and the cosigners supporting the two acceptances share one that is faithful to that log, as the Recommendations of and ask. Then they accept the same entry. A deployment gets this for every pair of acceptances when every pair of cosigner sets that the policies in effect accept shares such a cosigner. Take a policy that requires the CA cosigner and k of n others, of which at most f are not faithful to the log; these are faulty, for example compromised, malicious, erring, or resumed after losing state. Then 2k > n + f suffices, and in the worst case it is needed. This is the usual quorum-intersection condition, which we call the intersection condition. For a policy built from nested groups, the pairwise condition applies to its acceptable sets directly. The CA cosigner does not count, since a rogue CA signs every branch (), and against a malicious CA operator, the operator's own mirror counts among the f. A cosigner that lost state and stopped signing is an outage, not a fault. Relying parties with different policies, or on different paths, need the condition for every pair of sets across them, including policies still in effect at relying parties not yet updated. Each key counts once. Aliases of one key are one cosigner, and identities that share an operator or a failure domain do not supply independent premises. So f is at least the number of cosigners that one operator or one shared failure can take out. G3 makes acceptances agree with each other, not with any chosen history. Preserving a chosen history is a separate matter (). Without the intersection condition, a rogue CA whose faulty cosigners fill the overlap can show different histories to different relying parties (), and no relying party rejects either. Monitors detect the split if every acceptance is supported by a cosigner that is faithful to the log and whose checkpoints they obtain (). This detection condition is stated here, not proved (). A witness that resumed after losing state signs its fork as an ordinary checkpoint, which monitors see. A malicious cosigner, though, can keep a fork in subtree cosignatures, whose zero timestamp states no signing time or largest observed tree (), so that the fork never reaches a monitor. In Sections and of , each correctly operated cosigner follows a single append-only view, and across cosigners the design relies on this detection. G3 asks that split views be prevented across cosigners too. Under a mirror-backed policy whose supporting mirrors are faithful, each branch is recorded, and a monitor reading every mirror sees any certificate for its name. What is lost is that a serial number no longer names one entry. Ranges and certificate status then apply to both branches, the two paths can disagree, and the root program must answer the equivocation (). Under a witness-backed policy, nothing is recorded. There, a monitor may hold only two checkpoints with no consistency proof between them, and consistency is the only protection.

G4: Revoked ranges While a revoked range covering a serial number of a CA instance is in effect at a relying party, the relying party rejects every certificate of that instance with that serial number. It does so on both paths, before choosing a path (the first rule of , step 4 of ). Rejection, here and throughout, is a failure the user cannot override; where a user can click through, the guarantees do not hold. They constrain new acceptances, not resumed sessions or connections already open; the Recommendation of extends G4 to them. Ranges arrive in updates, under local and delegated validation alike. Suppose that, for each CA instance:

• the relying party installs updates from one designated update service, whose key is intact;
• each update carries the service's complete set of ranges for the instance, not a change to it;
• the service numbers its updates for the instance in increasing order;
• the relying party keeps a version floor for the instance, refusing updates numbered at or below the last one it installed, and keeps the floor and ranges across policy changes and across removal and re-addition of the instance; and
• the relying party applies the installation check of .

Then a range, once installed, stays in effect until the relying party installs a later update from that service that omits it. The floor is a premise because installing an older, validly signed update is otherwise a specified transition of the installer, which intact state does not exclude. Keeping the floor and ranges across removal is a premise for the same reason: otherwise a replayed earlier update, or a routine refresh, re-adds a distrusted instance without its ranges. A fresh install takes its floor and ranges from the configuration bundled with it, which counts only if it came from actual updates of the designated service. The Recommendations below for update services and relying parties state the numbering, completeness, and floor premises. A range names positions, not contents. A rogue CA can append the same certificate again at a new index. Against it, only two things are effective: distrust, or ranges above a cutoff in every log it may still append to, together with rejection of later log numbers (). Distrust can be delivered as a range over every serial number of the instance (), and then the premises above, and the bounded-delay form of , apply to it. A range issued in response to a split view or a compromise is best kept after its known entry expires: under a split view, another entry at that index may carry a later notAfter that nobody saw. Recommendation for update services: An update service numbers its updates for each CA instance in increasing order, and each update carries the service's complete set of ranges for that instance. Recommendation for relying parties: A relying party keeps the version floor and ranges for each CA instance as intact state that survives policy changes, removal of the instance, and distrust.

Bounded-delay form Nothing in bounds how soon a range is installed. A relying party kept from updating, which the network attacker can arrange, stays exposed. Keep the premises of other than numbering and the version floor, and suppose that:

• (a) each update for a CA instance carries a signed issue time, later than that of every earlier update from the service for that instance;
• (b) the relying party accepts a certificate of the instance, on either path, only while the update in effect for it, the last one installed, was issued at most a stated age D before the relying party's clock reading, so that it accepts none while no update is in effect; and
• (c) the relying party's clock is not more than e behind real time.

Let t_z be the issue time of the first update whose ranges cover a serial number s. Then at any acceptance at a real time at or after t_z + D + e, the update in effect is that update or a later one. So a certificate with serial number s is accepted then only if a later update, installed before then, does not cover s. Because installation applies an update in one step, everything else it installs from that update is at least as new. sketches the argument for ranges. The same argument covers the instance's whole configuration where every update carries all of it (). Without (a), a fresh-looking update could predate the range. Without (b), nothing bounds the delay, and expiring trusted subtrees only moves certificates to the cosigner path. Without (c), setting the clock back extends D; a clock that runs fast only fails closed. The floor is not needed for the bound, since a replayed older update looks stale and (b) rejects it. Without the floor, though, a replay re-exposes a relying party that installed the range promptly, until t_z + D + e. A deployment adopts the bounded-delay form or not. It departs from the default of , under which a relying party whose landmarks are too stale keeps accepting standalone certificates. Its main cost is availability: an attacker who blocks updates for longer than D turns exposure into an outage for every MTC site of the instance. Premise (c) also needs a time source that the network attacker, who withholds the updates, cannot also set. gives the other costs, and how the delay that users see adds up. A deployment states its D, or states that it has none.

G5: Validated configuration Suppose validation is local, or is delegated to an honest update service whose key is intact. Suppose also that validation records the cosigners it verified (the Recommendation of ), and that the relying party applies the installation check of and the retention rule of . Then each trusted subtree at the relying party corresponds to a validation for exactly that CA, log, interval, hash parameters, and hash. That validation's recorded evidence satisfies the cosigner policy and bindings now in effect, as describes. Acceptance on the trusted-subtree path inherits the assurance of that validation and no more. Trusted subtrees bundled with a fresh install count only if they too came from such a validation. A validation survives a change of cosigner policy only if its recorded evidence satisfies the new policy (). Removing a trusted subtree is not revocation ().

What is not provided Several properties that one might expect lie outside the guarantees. Authorization. Nothing in MTCs shows that the CA validated an identifier correctly, and witnesses and mirrors do not repeat that validation. Nor does anything show that the CA checked the subject's key. The log carries only the key's hash, so rejecting weak keys is a check before the append. Monitors cannot repeat it from the log alone, only by fetching keys elsewhere, such as from servers (). Eventual visibility. aims for every accepted certificate to be visible to monitors. The guarantees here cover the recording part of that aim; pursues the rest through availability policies that relying-party vendors enforce. Visibility also needs retention and serving: a monitor sees the entry only if the CA or a mirror retains and serves it (), and against a rogue CA, only a mirror counts. The monitor must also fetch and parse the entry. Timely response. A root program's decision binds a relying party only once it is installed there. A version floor prevents rollback but reveals nothing about a withheld update. Only the bounded-delay form () bounds the delay. Limits on a compromised CA. A certificate's notAfter, checked against a correct clock, bounds how long the certificate can be newly accepted. A root program's maximum lifetime does not bound that time, because a compromised CA chooses the validity interval. Neither bounds how long a resumed session lasts, or whether new entries are issued (). Uniform assurance. For a given name, the assurance is that of the weakest certificate the relying party will accept, including any directly signed fallback (). Subscriber key compromise. A subscriber whose key is compromised requests revocation of its certificate, and CRLs and OCSP apply unchanged (Sections and of ). A relying party that consults neither accepts the certificate until its notAfter, unless the root program ships a per-entry range. Such a range is a tool for incidents rather than routine revocation ().

Summary of premises Each guarantee below also assumes the common premises of and , including, on the trusted-subtree path, those of G5.

G1 Certification:

Rests on the CA cosigner key. The stronger form also needs the CA to sign only views of its own log, with intact log state. Holds against a rogue CA unless the key is extracted.

G2 Recording:

Rests on a supporting mirror's key, and on that mirror being faithful to the log and following . Against a malicious CA operator, that mirror is one the operator does not run. The accepted index is at or above the mirror's initial minimum index. Holds against a rogue CA.

G3 Consistency:

Rests on the key of a cosigner shared by the two acceptances' supports, and on that cosigner being faithful to the log and following or after state loss. To hold for every pair of acceptances, every pair of acceptable sets shares such a cosigner, which needs the intersection condition of . Holds against a rogue CA.

G4 Revoked ranges:

Rests on the update key; one designated service per CA instance, numbering complete updates; a version floor and ranges kept across policy changes, removal, and distrust; and the installation check. The bounded-delay form drops numbering and the floor, and adds signed increasing issue times, the age bound D, and a clock at most e behind real time from a source the attacker cannot set. Holds against a rogue CA for the positions named.

G5 Validated configuration:

Rests, under delegation, on the update key and on a service that publishes only what it validated; and on the installation check and the retention rule. Holds against a rogue CA.

Deployment choices Three choices decide which guarantees a deployment can have and what they cost: which cosignatures relying parties require, who validates trusted subtrees, and which certificates servers send.

Cosigner policy The cosigner policy decides which of certification, recording, and consistency are available at all (). Each still needs the premises of . Requiring the CA cosigner in every acceptable set is what makes certification available. Sections , , and of advise a transparency-enforcing relying party to require a quorum of other cosigners as well. Root programs' current policies, and the guarantees they make available, are discussed in . Cosigner policies and the guarantees they make available

Policy	Required signatures	Guarantees made available
CA-only	CA cosigner	Certification
Witness-backed	CA cosigner and a quorum of witnesses	Certification; consistency where every pair of quorums shares a faithful witness
Mirror-backed	CA cosigner and a quorum of mirrors, optionally witnesses	Certification and recording; consistency where every pair of quorums shares a faithful cosigner

Quorum size trades consistency against availability and size. A policy that requires the CA cosigner and k of n others tolerates n - k outages. But the CA chooses which acceptable set to use, and a rogue CA chooses sets that share no faithful cosigner. Consistency therefore needs 2k > n + f, where at most f of the n are faulty (). Tolerating u outages as well needs n > f + 2u while the f keep signing. If they withhold, it needs n > 3f + 2u, with k <= n - f - u. An attacker who wants issuance stopped has them withhold. At f = 1:

• n = 4 and k = 3 tolerate one outage, but only while the faulty cosigner signs, at 13.8 kB per handshake with a standalone certificate ().
• n = k = 2, the cheapest, costs 11.4 kB and tolerates none.
• n = 6 and k = 4 tolerate one outage and one withholding cosigner, at 16.3 kB.

The CA cosigner is in every set but does not count toward the intersection: against a rogue CA, it is the party that the intersection must not depend on. Any two sets acceptable under policies that require k1 of S1 and k2 of S2 share at least k1 + k2 - m cosigners, where m is the number of cosigners in S1 or S2. The two policies are consistent with each other if that number exceeds the number of faulty cosigners among those. Sizes constrain only the cosigner path. Landmark-relative certificates carry no cosignatures, so the policy for the trusted-subtree path can require a quorum that meets 2k > n + f at no cost in certificate size. Such a quorum gives consistency on the trusted-subtree path. Pairs of acceptances across the two paths still need the condition across both policies (). Mirror eligibility is part of the policy too. The simplest rule is one the program checks once. It admits a mirror for a log only if the mirror starts at index zero, as it can for a log number accepted in advance, or at or below a pruning bound that the program ships as a revoked range (), the kind of "per-log lower bound" that asks pruning log applications to define. Then b is zero for every relying party that lags less than the program's retention margin (), and verifiers keep no state per mirror. Otherwise, the threshold b of travels with root-program metadata and policy formats, and every verifier applies it.

Local or delegated validation

Local validation:

The relying party fetches landmarks and cosignatures and checks them against its own policy. It depends on its update channel only for policy and ranges. It needs the cosigner keys, bandwidth, and a clock that applies landmark expiry (, ). It also reveals which CAs and intervals interest it ().

Delegated validation:

An update service validates and ships the resulting trusted subtrees, and the relying party depends on the service having done so. Authenticating an update establishes its source and content, not that its subtrees were validated. A party with authority to validate can install a wrong subtree for every relying party it serves (). The update's signature sets the subtrees' resistance to quantum attack ().

Authenticating an update does not show that it fits the relying party's configuration. An authentic update validated under an earlier policy and delivered after a change would install subtrees that the current policy rejects. An update for one CA instance, or from another service, could change an instance's ranges or floor. When one numbered update carries both a policy and the subtrees validated under it, the floor and an honest service already exclude the first case. The check below matters where policy reaches the relying party separately, for example with the verifier. Recommendation for relying parties: A relying party installs an update only if the update names the CA instance it is for and comes from the update service designated for that instance. From such an update, it installs only those subtrees whose recorded evidence satisfies the cosigner policy and bindings in effect. An update that carries only ranges needs no policy check.Editor's note: (version -08) leaves the update channel out of scope, so this Recommendation has no counterpart there.

Certificates served An authenticating party whose TLS stack selects by trust anchor holds three kinds of certificate, and chooses among them per connection:

• A standalone certificate is usable at once, but carries a signature per required cosigner.
• A landmark-relative certificate carries no required signatures and rests on the hash function alone (). But it is usable only once a covering landmark has arrived.
• A directly signed certificate is for clients without MTC support.

A server whose stack installs one chain per name cannot use the trusted-subtree path. It can still carry a standalone certificate embedded in its conventional one , which relying parties find by path building, with no certificate selection. intends this only for classical endpoint keys, which leave the weaker path described below. The embedded proof, about 5.3 kB with the CA and one mirror, then goes to every client, and logged final certificates carry it too. A relying party that accepts several kinds for a name gets the assurance of the weakest. Under the bounded-delay form, a directly signed certificate stays in a server's inventory for relying parties past D (). So migrating to post-quantum authentication concerns every credential that a relying party still accepts for a name, not only the one a server prefers. An MTC for a classical endpoint key, or an accepted classical alternative, leaves a weaker path (). TLS downgrade protection does not close it ().

Who decides assigns each decision an owner. The examples of cadence and renewal are 's (Sections 6.5 and 10.4), except the landmark limit. The examples of policy, cadence limits, retention, and log numbers are from as of version 0.4.0 (Sections 2.4.5; 2.6.2; 2.5.1.3 and 3.2.4; and 2.5.1.3). The rest are illustrative. Operational decisions

Decision	Owner	Example
Checkpoint and landmark cadence	CA, within root-program limits	2 s; hourly, at most 220 landmarks per 7 days
Cosigner policy and lifecycle	Root program	CA and one mirror; CA and k of n
Mirror eligibility	Root program, mirror	Start at zero, or threshold b
Who validates; update channel	Relying-party vendor	Daily component update
Standalone certificate as fallback	Server configuration; CA default (trust_anchor_negotiation)	Not a fallback under the bounded-delay form
Freshness, version floor	Relying-party vendor or organization	Age D, then fail or fall back
Retention past expiry	Root program, CA, mirrors	35 days; mirrors may prune after 90
Log-number bound	Root program, cosigners	5 logs per CA key
Monitor scope	Subjects, monitors	Every trusted cosigner
Renewal window	CA suggests (ARI); client decides	Renew at 75%
Alternatives held; when to swap	Authenticating party	Keep the old certificate until expiry

states the condition for retention. The number, and with it the configuration lag that a program supports, is the root program's ().

Configuration lifecycle A root program's decision becomes a validated, authenticated update. Each relying party installs that update on its own schedule. Relying parties therefore do not share one configuration, and every guarantee is about a relying party's configuration in effect.

Changing the cosigner policy Validation establishes consistency with the policy in effect at the time, and acceptance on the trusted-subtree path does not repeat it. When a CA instance's cosigner policy changes, a relying party keeps the trusted subtrees whose recorded evidence satisfies the new policy and discards the rest. Adding a mirror to a policy that accepts any one of several keeps every subtree. Replacing mirror A by mirror B keeps only the subtrees whose validation also verified another acceptable mirror: A's evidence says nothing about what B recorded, and matching version labels show nothing. Removing a compromised key keeps only the subtrees that suffice without it. Under delegation, one update can carry a new policy together with subtrees revalidated under it. Then no gap need open, if installation applies the policy before checking the subtrees, in one step. Until revalidation, certificates under discarded subtrees are accepted only on the cosigner path (). A landmark group covers every landmark up to its number (), so a relying party that discarded older subtrees but kept later ones advertises individual landmarks, or only the CA ID, until then. This costs bandwidth and availability, not security (). Recommendation for relying parties and update services that validate: A validation, local or delegated, records the cosigners whose signatures it verified, under their identity, key, and hash bindings. Recommendation for relying parties: Atomically with a change of a CA instance's cosigner policy, a relying party discards each trusted subtree of that instance whose recorded evidence does not satisfy the new policy.Editor's note: requires trusted subtrees to be consistent with the relying party's cosigner requirements, but version -08 does not yet say how that is kept across a policy change: that a validation records the cosigners whose signatures it verified, and that a policy change discards trusted subtrees whose recorded evidence no longer satisfies the new policy.

Cosigner lifecycle Certificate Transparency policies such as keep an SCT acceptable if its log was trusted when the SCT was issued. That rule cannot be enforced on the cosigner path, because cosignatures carried in certificates have a zero timestamp (). On that path, a cosigner is retired by position, with a per-log index bound. The bound comes from the cosigner's last timestamped checkpoint cosignature, best taken from cosignatures the program collected itself rather than from the cosigner's own endpoint. A retired key that is later compromised can still sign below its bound, so retirement narrows exposure without ending it. For a cosigner that signed inconsistent views, a bound above the first index where the branches diverge keeps both branches acceptable. Only comparing the branches finds that index. Such a cosigner is therefore bounded at or below that index, or removed, with ranges over the forked indices on both branches (). A removed cosigner's signatures are invalid only at relying parties that have the update. If every update carries the complete cosigner policy, removal behaves like a revoked range. The arguments of for persistence and for the delay bound then cover it, provided policy reaches the relying party no other way. If instead policy travels only in the updates that change it, a replayed earlier update restores a removed cosigner, while later updates keep the configuration looking fresh. Only the floor prevents that replay, and even the floor does not stop an attacker who withholds the update that removes a cosigner while delivering later ones.

Revoked ranges, removal, and distrust A relying party has four separate operations. Removing a trusted subtree discards a validation result, and the entries remain acceptable on the cosigner path. Adding a revoked range rejects every certificate in it on both paths (). Distrusting the CA instance removes it. Certificate status through CRLs and OCSP continues to apply (). The exception is where no key may sign status for an instance (). calls revoked ranges complementary to certificate-level revocation, and likens index-based ranges to SCTNotAfter. They carry no reason code, and they neither impose nor discharge the CA's revocation obligations.

Log numbers A new log is a new history, with its own origin (, ). Witnesses and other non-CA cosigners are expected to accept the next few log numbers in advance (). That way, the CA can move to a new log on its own after a failure. The same window lets a rogue CA open a fresh history that every pre-configured cosigner follows from its first view. Bounding log numbers limits fresh histories. Stopping new acceptance from an earlier log also needs a per-log index bound () or a cosigner halt (). For example, accepts log numbers 1 through 5 per CA cosigner key, and requires each move to a new log to be reported as an incident (Sections 2.5.1.2 and 2.5.1.3).

Updates and recovery The guarantees ask the following of the update channel:

• updates that are complete for each CA instance and bound to it and to its service (, );
• a version floor that survives policy changes, removal of the instance, distrust, and rotation of the update key;
• installation of a policy together with the subtrees validated under it, in one step ();
• signed increasing issue times for the bounded-delay form (); and
• an encoding kept apart from everything else the update key signs ().

These answer what calls rollback, mix-and-match, and indefinite-freeze attacks. gives generic defenses against them. A deployment also states:

• which related changes are atomic;
• how each acceptance obtains one consistent configuration; and
• when an older, validly signed update may replace a newer one.Editor's note: (version -08) does not prescribe how relying parties obtain trusted subtrees, so it defines no update format, version counter, or recovery procedure, and no specification yet profiles the defenses of for MTC configuration. Whether the requirements above are stated in , in root-program requirements, or in a profile of an update framework is for the working group to decide.

Any such recovery path voids the persistence of while it is in use, though the bounded-delay form still bounds exposure. Rotating the update key needs the version floor to be carried across.

Deployment considerations

Sizes gives the authentication data per handshake for SHA-256 and ML-DSA-44 , from the estimates of Sections , , and of for a large CA with 7-day certificates. gives the arithmetic and its assumptions. A standalone certificate beats the conventional chain only under the CA and one other cosigner, or up to the CA and three other cosigners if the intermediate is sent. The policies that meet the intersection condition cost more on the cosigner path (). In practice, what separates policies is the share of handshakes that are landmark-relative, and the limits of TCP and QUIC (). Handshake authentication data with ML-DSA-44, in bytes

Certificate	Proof and signatures	Per handshake
Conventional: CA signature and two SCTs, intermediate omitted ()	7,260 B	10,992 B
Landmark-relative	755 B	4,487 B
Standalone, CA and one mirror	5,257 B	8,989 B
Standalone, CA and two cosigners	7,684 B	11,416 B
Standalone, CA and three cosigners	10,111 B	13,843 B
Standalone, CA and four cosigners	12,538 B	16,270 B

Renewal and configuration lag Renewal overlaps the old and new certificates, except after an endpoint key compromise (). The overlap bounds the configuration lag that the trusted-subtree path tolerates: the time from the actual renewal to the old certificate's expiry, minus the landmark interval. This assumes that the server keeps the old certificate until expiry, as recommends. A server that replaces its certificate in place sends the standalone certificate to every relying party until the new landmark reaches it; estimates that share. With 7-day certificates renewed at 75% of their lifetime and hourly landmarks, a relying party whose configuration lags by more than about 41 hours receives the standalone certificate for part of every renewal cycle ().

Security considerations This section considers the effect of compromising each service, the risks that remain whichever party is compromised, and what lies outside the threat model of . For each guarantee, gives the services whose compromise defeats it.

Compromise of the CA An attacker holding the CA cosigner key, or able to call its module, can certify entries that the CA never validated and fork its history. Recording and consistency survive under their own premises. Faithful cosigners, though, record misissuance that is consistent with the history they hold. Recording makes misissuance available for inspection, not impossible (). A new log number addresses a failed log. Only a new CA instance addresses a compromised key (, ). An attacker that drives the module without extracting the key loses access when the compromise ends. What it signed, though, remains valid. Afterwards, every pre-configured cosigner would still follow a checkpoint that the attacker signed during the compromise for a log number accepted in advance (). Recovery without replacing the key therefore still needs later log numbers to be rejected, and the entries of the exposure window to be revoked (). This is why replacing the key is the safe course. Distrust and revoked ranges stop a compromised CA only once installed at each relying party. Cosigners that stop signing the log's checkpoints can bound its new issuance sooner, under the premises of .Editor's note: No specification assigns the role of deciding such a halt. Removing a log's key from the configuration of a witness or mirror need not stop sign-subtree, which takes a checkpoint that the cosigner itself signed (, ), and has witnesses and other non-CA cosigners accept the next few log numbers but defines no halt that covers them. Where such a halt is specified is for the working group to decide. Recommendation for cosigners: A cosigner's halt of a log:

• is atomic with its checkpoint signing;
• refuses every checkpoint signing for the log, including one that completes a mirror's pending checkpoint;
• survives restarts and routine reconfiguration, and cannot be rolled back or cleared by a replayed or older notice;
• covers the CA instance's later log numbers; and
• keeps the cosigner's retained records and monitoring endpoint available.

A response that preserves selected history, rather than withdrawing trust in the CA instance, needs a prior authenticated commitment to that history; a cutoff alone does not suffice ().

Compromise of relying-party configuration The effect of compromising a party that contributes to configuration is the authority it holds:

• Authority to validate lets an attacker install a subtree that no evidence supports. This defeats certification, recording, consistency, and the halt bound on the trusted-subtree path.
• Authority over policy or ranges changes which evidence suffices.
• Authority only to deliver updates lets an attacker withhold them, leaving relying parties exposed or, under the bounded-delay form, failing closed. It can also replay older ones, which the version floor stops. It cannot make a relying party accept anything new, since G5 and both forms of G4 rest on the update key, held by whoever validates and publishes.

Rolling back local configuration bypasses every guarantee that depends on it. Local validation protects against a compromised delivery party, not against the authority that decides policy or ships the verifier.

Compromise of a witness, mirror, or monitor Consider a witness or mirror whose key is compromised, or one that lost state and resumed. Such a witness or mirror can defeat consistency wherever it is the only otherwise-faithful member shared by two acceptable sets. Such a mirror can also defeat recording for every acceptance in which it is the only supporting mirror. A witness or mirror that signed inconsistent views is answered as in . A compromised monitor can suppress findings but changes nothing a relying party accepts ().

Availability A required cosigner's outage delays issuance. Its signing interfaces authenticate no requester:

• A witness signs on add-checkpoint, whose only authentication is the log's signature.
• A mirror signs when add-entries completes, even an empty one at its current size ().
• Either signs on sign-subtree, whose only authentication is its own earlier cosignature ().

Anyone can therefore replay requests to load a cosigner, which attacks issuance where signing is the bottleneck, such as with a key in a hardware module. Returning the cosignature already made for an unchanged checkpoint removes the cost of replays. Rate limits per log would instead let anyone spend a CA's share. Neither defense bounds fresh sign-subtree requests for distinct subtrees of a checkpoint already signed. Requesting signatures "from a redundant set of cosigners" () absorbs outages. Blocking configuration delivery freezes a relying party's trusted subtrees and revoked ranges. A CA that withholds entries or prunes early creates a serving failure. Monitors learn the missing index, and so its serial number (). One failed retrieval, though, does not distinguish withholding from an outage.

Residual risks Some risks remain beyond the guarantees:

• Resumption. Ranges, distrust, and cosigner removal constrain new acceptances only. An impersonator issues its own tickets, which can extend the original authentication indefinitely (, ).
• The weakest credential (). TLS's downgrade protection covers negotiated parameters (Appendix F.1 of ), not which credential an impersonator presents.
• Targeting. Advertised landmark identifiers can show which relying parties lack a range ().

Recommendation for relying parties: A relying party retains the original acceptance's CA instance, serial number, path, and supporting cosigners. Before resuming a session or reusing a connection, it:

• checks them against the ranges, distrust, and cosigner removals in effect;
• under the bounded-delay form, applies (b) of ; and
• limits the time since the last full handshake (), under the bounded-delay form to D.

Outside the threat model As in , parties named in a premise are assumed to implement their specifications. The party that can replace the verifier can make it accept anything. A root program's policy process, the quality of identifier validation, and the security of servers' hosts are assumed.

Cryptographic and representation interfaces The guarantees assume:

• collision resistance of the log hash;
• unforgeability of cosigner signatures;
• unforgeability of update signatures, for every guarantee since configuration arrives under them, and in particular for G5 under delegation and for both forms of G4;
• exact reconstruction of the entry from the certificate (Sections and of ); and
• signing interfaces that keep cosigner messages separate from other uses of the key ().

does not define updates (). For updates, the guarantees likewise assume an encoding that binds instance, service, version number, issue time, and complete contents, kept apart from everything else the update key signs. An MTCProof is not a unique representation of a certificate (). So incident reports and revocation tooling identify a certificate by its TBSCertificate, or, where no split view is in question, by its CA instance and serial number (). offers one signature algorithm, ML-DSA-44 (, ), and no hybrid. Acceptance on the trusted-subtree path rests on the hash function alone. But every guarantee also rests on the update key, under local validation too, and on whoever can replace the verifier (). So the post-quantum security of every guarantee includes the algorithms of the update and verifier signing keys, which a deployment states.

Analysis sketches why each guarantee of holds under its premises, together with the storage lemma behind the mirror rules of and the halt bound of . The argument for G4 also covers cosigner removal and the rest of a CA instance's configuration, where every update carries all of it (). Three further claims are stated without a sketch: CA log recovery (), the split form of single initialization (), and an update service acting as a witness (). We are working on a companion analysis that gives full proofs. The arguments are over ordered traces of the services' specified actions. Each is meant to either establish its conclusion or construct, from the execution, a hash collision or a signature forgery. They derive no probability bounds and are not implementation refinements. A reference clock appears only in the bounded-delay form of G4. The arguments other than G5's are for local validation, and carry over to delegated validation through G5; the stronger form of G1 is argued on its own, not from the basic form. For updates, under either kind of validation, they assume one designated update service and key per CA instance at each relying party. They are stated for the Web PKI deployment. Their trace model does not depend on that deployment, but other deployments are outside their scope. They do not cover:

• TLS handshakes or their composition with these guarantees, connections already open, or resumed sessions, including the resumption check of ;
• the bounded-delay form's variants that measure age from installation, use a signed time over a nonce, or use one counter for both;
• configuration other than ranges, including cosigner removal, where updates carry only changes to it or it also reaches the relying party by another route ();
• replacement of the update key or service;
• the CA log recovery of where the signing service persists its record after using the key, before releasing the signature;
• the detection condition of ; and
• the second-CA-signature hedge of .

Privacy considerations Public logs disclose issuance, though subject keys appear only as hashes. Advertised landmark identifiers reveal a relying party's update state (Sections and of ). Deployments choose:

• whether the identifiers are sent on every connection, only when the server offers them, for example in its HTTPS/SVCB record (), or only in recovery;
• whether landmarks from many CAs are delivered together; and
• whether new landmarks are activated after a delay, so that relying parties updated at different times look alike.

In practice, a relying party that withholds the identifiers until recovery trades the trusted-subtree path for that privacy, since recovery follows only a failed connection (). Local validation reveals a relying party's interest in a CA, log, and interval to the server it retrieves from. Delegated validation concentrates that at the update service, where stored-data compromise and secondary use become the concerns. Measurements of landmark lag are population-level telemetry and are reported only in aggregate. When ranges and landmarks travel in the same updates, advertised landmark identifiers also show a network attacker which relying parties have not yet installed a revoked range. This is a sharper form of the targeting of that detection no longer offsets. Activating landmarks after a delay, with ranges effective at installation, weakens the signal. The bounded-delay form () bounds the window. Sending identifiers only when the server offers them does not help against an active attacker, who plays the server. Encrypted Client Hello hides the identifiers from passive observers. It does not hide them from the server the client encrypts to, and an attacker that supplies the client's ECH configuration can be that server.

IANA considerations This document has no IANA actions.

References Normative References C2SP Google LLC Apple Inc. Cloudflare Cloudflare Geomys This document describes Merkle Tree certificates, a new form of X.509 certificates which integrate public logging of the certificate, in the style of Certificate Transparency. The integrated design reduces logging overhead in the face of both shorter-lived certificates and large post-quantum signature algorithms, while still achieving comparable security properties to existing X.509 constructions and Certificate Transparency. Merkle Tree certificates additionally admit an optional size optimization that avoids signatures altogether, at the cost of only applying to up-to-date relying parties and older certificates. Work in Progress C2SP This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. OpenSSL Google LLC Meta This document defines the TLS Trust Anchors extension, a mechanism for a TLS client or server to select a certificate to present based on the peer's trusted certification authorities. It describes certification authorities more succinctly than the TLS Certificate Authorities extension. Work in Progress C2SP C2SP C2SP Informative References Apple Apple Apple Apple CA/Browser Forum C2SP Google Chrome Google Chrome Chrome Secure Web Networking Team Google Chrome Release candidate 1.0.0, commit c5a8a8eceafc Passive and Active Measurement (PAM 2017) Transparency.dev Summit 2025 DigiCert and Google Chrome ct-policy mailing list Apple Mozilla Mozilla Bugzilla, bug 2083449 Google Chrome and Android Security Teams Outside the Stacks Blue Cross Blue Shield of Michigan The migration of public Web PKI authentication to post-quantum mechanisms must fit enterprise certificate management and TLS termination architectures. This document examines whether an urgent need for post-quantum authentication would justify transitional support for standalone ML-DSA certificates in browser root-store policy while standalone MTC deployment capabilities mature. The scope is limited to enterprise public websites accessed by unmanaged clients using the public Web PKI. Note: a large enterprise may operate many such sites. The document describes enterprise-managed, third-party-hosted, and CDN-fronted deployments, identifies the components needed to serve standalone Merkle Tree Certificates (MTCs), and examines realistic authentication attack paths and migration priorities. It distinguishes the browser-to-edge connection from origin and internal connections, and server authentication from identity-provider login. The document draws on initial browser and TLS client testing of Trust Anchor ID signaling, and proposes interoperability tests and deployment requirements rather than changes to the MTC wire format. Relative priorities are illustrative and not empirical attack probabilities. Work in Progress National Institute of Standards and Technology Let's Encrypt Transparency.dev Summit 2024 Sectigo ct-policy mailing list Mozilla All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group. This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912. This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. The Messaging Layer Security (MLS) protocol (RFC 9420) provides a group key agreement protocol for messaging applications. MLS is designed to protect against eavesdropping, tampering, and message forgery, and to provide forward secrecy (FS) and post-compromise security (PCS). This document describes the architecture for using MLS in a general secure group messaging infrastructure and defines the security goals for MLS. It provides guidance on building a group messaging system and discusses security and privacy trade-offs offered by multiple security mechanisms that are part of the MLS protocol (e.g., frequency of public encryption key rotation). The document also provides guidance for parts of the infrastructure that are not standardized by MLS and are instead left to the application. While the recommendations of this document are not mandatory to follow in order to interoperate at the protocol level, they affect the overall security guarantees that are achieved by a messaging application. This is especially true in the case of active adversaries that are able to compromise clients, the Delivery Service (DS), or the Authentication Service (AS). This document specifies how an Automated Certificate Management Environment (ACME) server may provide suggestions to ACME clients as to when they should attempt to renew their certificates. This allows servers to mitigate load spikes and ensures that clients do not make false assumptions about appropriate certificate renewal periods. This document describes a mechanism in Transport Layer Security (TLS) for encrypting a message under a server public key. Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described. This document defines a placeholder X.509 signature algorithm that may be used in contexts where the consumer of the certificate is not expected to verify the signature. As part of this, it updates RFC 5280. C2SP C2SP TLS Working Group tls-trust-anchor-ids pull request 138 The Update Framework Google LLC TurboLight Solutions, LLC Entrust Cryptic Forest Software This document defines a mechanism to embed one or more alternate certificates within a single outer certificate. The outer certificate remains parseable to a legacy relying party that is unaware of this specification. Each alternate certificate certifies the same subject information, but with a different issuer. This can be used to help TLS on the Web transition securely to post-quantum authentication, as well as other PKI transitions with similar constraints. Work in Progress Entrust Limited Bundesdruckerei GmbH UK National Cyber Security Centre AppViewX Inc Merkle Tree Certificates (MTC) I-D.ietf-plants-merkle-tree-certs has been defined for the use case of the WebPKI. In this document we explore when and how MTC in parts or full can be used in different use cases. Some of this use-cases may provide benefit for private PKI usage. Work in Progress

Basis for the guarantees This appendix sketches why each guarantee holds under its premises, in enough detail to judge whether those premises are the right ones. states the limits of these arguments. In the model, each party is a state machine with declared actions. For example, a mirror may sign a checkpoint only after storing the entries it covers. Parties named in a premise meet it as defines, and all other parties are adversarial. Each result says that either the conclusion holds, or a hash collision or a signature forgery can be extracted from the execution. Three facts recur:

• Signature provenance. A signature that verifies under an intact key was produced by that key's signing operation on exactly that message. This needs the signed messages of , and the update encoding of , to encode injectively and to be separate from the key's other uses (). It also needs the identity, key, and hash bindings to be fixed: a cosigner policy selects among them and never reinterprets one.
• Configuration provenance. Every trusted subtree in effect carries a record of an actual validation under the cosigner policy and bindings now in effect. Under local validation, this follows by induction over the relying party's actions. The relying party starts with no trusted subtrees, or with only ones that came from such validations. Validation and installation are atomic. Each verification reads one configuration. A policy change keeps only the subtrees whose recorded evidence satisfies the new policy, and that record and its check results are fixed when validation completes. Under delegation, an honest update service and the installation check supply the same record ().
• Openings. Inclusion and consistency proofs combine into an opening of an entry against a later checkpoint, and two openings at one index, against checkpoints of one checked history, agree ().

G1:

Signature provenance shows that the CA key signed the subtree, or, through configuration provenance, a checkpoint that the subtree is consistent with. The opening and exact reconstruction () bind the entry to the certificate. Only the key is used, through its signing operation. An attacker who drives the CA's signing module uses that operation too, so the basic form needs no premise about the CA's behavior. An extracted key signs outside that operation, and the premise of an intact key excludes this. The stronger form adds that an honest CA signs only views of its own append-only log and keeps that log's state intact. So the opening identifies the entry that the CA appended.

G2:

Storage lemma. Let a mirror follow the two rules of for a log, with initial minimum index m0, and let j >= m0. At the mirror's earliest checkpoint signing covering j, entry j was durably committed. Before that signing, either the mirror had signed nothing for the log, or every size it had signed was at most j. In the first case, its minimum index was at most m0. In the second case, by the minimum-index bound, its minimum index was at most j. Either way, j was at or above the minimum index, and commits every covered entry at or above the minimum index before signing. Single initialization is what fixes m0. A mirror started again at a larger minimum index under the same key would, at its first signing, cover entries it never stored. Backfill stores entries that earlier signings covered without storing. It changes nothing committed before those signings, so it cannot lower b. G2. Signature provenance traces the mirror's supporting signature, or the checkpoint signature that a subtree cosignature rests on, to a signing at or after that earliest one. The opening makes the committed entry the accepted one. No premise about the CA is used. The result also holds for a mirror that lost state for the log and signs no checkpoint for it again. Every signing that the result relies on precedes the loss, so the argument runs on the part of the execution before the loss.

G3:

The supporting cosigners of the two acceptances share one that is faithful to the log. A faithful cosigner signs only checkpoints in one checked history, or subtrees consistent with one of those checkpoints. With intact state, that history is the one the cosigner holds. After a loss of state, it is the history the cosigner held just before the loss, since the cosigner signs no checkpoint for the log afterward. Both acceptances open against checkpoints of that history, so they agree. The quorum bound follows by counting: two sets of k drawn from n share at least 2k - n members, of which at most f are not faithful to the log. Conversely, suppose 2k <= n + f. Then a rogue CA can choose two acceptable sets whose common members are all among f faulty cosigners. It can have those cosigners sign both of two histories that differ at one index, and show one history to the rest of each set.

G4:

The decision checks revoked ranges before choosing a path (), so a range in effect rejects on both paths. Persistence. Only installing an update from the designated service changes the ranges that service supplies for a CA instance. Local actions, policy changes, and removal of the instance leave those ranges and the floor alone. The installation check keeps another instance's or another service's update from touching them. Signature provenance makes each installed update an actual publication of the service. The floor makes each installed update numbered above the last, and the service's numbering makes that a later publication. Each update carries the service's complete set of ranges, so a range leaves only through a later publication that omits it. Bounded-delay form. Let t_z be the issue time of the first update whose ranges cover the serial number s. Consider an acceptance at a real time at or after t_z + D + e. By (c), the relying party's clock then reads at least t_z + D. So, by (b), an update is in effect, the last one installed, and it was issued at or after t_z. It is an actual publication of the designated service, so by (a) it is the first update whose ranges cover s, or a later one. Since updates are complete, its ranges are the ones in effect. Neither numbering nor the floor is used.

G5:

Under local validation, this is configuration provenance. Under delegation, signature provenance on the update key identifies an actual publication. An honest service publishes only records of its own validations. The installation check re-evaluates each subtree's recorded evidence against the policy and bindings in effect at installation. The retention rule re-evaluates that evidence at every later policy change. So the evidence satisfies the policy in effect at use. G1 to G3 then transfer, with forgery of the update signature as one more failure event. For G3, the two relying parties may use different services. Without the installation check, an authentic update validated under an earlier policy installs subtrees that the current policy rejects.

Halt bound:

Suppose every set acceptable under the policy in effect at an acceptance includes a member of F that is faithful to the log, and each such member has halted it. Then the actual support of that acceptance includes one such member. On the cosigner path, this holds directly. On the trusted-subtree path, it holds through configuration provenance, whose retention rule keeps only subtrees whose recorded evidence satisfies that policy. That member's signature traces to a checkpoint signing, directly or, for a subtree cosignature or a trusted subtree validated after the halt, through the checkpoint signature it rests on. The halt places that signing before the halt. The accepted entry opens against that checkpoint, so its index is below the checkpoint's size. Only the halted member is used, so the argument holds for witnesses as well as mirrors, and under delegated validation with an honest update service.

Deployment notes This appendix collects deployment detail that supports the guarantees but is not needed to state them.

The bounded-delay form in practice The bounded-delay form of has these costs:

Availability:

Beyond the outage of , the service must publish for every instance more often than D less delivery delay and however far ahead relying parties' clocks may run. Otherwise its relying parties reject that instance. Until a fresh install updates, it rejects every instance whose bundled configuration is older than D.

Posture:

degrades a stale relying party to standalone certificates ("If this landmark information becomes too stale, such a relying party SHOULD switch to advertising just the CA ID"). (b) rejects those too. Past D, the remaining alternative is a directly signed certificate with its CRL and OCSP revocation, which under is classical (the Introduction). That certificate's assurance then sets that of the name (). For the server to send the directly signed certificate, a relying party past D stops advertising every trust anchor identifier of the instance, including the bare CA ID. The bare CA ID would otherwise select a standalone certificate, which the relying party then rejects. In the timestamped landmark groups of , base.V and base.V.T both match standalone certificates of every CA in the group. With those groups, the relying party lists the other CAs' identifiers instead. The standalone certificate must also not be chosen as a fallback, through trust_anchor_negotiation, which leaves optional, or through the server's own configuration (). Otherwise, only the recovery of , at a round trip, reaches the directly signed certificate. It does so only if that certificate's path has a trust anchor identifier. That section also tells a client that rejected a path for a reason other than its trust anchor, such as a relying-party constraint, not to request that trust anchor again when it retries. Never sending the standalone certificate as a fallback also withholds it from relying parties that send no trust anchor signal at all, such as those configured only when their trust store is built. A server can tell them from stale ones only by a local rule, and only while stale ones still send trust_anchors, if need be empty ().

Clock:

Clocks are often set by unauthenticated protocols that the network attacker controls. Measuring age at installation narrows (c) to that moment; that variant is not proved. The age is then the relying party's clock at installation minus the issue time, plus the time elapsed since installation. That elapsed time is measured on a timer that survives restarts and runs no slower than real time. An unknown elapsed time counts as stale. Where the timer resets at boot, every restart leaves every instance stale until the next update. A time signed by the update service over a nonce that the relying party sends would replace (c) by the service's clock. That holds if the age adds the round trip, measured on such a timer.

Delay for users:

The delay is the sum of four parts: detection, the decision, the time until an update carrying the range is issued, and D + e. The bounded-delay form bounds only the last, and only if the service never dates an update later than it signs it. A per-entry range against an honest CA's misissuance helps only relying parties whose lag is shorter than the certificate's remaining lifetime. Against a compromised CA's new issuance, exposure lasts until a cutoff or distrust is installed. Without the bounded-delay form, that is unbounded, unless a cosigner halt ends it ().

Deployment:

Where relying parties past D keep accepting the instance's certificates rather than reject them, the bounded-delay form does not hold. An attacker who withholds updates then keeps a revoked certificate working.

A single signed issue time could serve as both the version number and the issue time. It would be floored like a version number, and refused when more than e ahead of the relying party's clock.

Resumption and open connections recommends limits on resumption that "take into account the lifetime of the peer's certificate, the likelihood of intervening revocation, and the time since the peer's online CertificateVerify signature". Before a client offers a ticket or sends early data under it, the client already checks that "the new SNI value is valid for the server certificate presented in the original session" (). The check of fits there. The client need not verify the certificate again, since removing a trusted subtree is not revocation (). When a range or distrust is installed, the client discards tickets that rest on certificates the configuration now rejects. It also stops reusing connections that rest on such certificates, including coalesced ones. Ending a ticket chain at the original certificate's notAfter bounds nothing against a compromised CA, which chooses the validity interval. The time since the last full handshake does not depend on the CA. For client authentication, the relying party is the server, which keeps the CA instance and serial number in its ticket state. None of this is covered by the arguments of .

Root-program examples These examples are dated: is version 0.4.0 (October 2026), and Apple's policy was announced as a draft. In , every CA operator also runs a mirror. The program requires the CA cosigner and one Usable mirror "not operated by or affiliated with the MTC CA Operator", "to protect Chrome clients against log tampering or split-views created by an MTC CA" (Section 2.4.5 of ). Section 1.3 of tests independence: operators that "share no common ownership, ultimate corporate control, parent companies, administrative access, or control over cosigner key material". In the terms of , that is a mirror-backed policy with a quorum of one. It makes recording available on both paths, on the trusted-subtree path through the landmark rule of Section 2.4.5 of , given G5. In the sense of , it does not make consistency available, even on the trusted-subtree path, where a quorum would cost validation and availability rather than certificate size. On the cosigner path, it trades consistency for size and availability: the CA and one mirror cost 9.0 kB per standalone handshake, against at least 11.4 kB for any policy that meets the intersection condition at f = 1 (). Split views are answered after detection, with revoked ranges or distrust, whose delay is that of . The program also requires CAs to "attempt to submit all issuance log updates to all Chrome-recognized Mirroring Cosigners", and Chrome monitors that mirror checkpoints and tiles are available (Section 2.5.1.2 of ). Distinguishing a CA that withheld an update from a mirror that lagged needs a record of the CA's submissions. On the trusted-subtree path, an update service would add consistency among its relying parties, for the subtrees it delivers, if, for each log:

• it kept the history of reference checkpoints it validated against;
• it accepted a new reference checkpoint only with a consistency proof from the last; and
• it published only subtrees consistent with that history.

The service would then act as a witness. This consistency holds where the service keeps that history as intact state, which all its replicas share and which it never resets. It does not by itself extend to the cosigner path, to subtrees that a relying party validated itself, or to subtrees from another such service: in each case, two relying parties can accept different entries.Editor's note: Version 0.4.0 of does not yet ask its Landmark Service to keep a history of reference checkpoints and to accept a new one only with a consistency proof from the last. counts cosignatures from mirrors that are Usable, or Frozen for those generated before the freeze point (Section 3.3).Editor's note: Version 0.4.0 of does not yet mention a mirror's initial minimum index, in that rule or in the criteria of Section 2.4.5 (), or forbid initializing a mirror again for a log under the same key. Apple announced on 21 September 2026 that its draft policy "is expected to require" three cosignatures :

• "an ML-DSA (minimum ML-DSA-44) cosignature from the issuing Operator";
• "an ECDSA (minimum ECDSA-P256-SHA256) cosignature from the issuing Operator"; and
• "an ML-DSA (minimum ML-DSA-44) cosignature from a different Operator acting as a mirror".

That names one mirror, at about 9.1 kB per handshake on the cosigner path. Sections and of allow other cosigner roles and algorithms. A second signature adds no post-quantum assurance. Under a policy requiring both, though, certification holds if either key is intact and its algorithm unforgeable, provided the second signature's role makes the certification statement of . That hedges against a break of ML-DSA or its implementations, for certification only: recording and consistency rest on cosigners that sign with ML-DSA-44 alone.Editor's note: (version -08) leaves other cosigner roles to other documents and deployments, and defines a single CA cosigner, with one key per cosigner ID (), so a second CA signature needs a role of its own. and currently allow only ML-DSA-44 for subtree cosignatures (the former says "This MAY be extended to future MTC-compatible, subtree-capable cosigners"), and version 0.4.0 of allows only ML-DSA-44 for the CA cosigner key (Section 2.4.3.1). Several root programs complicate the choice of policy, since their standalone certificates share one trust anchor identifier (Sections and of ), and the recovery of cannot tell them apart either. Programs can share cosigners, or CAs can carry the union of the programs' required cosignatures. For the policy and Apple's announced one, with disjoint mirrors, the union comes to about 11.5 kB per handshake, above the conventional chain. Sharing cosigners does not mean sharing a list. The cosigner list "may contain keys that are not unconditionally trusted by Chrome" and is not for other clients (the Introduction). Each program therefore authenticates the keys and their states itself. moves a mirror that signs an inconsistent view "to the Frozen state". In that state, "Cosignatures generated prior to the freeze point remain valid". In the Removed state, cosignatures are "immediately invalid" (Sections 3.2.6 and 3.3 of ). The program lets a mirror with credible evidence of compromise or a split view "temporarily suspend cosigning new checkpoints for that specific issuance log", provided the mirror notifies Chrome at once and keeps serving the log (Section 3.2.6 of ). How a frozen mirror's bound relates to a fork, and what a halt must cover, are in and . Status signing can run out of conforming keys. A CA cosigner key signs status only for its own instance (). Once that key is retired, a policy that has CRLs signed only with active keys, as Section 2.4.3.3 of reads, leaves no conforming signer for that instance's certificates. After a compromise, the only such signer is the compromised key (). The Key Sunset of is "technically enforced in client configurations through bounded minimum and maximum certificate serial numbers and log instances" (the Definitions). It is a cutoff in the sense of . There, bounding each log instance, rather than one serial interval, is what keeps earlier logs closed.

Offline trust anchors and online keys Root keys in today's Web PKI are offline, but the CA cosigner key is online. treats it as both. For key generation, it is "considered to be CA Key Pairs for a Root Certificate". But "MTC CA Cosigner Keys and Mirroring Cosigner Keys are not considered Root CA Systems" (Section 2.6.1 of ). Three arrangements, which may be combined, keep an offline key in the picture:

• An offline root can certify the Merkle Tree CA as a subordinate, supplying the CA parameters (Sections and of ). This protects the binding of CA identifier, key, and serial bounds. It suits programs other than , whose root store holds the Merkle Tree CAs themselves (the Introduction). Relying parties still configure the Merkle Tree CA's cosigner policy and trusted subtrees (). The root thus checks the CA's parameters rather than replacing that configuration. The minimum serial number that such a root states should advance as entries expire (). That means either repeated root ceremonies or ranges delivered separately.
• An offline authority can authorize configuration updates. The Merkle Tree CA is then itself a trust anchor , and the update channel plays the role of the root. This also protects policy, subtrees, and ranges ().
• The CA operator can hold offline reserve CA cosigner keys. already keeps two of these in its root store (Sections 2.6.2 and 2.6.3), and Section 3.1.3 of calls them parked keys. What we add is configuring each reserve key in advance as a successor CA instance at relying parties and cosigners, so that a mirror starts it at minimum index zero. processes key additions only quarterly, with 30 days' notice (Section 2.6.3). Without such successors, a CA's fastest recovery can be a quarter away. Either way, replacing a CA cosigner key creates a new CA instance that every root program must configure, as for a root today (). Reserve keys make that routine, at a price. A reserve key already trusted at relying parties and accepted by mirrors is an issuance key protected only by its operator's controls, and distrust of a malicious operator must also cover it ().

Reserve keys serve recovery. For availability, already lets a CA "issue Subscriber certificates concurrently from multiple Active CA Cosigner Keys" (Section 2.6.3), so one log failure need not stop issuance. Status signing by the CA cosigner key (), such as signing CRLs, can pass through the signing service of as a second message type. This enforces the separation of .

CA log recovery Restoring a backup of log state, unlike a backup of the key, can fork the CA's own history with an intact key. Suppose the CA can rebuild the log to exactly the last checkpoint its signing service recorded, and verifies the rebuilt log against that record. Then nothing has forked, and the CA can resume, provided that every tile or entry bundle it published beyond that checkpoint is kept: tiles are immutable (), so the rebuilt log includes each published entry unchanged, at the same index. Entries appended beyond that checkpoint and not published were never certified (). They are discarded, and their indices, and so their serial numbers, are reused. Indices that the recorded checkpoint covers are never reused, even where no signature over them was released. So the CA's records treat a serial number as issued only once a checkpoint covering it is signed (Section 2.4 of ). This recovery preserves every view the key signed, even when the discarded indices are reused, and the stronger form of G1 holds through it. That needs the signing service to persist its record before it uses the key, not only before it releases the signature. If the CA cannot rebuild the log in this way, the log has failed. The CA stops issuing on it, and moves to a new log number (Sections and of ), rather than resuming from an earlier checkpoint (). It keeps serving the failed log read-only, from a mirror's copy if need be, for monitors and for relying parties not yet updated.

Witnesses and mirrors in practice requires MTC cosigners to sign with ML-DSA-44. The Ed25519 witnesses deployed today are therefore not MTC cosigners, and they cannot sign the subtrees that a standalone certificate carries (). An existing witness can add an ML-DSA-44 key alongside its Ed25519 one, since returns cosignatures from "the witness key(s)" and says witnesses "SHOULD use ML-DSA-44". then also requires a cosigner name derived from a trust anchor identifier. Counting Ed25519 witnesses for landmark validation would be a separate profile, with different cosigner sets on the two paths. Consistency would then have to hold across both. Suppose a CA moves to a new log number to regain a cosigner that lost state. Under , it pays for that move with a reportable incident and one of a bounded number of logs (Sections 2.5.1.2 and 2.5.1.3). Where a policy leaves the CA no other cosigner to use, a program therefore sizes its log-number budget for the moves that a cosigner's failure, or the CA's own failover (), forces. Since the move is caused by the cosigner, a program can also choose not to count it against the CA. A mirror counts toward standalone certificates only if it signs subtrees, in C2SP through sign-subtree, which makes optional and says such a cosigner "SHOULD implement". A hardware module protects a mirror's key against extraction, and makes one optional (Section 3.1). But whoever can drive the module can sign without storing. What protects recording is that the component that signs is the one that checks durability. designates at most one Usable mirror key per operator (Section 3.1). It also requires every CA operator to run a mirror "usable by all other CA Cosigners" (Section 3 of ). Under that program, a mirror that loses one log's state and follows cannot cosign that log until the CA moves to a new log number. We state single initialization as one rule because it serves both recording and consistency, but recording needs less. For recording alone, it suffices that no initialization of the mirror for a log starts above its first initial minimum index, with backfill before its first new signing. Resuming under the same key is what endangers consistency. A split form of the rule would let a mirror that loses one log re-mirror it from index zero and remain a recorder. That works only if the mirror signs nothing for the log between the loss and the restart, and the restart carries over no stored entries or largest signed size from before the loss. The entry is then stored before the restarted mirror's first signing that covers it, and so before acceptance, though not necessarily before the mirror's first such signing ever. Two relying parties could, however, accept different entries through such a mirror.

Obtaining landmark-relative certificates An authenticating party obtains the landmark-relative certificate from the CA, through the ACME optional alternate of , or builds it from the log and landmark file (). That optional alternate answers "HTTP 202 (Accepted)" with a Retry-After until the certificate exists. Building the certificate from the log and landmark file makes the file's clock dependence a server-side problem too. The file carries an expired landmark as a terminator, and decoders reject a file without one (). A decoder whose clock runs slow by more than the time since the newest expired landmark expired, which lies between zero and one landmark interval for a freshly published file, rejects the whole file. With hourly landmarks, a clock s minutes slow rejects about s/60 of fresh fetches, at update services and servers alike. Every landmark-relative certificate of an interval becomes available when its landmark is allocated. So a CA that points Retry-After at the expected landmark time plus jitter keeps clients from polling at once.

Sizes, transport, and renewal The sizes in come from these figures (Sections and of ):

• A cosignature in an MTCProof, the CA's included, costs 2,427 B: the 2,420 B ML-DSA-44 signature, its 2-byte length, and a cosigner ID of 4 B (as for a trust anchor ID such as 32473.1) with its 1-byte length.
• The rest of an MTCProof costs 19 B: the 2-byte length of the empty extensions, the 6-byte start and 6-byte end, the 2-byte length of the inclusion proof, and the 3-byte length of the signature list.
• A landmark-relative inclusion proof costs 736 B (23 hashes), and a standalone one 384 B (12 hashes).
• The endpoint key with its handshake signature costs 3,732 B.

With hourly landmarks, a relying party holds about 10.8 kB of trusted-subtree hashes per CA instance. sets ceilings of 220 landmarks per 7 days and 370 per 47 days (Section 2.6.2). These ceilings allow about 14.1 and 23.7 kB, respectively. Each MTC row of is a whole MTCProof: 19 B, the inclusion proof, and the cosignatures. The conventional row counts three bare 2,420 B signatures and leaves out the framing and certificate fields around them. It is a yardstick, as in . adds no post-quantum X.509 roots (the Introduction). The expected cost per handshake depends on how often the trusted-subtree path is used (). That frequency is the product of relying-party freshness and server support (). With nine handshakes in ten landmark-relative, the CA and one mirror average about 4.9 kB, and the CA and three cosigners about 5.4 kB. At half, they average about 6.7 and 9.2 kB. The cosigner path matters most for lagging and first-contact relying parties. Over TCP, with about 2 kB for the rest of the server's flight, the CA and two cosigners fit an initial window of ten segments of 1,460 B . The CA and three cosigners do not. Over QUIC, a server may send at most three times what it has received before validating the client's address (). A ClientHello with a post-quantum key share fills about two Initial packets. So the server's whole first flight, including a ServerHello of about 1.2 kB, gets about 7 kB. That leaves room, by a few hundred bytes, for the landmark-relative flight with ML-DSA-44 endpoint keys. It leaves no room for a standalone flight, which then costs a round trip. With ML-DSA-65 endpoint keys, even the landmark-relative flight does not fit. With 7-day certificates renewed at 75% of their lifetime, the old certificate has 42 hours left (). There, the new entry waits up to an hour for a covering landmark. If renewal succeeds on schedule, a relying party whose configuration lags by more than about 41 hours holds neither landmark for part of every renewal cycle. A renewal delayed by a day, which is the outage that Section 2.2 of tolerates, leaves about 17 hours. For 47-day certificates under , with landmarks every 4 hours (Section 2.6.2), the tolerated lag is about 278 hours.

Renewal overlap and the tolerated configuration lag (not to scale) renew: new landmark old cert expires entry logged covers entry | | | old cert +===============+==============+================+ new cert +==================================> 0 h 126 h 127 h 168 h |<---- 1 h --->|<---- 41 h ---->| (wait) tolerated lag

ACME Renewal Information lets the CA suggest a renewal window, and a client may renew anywhere in it. So a CA that wants to tolerate a lag T ends the window at least T plus the landmark interval before the old certificate's notAfter. The tolerated lag of assumes the server keeps the old certificate ("SHOULD retain both the new and old certificates", ). A client that replaces a certificate in place does not do that. With replacement in place, every relying party takes the cosigner path from renewal until the new landmark reaches it. Take a lag L, and a server that fetches the landmark-relative certificate F hours after the landmark. Then about (1 h + max(F, L))/126 h of handshakes take the cosigner path. That is 6% at L = 6 hours when F is small, and 20% at 24 hours. A server that holds one generation at a time can instead stage the renewed pair and swap W hours after renewal. permits this ("MAY opt to wait for optional alternates"). The server's share is then max(0, 1 h + L - W)/126 h. That is none at W = 24 hours and L = 6 hours, with 18 hours left on the old certificate if the swap fails. When a cosigner policy change discards trusted subtrees (), the relying party stops advertising the discarded landmarks at the same time, and a handshake already in flight can fail. The retry, whether by the application or by the recovery of , is a new connection. At a large program, a change that discards many subtrees shifts the affected handshakes to standalone certificates at once. Vendors therefore stage such changes per CA. Renewal at the scale of an incident, when a CA pulls renewal windows forward for its whole population, multiplies issuance. Reissuing the population of 's estimate in a day adds about five times the steady rate (126 h / 24 h) on top of ongoing issuance. A revoked range is the blunt instrument that causes this. An incident bounded in time is one interval of one log. A range over it also revokes the correct certificates in the window, which then need reissuing. For an honest CA with short-lived certificates, natural expiry can be the better answer. Mirrors on the issuance path see the same multiple. Under , these include competitors' mirrors (Sections 2.5.1.2 and 3). Every reissued certificate also takes the cosigner path for the landmark interval plus each relying party's lag. So CAs, mirrors, and servers plan capacity for that peak as well as the average.

Retention states the condition for retention (). , for example, publishes a serial-number bound, safe_to_prune_before, advanced past entries "revoked or expired for at least 35 days" (Section 2.5.1.3). Mirrors "SHOULD NOT prune entries until the corresponding entries have been pruned from the corresponding issuance log, except that Mirroring Cosigners MAY independently prune any entry below safe_to_prune_before once 90 days have elapsed since the end of the certificate's validity period" (Section 3.2.4 of ). asks relying parties to restrict pruning, "such as requiring that the log's minimum index be at most the minimum trusted index in up-to-date copies of the relying party's trust anchors". likewise keys on up-to-date relying parties. The input we use is stronger: the lag of the oldest relying parties that a program supports. That way, entries stay visible to relying parties that have not installed the advance of the minimum serial number. A program that publishes a pruning bound therefore states, implicitly, the lag it supports, and a vendor's choice of D sets how long CAs and mirrors retain entries. Under the bounded-delay form, that lag is at most D + e. So suppose entries are retained for D + e after the update that revokes them is issued, and the service never dates an update later than it signs it. Then no relying party that enforces the program's bounded-delay form accepts an entry that the CA and mirrors have pruned. A deployment will want to measure lag in aggregate (), along with which certificates handshakes use.

Responding to CA compromise This appendix details the two responses to CA compromise that summarizes.

Halting new issuance The CA operator's first step is to stop issuance on the affected log or instance. Section 2.5.2 of makes this automatic for an unverifiable log. Against an attacker holding the key, though, that step bounds nothing. Distrust and revoked ranges stop such an attacker only once they are installed at each relying party. Cosigners can act sooner, for relying parties not yet updated. Suppose that:

• each cosigner in a set F halts a log, that is, stops signing its checkpoints, and each such halt is atomic with that cosigner's checkpoint signing and survives restarts and routine reconfiguration;
• at each of a relying party's acceptances, every cosigner set that the policy then in effect accepts contains a member of F that is faithful to the log; and
• on the trusted-subtree path, the premises of G5 hold ().

Then, once every such member has halted the log and while each remains halted, every entry that the relying party accepts from that log lies below the size of a checkpoint that some member of F signed before stopping (). This holds on either path and under local or delegated validation, including for subtrees validated after the halt. Nothing shows that the bounded entries were authorized or predate the compromise. Resuming ends the bound. Under the policy of the CA and any one of several mirrors, this needs every such mirror to halt. A suspension that covers one log, or that ends on its own, is not such a halt. A cosigner that serves several root programs halts as its own operational decision, since halting withdraws cosignatures that other programs' relying parties may need. The Recommendation of states what such a halt involves; its last two items extend the bound to the CA instance and keep the halt observable.Editor's note: The nearest mechanisms in version 0.4.0 of are a mirror's suspension of one log (Section 3.2.6) and mirrors' daily reading of the cosigner list, after which they "MAY stop mirroring" a removed key's logs (Section 3.2.2). Neither yet amounts to such a halt: a suspension does not cover the CA key's later log numbers, in-flight uploads, or pending checkpoints, and one suspending mirror does not stop acceptance.

Preserving history A response to CA compromise either withdraws all trust in the CA instance or preserves selected history. Selected history is usually preserved with a revoked range that covers every index above a cutoff. A cutoff alone does not preserve exactly the intended history:

• Under a CA-only policy, the attacker can sign a different subtree over indices below the cutoff ().
• The CA can append to an earlier log, whose indices stay below the cutoff. So each retained log needs its own bound, and later log numbers must be rejected. A cutoff enforced as one serial interval leaves every earlier log open. This is because a serial number is the log number shifted left 48 bits, combined with the index (). Against a malicious operator, rather than one stolen key, distrust must also cover the successor instances of its reserve keys already configured at relying parties ().
• A cosigner initialized after the compromise can follow whichever history the attacker presents first, unless its configuration carries an initial trusted checkpoint for the log, taken from checkpoints that the root program collected.

Preservation therefore needs a prior authenticated commitment to the chosen history, such as checkpoints cosigned by cosigners whose views connect to it. It also needs a decision authenticated independently of the compromised key. A checkpoint newly signed by that key cannot select the history. Without such a commitment, the response withdraws trust in the CA instance entirely. Either way, the decision is consulted on every acceptance. Status signed by the compromised key does not override it. allows that key to sign such status, and Section 2.4.3.3 of has CRLs signed with it.

Acknowledgements This document draws on the specifications and policy it describes (, , , , , , , , , ) and on the work of their authors and maintainers: Bob Beck, David Benjamin, Chris Clements, Russ Cox, Al Cutter, Rasmus Dahlberg, Joe DeBlasio, Ryan Dickson, Aaron Gable, Martin Hutchinson, Matthew McPherrin, Kyle Nekritz, Devon O'Brien, Luke Valenta, Filippo Valsorda, and Bas Westerbaan. began as a document of the Sigsum project. Luke Valenta raised the key-custody question in ; David Benjamin raised the privacy choices around update recency in ; and Ilari Liusvaara raised the log-fork problem in .