PKI, Logs, And Tree Signatures sanketh Internet-Draft AWS Intended status: Informational 2 November 2026 Expires: 6 May 2027 Merkle Tree Certificates Architecture draft-sanketh-plants-mtc-architecture-00 Abstract 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 https://datatracker.ietf.org/doc/draft-sanketh-plants-mtc- architecture/. Discussion of this document takes place on the PKI, Logs, And Tree Signatures Working Group mailing list (mailto:plants@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/plants. Subscribe at https://www.ietf.org/mailman/listinfo/plants/. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. sanketh Expires 6 May 2027 [Page 1] Internet-Draft MTC Architecture November 2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Transparency and revocation today . . . . . . . . . . . . 4 1.2. Merkle Tree Certificates . . . . . . . . . . . . . . . . 5 1.3. This document . . . . . . . . . . . . . . . . . . . . . . 7 2. Setting and services . . . . . . . . . . . . . . . . . . . . 10 2.1. Accepting a certificate . . . . . . . . . . . . . . . . . 12 2.2. Certification authority . . . . . . . . . . . . . . . . . 13 2.3. Witnesses . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. Mirrors . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5. Monitors . . . . . . . . . . . . . . . . . . . . . . . . 16 2.6. Relying-party configuration . . . . . . . . . . . . . . . 17 2.7. Authenticating party . . . . . . . . . . . . . . . . . . 17 3. Security guarantees . . . . . . . . . . . . . . . . . . . . . 18 3.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 19 3.2. G1: Certification . . . . . . . . . . . . . . . . . . . . 21 3.3. G2: Recording . . . . . . . . . . . . . . . . . . . . . . 22 3.4. G3: Consistency . . . . . . . . . . . . . . . . . . . . . 23 3.5. G4: Revoked ranges . . . . . . . . . . . . . . . . . . . 24 3.5.1. Bounded-delay form . . . . . . . . . . . . . . . . . 25 3.6. G5: Validated configuration . . . . . . . . . . . . . . . 26 sanketh Expires 6 May 2027 [Page 2] Internet-Draft MTC Architecture November 2026 3.7. What is not provided . . . . . . . . . . . . . . . . . . 27 3.8. Summary of premises . . . . . . . . . . . . . . . . . . . 27 4. Deployment choices . . . . . . . . . . . . . . . . . . . . . 28 4.1. Cosigner policy . . . . . . . . . . . . . . . . . . . . . 28 4.2. Local or delegated validation . . . . . . . . . . . . . . 30 4.3. Certificates served . . . . . . . . . . . . . . . . . . . 31 4.4. Who decides . . . . . . . . . . . . . . . . . . . . . . . 32 5. Configuration lifecycle . . . . . . . . . . . . . . . . . . . 34 5.1. Changing the cosigner policy . . . . . . . . . . . . . . 34 5.2. Cosigner lifecycle . . . . . . . . . . . . . . . . . . . 35 5.3. Revoked ranges, removal, and distrust . . . . . . . . . . 35 5.4. Log numbers . . . . . . . . . . . . . . . . . . . . . . . 36 5.5. Updates and recovery . . . . . . . . . . . . . . . . . . 36 6. Deployment considerations . . . . . . . . . . . . . . . . . . 37 6.1. Sizes . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.2. Renewal and configuration lag . . . . . . . . . . . . . . 38 7. Security considerations . . . . . . . . . . . . . . . . . . . 38 7.1. Compromise of the CA . . . . . . . . . . . . . . . . . . 38 7.2. Compromise of relying-party configuration . . . . . . . . 39 7.3. Compromise of a witness, mirror, or monitor . . . . . . . 40 7.4. Availability . . . . . . . . . . . . . . . . . . . . . . 40 7.5. Residual risks . . . . . . . . . . . . . . . . . . . . . 40 7.6. Outside the threat model . . . . . . . . . . . . . . . . 41 7.7. Cryptographic and representation interfaces . . . . . . . 41 7.8. Analysis . . . . . . . . . . . . . . . . . . . . . . . . 42 8. Privacy considerations . . . . . . . . . . . . . . . . . . . 43 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 44 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 10.1. Normative References . . . . . . . . . . . . . . . . . . 44 10.2. Informative References . . . . . . . . . . . . . . . . . 45 Appendix A. Basis for the guarantees . . . . . . . . . . . . . . 50 Appendix B. Deployment notes . . . . . . . . . . . . . . . . . . 53 B.1. The bounded-delay form in practice . . . . . . . . . . . 53 B.2. Resumption and open connections . . . . . . . . . . . . . 55 B.3. Root-program examples . . . . . . . . . . . . . . . . . . 55 B.4. Offline trust anchors and online keys . . . . . . . . . . 58 B.5. CA log recovery . . . . . . . . . . . . . . . . . . . . . 59 B.6. Witnesses and mirrors in practice . . . . . . . . . . . . 60 B.7. Obtaining landmark-relative certificates . . . . . . . . 61 B.8. Sizes, transport, and renewal . . . . . . . . . . . . . . 61 B.9. Retention . . . . . . . . . . . . . . . . . . . . . . . . 64 Appendix C. Responding to CA compromise . . . . . . . . . . . . 64 C.1. Halting new issuance . . . . . . . . . . . . . . . . . . 64 C.2. Preserving history . . . . . . . . . . . . . . . . . . . 65 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 66 sanketh Expires 6 May 2027 [Page 3] Internet-Draft MTC Architecture November 2026 1. Introduction 1.1. Transparency and revocation today Today, a website's server asks a certification authority (CA) for a certificate, often using ACME [RFC8555]. 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) [RFC6962] [RFC9162]. 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 [CHROME-CT] [APPLE-CT]. 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. Figure 1 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_. 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 | Figure 1: Issuing and accepting a certificate with Certificate Transparency today 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 [CABF-SC081], and Let's Encrypt is now issuing certificates valid for only 160 hours [LE-SHORTLIVED]. sanketh Expires 6 May 2027 [Page 4] Internet-Draft MTC Architecture November 2026 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 [LE-CT-LOGS]. Let's Encrypt alone had about 682 million active certificates in September 2026 (Section 6.5 of [MTC]). 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 [LE-CT-TALK]. The logs' annual cloud costs were approaching seven figures when Let's Encrypt replaced them with cheaper static logs [LE-CT-EOL]. 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 [CT-LANDSCAPE], Sectigo's Mammoth2024h1 in 2024 [MAMMOTH-2024], and two DigiCert logs in 2025 [DIGICERT-2025]; [CT-LOG-FAILURES] surveys such failures. Static logs remove the merge delay by sequencing entries before returning an SCT [STATIC-CT], and Chrome now admits new logs only with an MMD of at most four hours, or one minute for static logs [CHROME-CT-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 [EMUDHRA-BUG] [EMUDHRA-SITE]. 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 [EMUDHRA-CHROME] [EMUDHRA-BUG], but clients that consume neither stay exposed until a software update or an administrator intervenes [EMUDHRA-APPLE]. 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 (Section 7.1), cosigners could also bound a compromised CA's new issuance at relying parties not yet updated. 1.2. Merkle Tree Certificates Merkle Tree Certificates (MTCs) [MTC] 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. sanketh Expires 6 May 2027 [Page 5] Internet-Draft MTC Architecture November 2026 Figure 2 shows the flow for comparison with Figure 1. 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. 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 | Figure 2: Issuing and accepting Merkle Tree Certificates 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 1 and 12.3 of [MTC]). 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 (Section 5.4 of [MTC]). Handshakes shrink. sanketh Expires 6 May 2027 [Page 6] Internet-Draft MTC Architecture November 2026 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 (Section 6.1). 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 (Section 7.5 of [MTC]). 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 Section 12.2.1 of [MTC] 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 (Section 1 of [MTC]). 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 [CHROME-PQ] [CQRP]. 1.3. This document This document describes the architecture for deploying MTCs, following the approach of the MLS architecture [RFC9750]. 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 (Section 3). 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 (Section 3.1). Under a sanketh Expires 6 May 2027 [Page 7] Internet-Draft MTC Architecture November 2026 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 (Section 2). After them, we cover the deployment choices and who owns them (Section 4), how configuration changes over time (Section 5), and deployment, security, and privacy considerations (Section 6, Section 7, and Section 8). Appendix A sketches why each guarantee holds, and Section 7.8 states the limits of those arguments. Table 1 summarizes the guarantees of Section 3, 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 (Section 3.1). The trusted- subtree path also rests on G5. sanketh Expires 6 May 2027 [Page 8] Internet-Draft MTC Architecture November 2026 +===============+==============+=====================+===========+ | Guarantee | What the | Rests on | Against a | | | relying | | rogue CA | | | party learns | | | +===============+==============+=====================+===========+ | G1 | the CA key | the CA cosigner | holds | | Certification | certified | key, if the policy | unless | | | exactly this | requires it | the key | | | entry | | is | | | | | extracted | +---------------+--------------+---------------------+-----------+ | G2 Recording | a mirror | a supporting mirror | holds | | | stored the | faithful to the log | | | | entry before | | | | | acceptance | | | +---------------+--------------+---------------------+-----------+ | G3 | relying | a faithful | holds | | Consistency | parties | supporting cosigner | | | | agree on the | shared by every | | | | entry at | pair of acceptances | | | | each index | (the intersection | | | | | condition) | | +---------------+--------------+---------------------+-----------+ | G4 Revoked | an installed | the update key, | holds for | | ranges | range | numbered complete | the | | | rejects on | updates with a | positions | | | both paths, | version floor, and | named | | | and stays | the installation | | | | installed | check | | +---------------+--------------+---------------------+-----------+ | G5 Validated | each trusted | local validation, | holds | | configuration | subtree was | or an honest update | | | | validated | service; the | | | | under the | installation check | | | | policy in | and retention rule | | | | effect | | | +---------------+--------------+---------------------+-----------+ Table 1: The guarantees at a glance Terms not taken from [MTC] are defined where they are introduced: the services and paths in Section 2, the failure and premise terms in Section 3.1, the intersection condition in Section 3.4, the version floor in Section 3.5, the bounded-delay form in Section 3.5.1, the installation check in Section 4.2, the retention rule in Section 5.1, and the halt in Appendix C.1. sanketh Expires 6 May 2027 [Page 9] Internet-Draft MTC Architecture November 2026 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 (Section 4.4), 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 (Section 12.9 of [MTC]). This document is meant to be read alongside [MTC], revision -08. We use its terms (see Section 2.1 of [MTC]), its formats, and its verification procedure. In the language of Section 7.3 of [MTC], certification refines authenticity, recording is the part of transparency that holds at acceptance, and consistency goes beyond transparency; eventual visibility is not provided (Section 3.7). 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 [TLOG-MIRROR] and tiled logs [TLOG-TILES], consistency on cosignatures [COSIG] and witnesses [TLOG-WITNESS], and both on the MTC profile [MTC-TLOG]. A mirror implements parts of the witness protocol and serves tiles, so a mirror-only policy rests on [TLOG-WITNESS] and [TLOG-TILES] too. The checkpoint [CHECKPOINT] and signed-note [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 Section 5.2.2 of [MTC] anticipates for its own references. Trust anchor identifiers [TAI] supply certificate selection in TLS 1.3 [RFC9846], and ACME [RFC8555] supplies enrollment. [USE-CASES] and [ENTERPRISE] explore further applications and mechanisms. 2. 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 (Section 5 of [MTC]). 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 (Section 2.2). A certificate's serial number encodes the log number and the entry's index (Section 6.2 of [MTC]). A _cosigner_ signs checkpoints, or subtrees of the log, under its own key (Section 5.3 of [MTC]). The CA signs as the _CA cosigner_. A _witness_ cosigns a checkpoint after checking that it is consistent with the last one it cosigned [TLOG-WITNESS]. A _mirror_ also stores sanketh Expires 6 May 2027 [Page 10] Internet-Draft MTC Architecture November 2026 the entries a checkpoint covers before it cosigns [TLOG-MIRROR]. 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 (Section 5.3 of [MTC]). Its _configuration in effect_ is the CA parameters, cosigner policy, trusted subtrees, and revoked ranges it is using at a given moment (Section 7.1 of [MTC]). 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 (Section 7.2). The _installer_ is the local component that makes delivered configuration effective. Figure 3 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 (Section 2.2 of [RFC9750]). One operator may run several, and drawing them as separate boxes does not make them independent. Section 3.8 lists which keys and state must stay intact. +-----------+ 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 | +-----------+ sanketh Expires 6 May 2027 [Page 11] Internet-Draft MTC Architecture November 2026 Figure 3: Services and the evidence between them 2.1. 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 (Section 7.4 of [MTC]). No cosignature is checked at acceptance; a landmark-relative certificate is built for this path. Section 7.3 of [MTC] 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 (Section 4.1). 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 4.5, 6.4.1, and 7.4 of [MTC]). 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 (Section 7.4 of [MTC]). A mirror counts only for subtrees that start at or above its threshold (Section 2.4). Validation is local when the relying party does it and delegated when the update service does (Section 4.2). 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. Section 7.2 of [MTC] 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. sanketh Expires 6 May 2027 [Page 12] Internet-Draft MTC Architecture November 2026 The decision replaces only the signature check; the rest of path validation, such as expiry, still applies (Section 7.2 of [MTC]). 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. Section 3 of [MTC] follows one certificate from issuance to certificate selection. 2.2. Certification authority The CA is trusted to validate identifiers (Section 3.1). 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 (Section 5.4 of [MTC]), and Section 2.4 of [CQRP] 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 [CQRP] asks of linting. The CA cosigner key signs at checkpoint cadence, every two seconds in the example of Section 6.5 of [MTC], so it is an online key. A hardware module protects it against exfiltration (Section 2.6.1 of [CQRP] 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. sanketh Expires 6 May 2027 [Page 13] Internet-Draft MTC Architecture November 2026 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 5.2 and 12.2.1 of [MTC]), rather than resuming from an earlier checkpoint (Section 5.4, Appendix B.5). 2.3. Witnesses A witness holds no entries. It is relied on for consistency, as a member shared by two acceptable sets (Section 3.4), and for the halt bound, which limits a compromised CA's new issuance once cosigners halt (Appendix C.1). [COSIG] and Section 5.3.2 of [MTC] 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: [TLOG-WITNESS] 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 (Section 2.2), 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 (Section 5.4), but only when it cannot otherwise meet its policy. The move has a cost in incidents and log numbers (Appendix B.6). A new key would be a new cosigner (Section 5.3.3 of [MTC]), and so a policy change (Section 5.1). sanketh Expires 6 May 2027 [Page 14] Internet-Draft MTC Architecture November 2026 2.4. 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 ([TLOG-MIRROR]). A mirror initialized at a minimum index above zero may sign a checkpoint that covers earlier entries it never stored. [TLOG-MIRROR] 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 (Figure 4), and later pruning cannot undo recording (Appendix A). The bound follows from [TLOG-TILES], 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 [TLOG-MIRROR], except before a mirror's first signing. A new mirror key is a new cosigner. Under [CQRP], 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 (Appendix B.6). // Editor's note: [TLOG-MIRROR] 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. 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 sanketh Expires 6 May 2027 [Page 15] Internet-Draft MTC Architecture November 2026 Figure 4: A mirror's initial minimum index m0 and eligibility threshold 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 (Section 4.1). 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 (Section 2.3). 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 (Section 10.2 of [MTC]). An operator running both a witness and a mirror keeps them distinct cosigners (Section 5.3 of [MTC], [TLOG-MIRROR]). 2.5. 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 (Section 5.4), fetched from the cosigners themselves rather than only through the CA (see the Monitor Retrieval Mechanism of [TLOG-WITNESS]); * parses every entry in its scope (Section 12.5 of [MTC]); * checks entries against its own record of authorized keys (Section 12.3 of [MTC]); 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 (Section 12.2 of [MTC]). Detection assumes that monitors reach the cosigners and are not served stale views sanketh Expires 6 May 2027 [Page 16] Internet-Draft MTC Architecture November 2026 ([TLOG-WITNESS]). So a policy that counts a witness can require the witness's monitoring endpoint. [TLOG-WITNESS] only recommends that endpoint, and says its delay "SHOULD NOT" exceed an hour. [CQRP] 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. 2.6. 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 (Section 7.2). A vendor that holds all of them, as Section 7.4 of [MTC] anticipates, can still separate them internally, with distinct keys, approvals, and roles. 2.7. Authenticating party The authenticating party: * deploys a standalone certificate alongside any landmark-relative one, for relying parties whose configuration lags (Section 6.4 of [MTC]); * sends the landmark-relative one only when the trust anchor signal shows that the relying party holds its subtree (Section 8.2 of [MTC]); and * renews early enough for a covering landmark to arrive (Section 6.2). 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 (Section 4.3). It obtains the landmark-relative one from the CA, or builds it from the log (Appendix B.7). // Editor's note: Deploying the TLS integration as intended may need // a change to [TAI] or [MTC]. Since [MTC] defines no // SignatureScheme for the proof, under a strict reading of // Section 4.5.1.2 of [RFC9846] and Section 5.4 of [TAI], a server // that holds a conventional chain signed with algorithms the client // advertises sends that chain instead of the MTC. The recovery of // Section 5.6 of [TAI] inherits this, and options are under sanketh Expires 6 May 2027 [Page 17] Internet-Draft MTC Architecture November 2026 // discussion in [TAI-138]. Section 5.5 of [TAI] (version -07) also // does not yet say what a complete certification path is when the // trust anchor is a landmark. 3. Security guarantees This section states what holds at acceptance, as five guarantees, and what each rests on. Figure 5 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. +------------------------------+ | 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 +------------------------------+ Figure 5: The guarantees along the path from issuance to acceptance sanketh Expires 6 May 2027 [Page 18] Internet-Draft MTC Architecture November 2026 3.1. Threat model We start from the Internet threat model [RFC3552], 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 (Section 3.7). It can withhold or replay updates (Section 3.5), set clocks that synchronize without authentication, cut monitors off from cosigners (Section 2.5), and read trust anchor signals (Section 8). 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 [RFC9846]), and that the application checks that the certificate is for the name it wants ([RFC9525]). 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 (Section 7.8). 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 (Section 2.2), 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 sanketh Expires 6 May 2027 [Page 19] Internet-Draft MTC Architecture November 2026 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 Section 3.4. 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 Section 2.3 and Section 2.4 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 ([TLOG-WITNESS]). 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 (Section 3.5.1), 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 (Section 7.6); * 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 (Section 7.2); sanketh Expires 6 May 2027 [Page 20] Internet-Draft MTC Architecture November 2026 * that a resumed session inherits the original authentication through its resumption PSK (Appendix F.1 of [RFC9846]; limited in Section 7.5); * that validation and installation are atomic, that each verification reads one configuration, and that installation applies everything an update carries in one step (Appendix A); and * the cryptographic assumptions of Section 7.7. On the trusted-subtree path, certification, recording, consistency, and the halt bound (Appendix C.1) also rest on validated configuration (Section 3.6). 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 Section 8.2 of [RFC9750] states intended guarantees, each guarantee here is an implication: it holds in a deployment that makes its premises true. Section 3.8 collects the parties each guarantee depends on, and Appendix A sketches why each holds. 3.2. 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 (Section 5.4 of [MTC]). This holds against a malicious CA, which has certified every entry of every subtree it signed (Sections 5.3.2 and 5.4 of [MTC]). 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 (Section 12.4 of [MTC]). 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 Section 2.2 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. sanketh Expires 6 May 2027 [Page 21] Internet-Draft MTC Architecture November 2026 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 ([COSIG]). 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 (Section 12.2 of [MTC]). 3.3. 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 Section 2.4, and that the accepted index is at or above that mirror's initial minimum index, as the Recommendation of Section 2.4 arranges. Then that mirror durably committed the exact accepted entry ([TLOG-MIRROR]) before its earliest checkpoint signing covering that index, and so before acceptance (Appendix A). 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. Appendix B.3 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 (Appendix B.3). 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 ([TLOG-MIRROR]), so a later failure to serve them is attributable to the mirror. sanketh Expires 6 May 2027 [Page 22] Internet-Draft MTC Architecture November 2026 3.4. 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 Section 2.3 and Section 2.4 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 (Section 4.1), 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 (Appendix C.2). Without the intersection condition, a rogue CA whose faulty cosigners fill the overlap can show different histories to different relying parties (Appendix A), 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 (Section 2.5). This detection condition is stated here, not proved (Section 7.8). 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 (Section 5.3.1 of [MTC]), so that the fork never reaches a monitor. In Sections 10.2 and 12.2 of [MTC], 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. sanketh Expires 6 May 2027 [Page 23] Internet-Draft MTC Architecture November 2026 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 (Section 3.5). 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. 3.5. 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 Section 2.1, step 4 of Section 7.2 of [MTC]). 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 Section 7.5 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 Section 4.2. 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. sanketh Expires 6 May 2027 [Page 24] Internet-Draft MTC Architecture November 2026 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 (Appendix C.2). Distrust can be delivered as a range over every serial number of the instance (Section 7.5 of [MTC]), and then the premises above, and the bounded-delay form of Section 3.5.1, 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. 3.5.1. Bounded-delay form Nothing in [MTC] 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 Section 3.5 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 sanketh Expires 6 May 2027 [Page 25] Internet-Draft MTC Architecture November 2026 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. Appendix A sketches the argument for ranges. The same argument covers the instance's whole configuration where every update carries all of it (Section 5.2). 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 Section 8.2.1 of [MTC], 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. Appendix B.1 gives the other costs, and how the delay that users see adds up. A deployment states its D, or states that it has none. 3.6. 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 Section 5.1), and that the relying party applies the installation check of Section 4.2 and the retention rule of Section 5.1. 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 Section 7.4 of [MTC] 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 (Section 5.1). Removing a trusted subtree is not revocation (Section 5.3). sanketh Expires 6 May 2027 [Page 26] Internet-Draft MTC Architecture November 2026 3.7. 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 (Section 12.3 of [MTC]). _Eventual visibility._ Section 12.2 of [MTC] aims for every accepted certificate to be visible to monitors. The guarantees here cover the recording part of that aim; Section 10.3 of [MTC] 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 (Section 10.3 of [MTC]), 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 (Section 3.5.1) 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 (Section 7.1). _Uniform assurance._ For a given name, the assurance is that of the weakest certificate the relying party will accept, including any directly signed fallback (Section 4.3). _Subscriber key compromise._ A subscriber whose key is compromised requests revocation of its certificate, and CRLs and OCSP apply unchanged (Sections 10.4 and 12.7 of [MTC]). 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 (Section 5.3). 3.8. Summary of premises Each guarantee below also assumes the common premises of Section 3.1 and Section 7.7, including, on the trusted-subtree path, those of G5. sanketh Expires 6 May 2027 [Page 27] Internet-Draft MTC Architecture November 2026 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 Section 2.4. 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 Section 2.3 or Section 2.4 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 Section 3.4. 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. 4. 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. 4.1. Cosigner policy The cosigner policy decides which of certification, recording, and consistency are available at all (Table 2). Each still needs the premises of Section 3. Requiring the CA cosigner in every acceptable set is what makes certification available. Sections 7.3, 10.2, and 10.3 of [MTC] 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 Appendix B.3. sanketh Expires 6 May 2027 [Page 28] Internet-Draft MTC Architecture November 2026 +================+====================+=============================+ | Policy | Required | Guarantees made | | | signatures | available | +================+====================+=============================+ | CA-only | CA cosigner | Certification | +----------------+--------------------+-----------------------------+ | Witness-backed | CA cosigner and a | Certification; | | | quorum of | consistency where every | | | witnesses | pair of quorums shares | | | | a faithful witness | +----------------+--------------------+-----------------------------+ | Mirror-backed | CA cosigner and a | Certification and | | | quorum of mirrors, | recording; consistency | | | optionally | where every pair of | | | witnesses | quorums shares a | | | | faithful cosigner | +----------------+--------------------+-----------------------------+ Table 2: Cosigner policies and the guarantees they make available 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 (Section 3.4). 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 (Section 6.1). * 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 sanketh Expires 6 May 2027 [Page 29] Internet-Draft MTC Architecture November 2026 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 (Appendix B.6). 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 (Section 7.5 of [MTC]), the kind of "per-log lower bound" that [TLOG-TILES] asks pruning log applications to define. Then b is zero for every relying party that lags less than the program's retention margin (Appendix B.9), and verifiers keep no state per mirror. Otherwise, the threshold b of Section 2.4 travels with root-program metadata and policy formats, and every verifier applies it. 4.2. 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 (Section 6.4.3 of [MTC], Appendix B.7). It also reveals which CAs and intervals interest it (Section 8). 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 (Section 7.2). The update's signature sets the subtrees' resistance to quantum attack (Section 7.7). 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. sanketh Expires 6 May 2027 [Page 30] Internet-Draft MTC Architecture November 2026 _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: Section 7.4 of [MTC] (version -08) leaves the // update channel out of scope, so this Recommendation has no // counterpart there. 4.3. Certificates served An authenticating party whose TLS stack selects by trust anchor [TAI] 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 (Section 7.7). 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 [TURDUCKEN], which relying parties find by path building, with no certificate selection. [TURDUCKEN] 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 (Appendix B.1). 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 ([PQ-MIGRATION]). TLS downgrade protection does not close it (Section 7.5). sanketh Expires 6 May 2027 [Page 31] Internet-Draft MTC Architecture November 2026 4.4. Who decides Table 3 assigns each decision an owner. The examples of cadence and renewal are [MTC]'s (Sections 6.5 and 10.4), except the landmark limit. The examples of policy, cadence limits, retention, and log numbers are from [CQRP] 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. sanketh Expires 6 May 2027 [Page 32] Internet-Draft MTC Architecture November 2026 +================+============================+====================+ | Decision | Owner | Example | +================+============================+====================+ | Checkpoint and | CA, within root-program | 2 s; hourly, at | | landmark | limits | most 220 landmarks | | cadence | | per 7 days | +----------------+----------------------------+--------------------+ | Cosigner | Root program | CA and one mirror; | | policy and | | CA and k of n | | lifecycle | | | +----------------+----------------------------+--------------------+ | Mirror | Root program, mirror | Start at zero, or | | eligibility | | threshold b | +----------------+----------------------------+--------------------+ | Who validates; | Relying-party vendor | Daily component | | update channel | | update | +----------------+----------------------------+--------------------+ | Standalone | Server configuration; CA | Not a fallback | | certificate as | default | under the bounded- | | fallback | (trust_anchor_negotiation) | delay form | +----------------+----------------------------+--------------------+ | Freshness, | Relying-party vendor or | Age D, then fail | | version floor | organization | or fall back | +----------------+----------------------------+--------------------+ | Retention past | Root program, CA, mirrors | 35 days; mirrors | | expiry | | may prune after 90 | +----------------+----------------------------+--------------------+ | Log-number | Root program, cosigners | 5 logs per CA key | | bound | | | +----------------+----------------------------+--------------------+ | Monitor scope | Subjects, monitors | Every trusted | | | | cosigner | +----------------+----------------------------+--------------------+ | Renewal window | CA suggests (ARI); client | Renew at 75% | | | decides | | +----------------+----------------------------+--------------------+ | Alternatives | Authenticating party | Keep the old | | held; when to | | certificate until | | swap | | expiry | +----------------+----------------------------+--------------------+ Table 3: Operational decisions Section 10.3 of [MTC] states the condition for retention. The number, and with it the configuration lag that a program supports, is the root program's (Appendix B.9). sanketh Expires 6 May 2027 [Page 33] Internet-Draft MTC Architecture November 2026 5. 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. 5.1. 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 (Section 6.1). A landmark group covers every landmark up to its number (Section 8.2.1 of [MTC]), 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 (Appendix B.8). _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: Section 7.1 of [MTC] 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. sanketh Expires 6 May 2027 [Page 34] Internet-Draft MTC Architecture November 2026 5.2. Cosigner lifecycle Certificate Transparency policies such as [APPLE-CT-LOGS] 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 (Section 6.2 of [MTC]). 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 (Section 3.4). 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 Appendix A 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. 5.3. 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 (Section 3.5). _Distrusting the CA instance_ removes it. _Certificate status_ through CRLs [RFC5280] and OCSP [RFC6960] continues to apply (Section 12.7 of [MTC]). The exception is where no key may sign status for an instance (Appendix B.3). Section 7.5 of [MTC] 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. sanketh Expires 6 May 2027 [Page 35] Internet-Draft MTC Architecture November 2026 5.4. Log numbers A new log is a new history, with its own origin (Section 5.3.1 of [MTC], [MTC-TLOG]). Witnesses and other non-CA cosigners are expected to accept the next few log numbers in advance ([MTC-TLOG]). 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 (Appendix C.2) or a cosigner halt (Appendix C.1). For example, [CQRP] 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). 5.5. 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 (Section 3.5, Section 4.2); * 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 (Section 5.1); * signed increasing issue times for the bounded-delay form (Section 3.5.1); and * an encoding kept apart from everything else the update key signs (Section 7.7). These answer what [TUF] calls rollback, mix-and-match, and indefinite-freeze attacks. [TUF] 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: Section 7.4 of [MTC] (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 [TUF] for MTC sanketh Expires 6 May 2027 [Page 36] Internet-Draft MTC Architecture November 2026 // configuration. Whether the requirements above are stated in // [MTC], 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 Section 3.5 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. 6. Deployment considerations 6.1. Sizes Table 4 gives the authentication data per handshake for SHA-256 and ML-DSA-44 [FIPS204], from the estimates of Sections 1, 6.4.2, and 6.5 of [MTC] for a large CA with 7-day certificates. Appendix B.8 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 (Section 4.1). In practice, what separates policies is the share of handshakes that are landmark-relative, and the limits of TCP and QUIC (Appendix B.8). +================================+============+===========+ | Certificate | Proof and | Per | | | signatures | handshake | +================================+============+===========+ | Conventional: CA signature and | 7,260 B | 10,992 B | | two SCTs, intermediate omitted | | | | (Section 9.5 of [TAI]) | | | +--------------------------------+------------+-----------+ | Landmark-relative | 755 B | 4,487 B | +--------------------------------+------------+-----------+ | Standalone, CA and one mirror | 5,257 B | 8,989 B | +--------------------------------+------------+-----------+ | Standalone, CA and two | 7,684 B | 11,416 B | | cosigners | | | +--------------------------------+------------+-----------+ | Standalone, CA and three | 10,111 B | 13,843 B | | cosigners | | | +--------------------------------+------------+-----------+ | Standalone, CA and four | 12,538 B | 16,270 B | | cosigners | | | +--------------------------------+------------+-----------+ Table 4: Handshake authentication data with ML-DSA-44, in bytes sanketh Expires 6 May 2027 [Page 37] Internet-Draft MTC Architecture November 2026 6.2. Renewal and configuration lag Renewal overlaps the old and new certificates, except after an endpoint key compromise (Section 10.4 of [MTC]). 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 Section 10.4 of [MTC] recommends. A server that replaces its certificate in place sends the standalone certificate to every relying party until the new landmark reaches it; Appendix B.8 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 (Appendix B.8). 7. 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 Section 3.1. For each guarantee, Section 3.8 gives the services whose compromise defeats it. 7.1. 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 (Section 12.2 of [MTC]). A new log number addresses a failed log. Only a new CA instance addresses a compromised key (Section 5.4, Appendix B.4). 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 (Section 5.4). Recovery without replacing the key therefore still needs later log numbers to be rejected, and the entries of the exposure window to be revoked (Appendix C.2). 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 Appendix C.1. // Editor's note: No specification assigns the role of deciding such sanketh Expires 6 May 2027 [Page 38] Internet-Draft MTC Architecture November 2026 // 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 ([TLOG-WITNESS], [TLOG-MIRROR]), // and [MTC-TLOG] 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 (Appendix C.2). 7.2. 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. sanketh Expires 6 May 2027 [Page 39] Internet-Draft MTC Architecture November 2026 7.3. 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 Section 5.2. A compromised monitor can suppress findings but changes nothing a relying party accepts (Section 2.5). 7.4. 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 ([TLOG-MIRROR]). * Either signs on sign-subtree, whose only authentication is its own earlier cosignature ([TLOG-WITNESS]). 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" (Section 6.3 of [MTC]) 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 (Section 12.2 of [MTC]). One failed retrieval, though, does not distinguish withholding from an outage. 7.5. 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 (Section 4.7.1 of [RFC9846], Appendix B.2). sanketh Expires 6 May 2027 [Page 40] Internet-Draft MTC Architecture November 2026 * The weakest credential (Section 4.3). TLS's downgrade protection covers negotiated parameters (Appendix F.1 of [RFC9846]), not which credential an impersonator presents. * Targeting. Advertised landmark identifiers can show which relying parties lack a range (Section 8). _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 Section 3.5.1; and * limits the time since the last full handshake (Section 4.7.1 of [RFC9846]), under the bounded-delay form to D. 7.6. Outside the threat model As in Section 8.5 of [RFC9750], 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. 7.7. 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 12.1 and 12.6 of [MTC]); and * signing interfaces that keep cosigner messages separate from other uses of the key (Section 12.8 of [MTC]). sanketh Expires 6 May 2027 [Page 41] Internet-Draft MTC Architecture November 2026 [MTC] does not define updates (Section 5.5). 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 (Section 12.6 of [MTC]). 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 (Section 3.4). [MTC-TLOG] offers one signature algorithm, ML-DSA-44 ([FIPS204], [RFC9881]), 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 (Section 7.6). So the post-quantum security of every guarantee includes the algorithms of the update and verifier signing keys, which a deployment states. 7.8. Analysis Appendix A sketches why each guarantee of Section 3 holds under its premises, together with the storage lemma behind the mirror rules of Section 2.4 and the halt bound of Appendix C.1. The argument for G4 also covers cosigner removal and the rest of a CA instance's configuration, where every update carries all of it (Section 5.2). Three further claims are stated without a sketch: CA log recovery (Appendix B.5), the split form of single initialization (Appendix B.6), and an update service acting as a witness (Appendix B.3). 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 Section 7.5; sanketh Expires 6 May 2027 [Page 42] Internet-Draft MTC Architecture November 2026 * 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 (Section 5.2); * replacement of the update key or service; * the CA log recovery of Appendix B.5 where the signing service persists its record after using the key, before releasing the signature; * the detection condition of Section 3.4; and * the second-CA-signature hedge of Appendix B.3. 8. Privacy considerations Public logs disclose issuance, though subject keys appear only as hashes. Advertised landmark identifiers reveal a relying party's update state (Sections 8.2.1 and 11 of [MTC]). Deployments choose: * whether the identifiers are sent on every connection, only when the server offers them, for example in its HTTPS/SVCB record (Section 10.1 of [TAI]), 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 (Section 5.6 of [TAI]). 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 [RFC6973] 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 Section 11.2.4 of [TAI] that detection no sanketh Expires 6 May 2027 [Page 43] Internet-Draft MTC Architecture November 2026 longer offsets. Activating landmarks after a delay, with ranges effective at installation, weakens the signal. The bounded-delay form (Section 3.5.1) 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 [RFC9849] 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. 9. IANA considerations This document has no IANA actions. 10. References 10.1. Normative References [COSIG] C2SP, "Transparency Log Cosignatures", C2SP tlog- cosignature@v1.1.0, October 2026, . [MTC] Benjamin, D., O'Brien, D., Westerbaan, B., Valenta, L., and F. Valsorda, "Merkle Tree Certificates", Work in Progress, Internet-Draft, draft-ietf-plants-merkle-tree- certs-08, 1 November 2026, . [MTC-TLOG] C2SP, "Merkle Tree Certificates With Tiled Transparency Logs", C2SP mtc-tlog@v0.1.0, October 2026, . [RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, . [TAI] Beck, B., Benjamin, D., O'Brien, D., and K. Nekritz, "TLS Trust Anchor Identifiers", Work in Progress, Internet- Draft, draft-ietf-tls-trust-anchor-ids-07, 1 November 2026, . [TLOG-MIRROR] C2SP, "Transparency Log Mirrors", C2SP tlog-mirror@v0.1.0, October 2026, . sanketh Expires 6 May 2027 [Page 44] Internet-Draft MTC Architecture November 2026 [TLOG-TILES] C2SP, "Tiled Transparency Logs", C2SP tlog-tiles@v1.0.0, October 2026, . [TLOG-WITNESS] C2SP, "Transparency Log Witness Protocol", C2SP tlog- witness@v1.1.0, October 2026, . 10.2. Informative References [APPLE-CT] Apple, "Apple's Certificate Transparency policy", 21 April 2025, . [APPLE-CT-LOGS] Apple, "Apple's Certificate Transparency Log Program", October 2026, . [APPLE-LIFECYCLE] Apple, "Apple Root Program Root CA Lifecycle and Replacement Plan", October 2026, . [APPLE-PQC] Apple, "Apple Root Program PQC announcement", September 2026, . [CABF-SC081] CA/Browser Forum, "Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods", 11 April 2025, . [CHECKPOINT] C2SP, "Transparency Log Checkpoints", C2SP tlog- checkpoint@v1.1.0, October 2026, . [CHROME-CT] Google Chrome, "Chrome Certificate Transparency Policy", 2026, . sanketh Expires 6 May 2027 [Page 45] Internet-Draft MTC Architecture November 2026 [CHROME-CT-LOGS] Google Chrome, "Chrome CT Log Policy", 2026, . [CHROME-PQ] Chrome Secure Web Networking Team, "Cultivating a robust and efficient quantum-safe HTTPS", 27 February 2026, . [CQRP] Google Chrome, "Chrome Quantum-resistant Root Program Policy, Version 0.4.0 (draft)", Release candidate 1.0.0, commit c5a8a8eceafc, October 2026, . [CT-LANDSCAPE] Gustafsson, J., Overier, G., Arlitt, M., and N. Carlsson, "A First Look at the CT Landscape: Certificate Transparency Logs in Practice", Passive and Active Measurement (PAM 2017), 2017, . [CT-LOG-FAILURES] Ayer, A., "Learning from Certificate Transparency Log Failures", Transparency.dev Summit 2025, 2025, . [DIGICERT-2025] DigiCert and Google Chrome, "DigiCert working to address log issues", ct-policy mailing list, March 2025, . [EMUDHRA-APPLE] Apple, "About the compromised eMudhra intermediate CAs", 29 October 2026, . [EMUDHRA-BUG] Mozilla, "eMudhra: Private key compromise of Intermediate Certificates", Mozilla Bugzilla, bug 2083449, October 2026, . sanketh Expires 6 May 2027 [Page 46] Internet-Draft MTC Architecture November 2026 [EMUDHRA-CHROME] Google Chrome and Android Security Teams, "Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates", 20 October 2026, . [EMUDHRA-SITE] Jackson, D., "eMudhra Intermediate CA Compromise", 28 October 2026, . [ENTERPRISE] Elkins, N. and M. ackermann, "Enterprise Deployment Considerations for Standalone Merkle Tree Certificates", Work in Progress, Internet-Draft, draft-elkins-plants- enterprise-mtc-deployment-01, 19 October 2026, . [FIPS204] National Institute of Standards and Technology, "Module- Lattice-Based Digital Signature Standard", NIST FIPS 204, August 2024, . [LE-CT-EOL] Aas, J., "End of Life Plan for RFC 6962 Certificate Transparency Logs", 14 August 2025, . [LE-CT-LOGS] Let's Encrypt, "Certificate Transparency (CT) Logs", 4 September 2026, . [LE-CT-TALK] McPherrin, M., "Shining a new light on Certificate Transparency", Transparency.dev Summit 2024, 10 October 2024, . [LE-SHORTLIVED] McPherrin, M., "6-day and IP Address Certificates are Generally Available", 15 January 2026, . sanketh Expires 6 May 2027 [Page 47] Internet-Draft MTC Architecture November 2026 [MAMMOTH-2024] Sectigo, "Mammoth2024h1 CT log has stopped accepting new entries", ct-policy mailing list, January 2024, . [MOZILLA-RSP] Mozilla, "Mozilla Root Store Policy, Version 3.1", July 2026, . [PQ-MIGRATION] Benjamin, D. and J. DeBlasio, "Post-Quantum HTTPS Authentication Roadmap", 27 February 2026, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, DOI 10.17487/RFC6928, April 2013, . [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . sanketh Expires 6 May 2027 [Page 48] Internet-Draft MTC Architecture November 2026 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, . [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, . [RFC9750] Beurdouche, B., Rescorla, E., Omara, E., Inguva, S., and A. Duric, "The Messaging Layer Security (MLS) Architecture", RFC 9750, DOI 10.17487/RFC9750, April 2025, . [RFC9773] Gable, A., "ACME Renewal Information (ARI) Extension", RFC 9773, DOI 10.17487/RFC9773, June 2025, . [RFC9849] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849, March 2026, . [RFC9881] Massimo, J., Kampanakis, P., Turner, S., and B. E. Westerbaan, "Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA)", RFC 9881, DOI 10.17487/RFC9881, October 2025, . [RFC9925] Benjamin, D., "Unsigned X.509 Certificates", RFC 9925, DOI 10.17487/RFC9925, February 2026, . sanketh Expires 6 May 2027 [Page 49] Internet-Draft MTC Architecture November 2026 [SIGNED-NOTE] C2SP, "Note", C2SP signed-note@v1.1.0, October 2026, . [STATIC-CT] C2SP, "The Static Certificate Transparency API", C2SP static-ct-api@v1.1.0, March 2026, . [TAI-138] TLS Working Group, "Properties: SPKI, Not stand-alone, Last algorithm ignore", tls-trust-anchor-ids pull request 138, 2026, . [TUF] The Update Framework, "The Update Framework Specification, Version 1.0.37", October 2026, . [TURDUCKEN] Benjamin, D., Bonnell, C., Gray, J., and M. Ounsworth, "Embedded Alternate Issuer Certificates", Work in Progress, Internet-Draft, draft-davidben-lamps-turducken- certs-00, 1 November 2026, . [USE-CASES] Gray, J., Klaußner, J., T, L., and G. Mallaya, "Merkle Tree Certificates Deployment Use Cases", Work in Progress, Internet-Draft, draft-ietf-plants-mtc-deploy-use-cases-00, 23 October 2026, . Appendix A. 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. Section 7.8 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 Section 3.1 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: sanketh Expires 6 May 2027 [Page 50] Internet-Draft MTC Architecture November 2026 * _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 Section 5.3.1 of [MTC], and the update encoding of Section 7.7, to encode injectively and to be separate from the key's other uses (Section 12.8 of [MTC]). 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 (Section 3.6). * _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 (Section 4 of [MTC]). 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 (Section 12.1 of [MTC]) 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 Section 2.4 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 [TLOG-MIRROR] commits every covered entry at or above the minimum index before signing. Single initialization is what fixes m0. A sanketh Expires 6 May 2027 [Page 51] Internet-Draft MTC Architecture November 2026 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 (Section 7.2 of [MTC]), 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 sanketh Expires 6 May 2027 [Page 52] Internet-Draft MTC Architecture November 2026 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. Appendix B. Deployment notes This appendix collects deployment detail that supports the guarantees but is not needed to state them. B.1. The bounded-delay form in practice The bounded-delay form of Section 3.5.1 has these costs: Availability: Beyond the outage of Section 3.5.1, 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. sanketh Expires 6 May 2027 [Page 53] Internet-Draft MTC Architecture November 2026 Posture: Section 8.2.1 of [MTC] 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 [CQRP] is classical (the Introduction). That certificate's assurance then sets that of the name (Section 4.3). 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 Section 8.2.2 of [MTC], 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 Section 9.2 of [MTC] leaves optional, or through the server's own configuration (Section 7.3 of [TAI]). Otherwise, only the recovery of Section 5.6 of [TAI], 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 (Section 5.1 of [TAI]). 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 sanketh Expires 6 May 2027 [Page 54] Internet-Draft MTC Architecture November 2026 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 (Appendix C.1). 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. B.2. Resumption and open connections Section 4.7.1 of [RFC9846] 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" (Section 4.7.1 of [RFC9846]). The check of Section 7.5 fits there. The client need not verify the certificate again, since removing a trusted subtree is not revocation (Section 5.3). 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 Appendix A. B.3. Root-program examples These examples are dated: [CQRP] is version 0.4.0 (October 2026), and Apple's policy was announced as a draft. In [CQRP], 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 [CQRP]). Section 1.3 of [CQRP] tests independence: sanketh Expires 6 May 2027 [Page 55] Internet-Draft MTC Architecture November 2026 operators that "share no common ownership, ultimate corporate control, parent companies, administrative access, or control over cosigner key material". In the terms of Table 2, 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 [CQRP], given G5. In the sense of Section 3.4, 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 (Section 6.1). Split views are answered after detection, with revoked ranges or distrust, whose delay is that of Section 3.5. 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 [CQRP]). 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 [CQRP] 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. [CQRP] 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 [CQRP] does not yet mention a // mirror's initial minimum index, in that rule or in the criteria of // Section 2.4.5 (Section 2.4), 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 [APPLE-PQC]: sanketh Expires 6 May 2027 [Page 56] Internet-Draft MTC Architecture November 2026 * "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 5.3 and 5.3.1 of [MTC] 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 Section 5.4 of [MTC]. 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: Section 5.3 of [MTC] (version -08) leaves other // cosigner roles to other documents and deployments, and Section 5.4 // of [MTC] defines a single CA cosigner, with one key per cosigner // ID (Section 5.3.3 of [MTC]), so a second CA signature needs a role // of its own. [MTC-TLOG] and [COSIG] 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 [CQRP] 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 8.1 and 8.2.1 of [MTC]), and the recovery of Section 5.6 of [TAI] cannot tell them apart either. Programs can share cosigners, or CAs can carry the union of the programs' required cosignatures. For the [CQRP] 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 [CQRP] 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. sanketh Expires 6 May 2027 [Page 57] Internet-Draft MTC Architecture November 2026 [CQRP] 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 [CQRP]). 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 [CQRP]). How a frozen mirror's bound relates to a fork, and what a halt must cover, are in Section 5.2 and Appendix C.1. Status signing can run out of conforming keys. A CA cosigner key signs status only for its own instance (Section 5.4 of [MTC]). Once that key is retired, a policy that has CRLs signed only with active keys, as Section 2.4.3.3 of [CQRP] reads, leaves no conforming signer for that instance's certificates. After a compromise, the only such signer is the compromised key (Appendix C.2). The Key Sunset of [CQRP] 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 Appendix C.2. There, bounding each log instance, rather than one serial interval, is what keeps earlier logs closed. B.4. Offline trust anchors and online keys Root keys in today's Web PKI are offline, but the CA cosigner key is online. [CQRP] 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 [CQRP]). 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 5.5 and 7.1 of [MTC]). This protects the binding of CA identifier, key, and serial bounds. It suits programs other than [CQRP], 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 (Section 7.1 of [MTC]). 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 (Section 7.5 of [MTC]). That means either repeated root ceremonies or ranges delivered separately. sanketh Expires 6 May 2027 [Page 58] Internet-Draft MTC Architecture November 2026 * An offline authority can authorize configuration updates. The Merkle Tree CA is then itself a trust anchor [RFC9925], and the update channel plays the role of the root. This also protects policy, subtrees, and ranges (Section 7.2). * The CA operator can hold offline reserve CA cosigner keys. [CQRP] already keeps two of these in its root store (Sections 2.6.2 and 2.6.3), and Section 3.1.3 of [MOZILLA-RSP] 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. [CQRP] 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 ([APPLE-LIFECYCLE]). 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 (Appendix C.2). Reserve keys serve recovery. For availability, [CQRP] 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 (Section 5.4 of [MTC]), such as signing CRLs, can pass through the signing service of Section 2.2 as a second message type. This enforces the separation of Section 12.8 of [MTC]. B.5. 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 ([TLOG-TILES]), so the rebuilt log includes each published entry unchanged, at the same index. Entries appended beyond that checkpoint and not published were never certified (Section 5.4 of [MTC]). 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 [CQRP]). This recovery preserves every view the key signed, even when the discarded indices sanketh Expires 6 May 2027 [Page 59] Internet-Draft MTC Architecture November 2026 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 5.2 and 12.2.1 of [MTC]), rather than resuming from an earlier checkpoint (Section 5.4). 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. B.6. Witnesses and mirrors in practice [MTC-TLOG] 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 ([COSIG]). An existing witness can add an ML-DSA-44 key alongside its Ed25519 one, since [TLOG-WITNESS] returns cosignatures from "the witness key(s)" and says witnesses "SHOULD use ML-DSA-44". [MTC-TLOG] 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 [CQRP], 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 (Appendix B.5), 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 [TLOG-MIRROR] makes optional and [MTC-TLOG] says such a cosigner "SHOULD implement". A hardware module protects a mirror's key against extraction, and [CQRP] 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. [CQRP] 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 [CQRP]). Under that program, a mirror that loses one log's state and follows Section 2.4 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 sanketh Expires 6 May 2027 [Page 60] Internet-Draft MTC Architecture November 2026 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. B.7. Obtaining landmark-relative certificates An authenticating party obtains the landmark-relative certificate from the CA, through the ACME optional alternate of Section 9 of [MTC], or builds it from the log and landmark file ([MTC-TLOG]). 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 (Section 6.4.3 of [MTC]). 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. B.8. Sizes, transport, and renewal The sizes in Table 4 come from these figures (Sections 6.2 and 6.5 of [MTC]): * 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). sanketh Expires 6 May 2027 [Page 61] Internet-Draft MTC Architecture November 2026 * 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. [CQRP] 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 Table 4 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 Section 1 of [MTC]. [CQRP] adds no post-quantum X.509 roots (the Introduction). The expected cost per handshake depends on how often the trusted-subtree path is used (Section 10.2 of [MTC]). That frequency is the product of relying-party freshness and server support (Section 4.3). 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 [RFC6928]. 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 (Section 8.1 of [RFC9000]). 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 (Figure 6). 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 [CQRP] tolerates, leaves about 17 hours. For 47-day certificates under [CQRP], with landmarks every 4 hours (Section 2.6.2), the tolerated lag is about 278 hours. sanketh Expires 6 May 2027 [Page 62] Internet-Draft MTC Architecture November 2026 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 Figure 6: Renewal overlap and the tolerated configuration lag (not to scale) ACME Renewal Information [RFC9773] 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 Section 6.2 assumes the server keeps the old certificate ("SHOULD retain both the new and old certificates", Section 10.4 of [MTC]). 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. Section 9.1 of [MTC] 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 (Section 5.1), 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 Section 5.6 of [TAI], 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 Section 6.5 of [MTC]'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 sanketh Expires 6 May 2027 [Page 63] Internet-Draft MTC Architecture November 2026 expiry can be the better answer. Mirrors on the issuance path see the same multiple. Under [CQRP], 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. B.9. Retention Section 10.3 of [MTC] states the condition for retention (Section 4.4). [CQRP], 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 [CQRP]). [MTC-TLOG] 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". Section 10.3 of [MTC] 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 (Section 8), along with which certificates handshakes use. Appendix C. Responding to CA compromise This appendix details the two responses to CA compromise that Section 7.1 summarizes. C.1. Halting new issuance The CA operator's first step is to stop issuance on the affected log or instance. Section 2.5.2 of [CQRP] 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. sanketh Expires 6 May 2027 [Page 64] Internet-Draft MTC Architecture November 2026 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 (Section 3.6). 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 (Appendix A). 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 Section 7.1 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 [CQRP] // 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. C.2. 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: sanketh Expires 6 May 2027 [Page 65] Internet-Draft MTC Architecture November 2026 * Under a CA-only policy, the attacker can sign a different subtree over indices below the cutoff (Section 2.1). * 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 (Section 6.2 of [MTC]). 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 (Appendix B.4). * 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. Section 5.4 of [MTC] allows that key to sign such status, and Section 2.4.3.3 of [CQRP] has CRLs signed with it. Acknowledgements This document draws on the specifications and policy it describes ([MTC], [TAI], [MTC-TLOG], [TLOG-TILES], [CHECKPOINT], [SIGNED-NOTE], [COSIG], [TLOG-WITNESS], [TLOG-MIRROR], [CQRP]) 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. [TLOG-WITNESS] began as a document of the Sigsum project. Luke Valenta raised the key-custody question in Appendix B.4; David Benjamin raised the privacy choices around update recency in Section 8; and Ilari Liusvaara raised the log-fork problem in Section 2.2. Author's Address sanketh AWS sanketh Expires 6 May 2027 [Page 66] Internet-Draft MTC Architecture November 2026 Email: sgmenda@amazon.com sanketh Expires 6 May 2027 [Page 67]