From 77a46d0744c29ff2e9101011732a7c8e737edf73 Mon Sep 17 00:00:00 2001 From: Chris Clements Date: Wed, 28 Oct 2026 09:06:07 -0400 Subject: [PATCH 01/15] Update ari-operational-test-report.schema.json Align with CQRP Policy RC1 --- .../ari-operational-test-report.schema.json | 23 ------------------- 1 file changed, 23 deletions(-) diff --git a/content/cqrp/disclosures/ari-operational-test-report.schema.json b/content/cqrp/disclosures/ari-operational-test-report.schema.json index 26da483..b01fd32 100644 --- a/content/cqrp/disclosures/ari-operational-test-report.schema.json +++ b/content/cqrp/disclosures/ari-operational-test-report.schema.json @@ -138,10 +138,6 @@ "issuance_log_entry_index", "ari_renewal_window", "outcome", - "user_agent", - "parsed_client", - "user_agent_source", - "renewal_timestamp", "time_to_renewal_seconds" ], "properties": { @@ -168,23 +164,6 @@ "type": "string", "enum": ["pass", "fail"] }, - "user_agent": { - "type": "string", - "description": "Full untruncated HTTP User-Agent request header string." - }, - "parsed_client": { - "type": "object", - "required": ["name", "version"], - "properties": { - "name": { "type": "string", "minLength": 1 }, - "version": { "type": "string", "minLength": 1 } - }, - "additionalProperties": false - }, - "user_agent_source": { - "type": "string", - "enum": ["renewal_request", "initial_issuance"] - }, "renewal_timestamp": { "type": ["string", "null"], "format": "date-time", @@ -201,5 +180,3 @@ }, "additionalProperties": false } - - From 9fa5a73e1107a45d0e717d20ec458506c9803d34 Mon Sep 17 00:00:00 2001 From: Chris Clements Date: Wed, 28 Oct 2026 09:07:21 -0400 Subject: [PATCH 02/15] Update ari-operational-test-report.json Align with CQRP Policy RC1 --- .../disclosures/ari-operational-test-report.json | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/content/cqrp/disclosures/ari-operational-test-report.json b/content/cqrp/disclosures/ari-operational-test-report.json index b08f218..5c31f50 100644 --- a/content/cqrp/disclosures/ari-operational-test-report.json +++ b/content/cqrp/disclosures/ari-operational-test-report.json @@ -50,13 +50,7 @@ "end": "2026-08-08T12:00:00Z" }, "outcome": "pass", - "user_agent": "Certbot/2.6.0 (Ubuntu 22.04; certbot-ari-plugin/0.1.0)", - "parsed_client": { - "name": "Certbot", - "version": "2.6.0" - }, - "user_agent_source": "renewal_request", - "renewal_timestamp": "2026-08-05T16:00:00Z", + "renewal_timestamp": "2026-08-05T16:00:00Z", "time_to_renewal_seconds": 14400 }, { @@ -67,15 +61,8 @@ "end": "2026-08-08T12:00:00Z" }, "outcome": "fail", - "user_agent": "legacy-acme-client/1.0.0", - "parsed_client": { - "name": "legacy-acme-client", - "version": "1.0.0" - }, - "user_agent_source": "initial_issuance", "renewal_timestamp": null, "time_to_renewal_seconds": null } ] } - From 90b154e1cf4165963ebab751ed933989f8854907 Mon Sep 17 00:00:00 2001 From: Chris Clements Date: Wed, 28 Oct 2026 09:07:53 -0400 Subject: [PATCH 03/15] Update mtc-disclosures.json Align with CQRP Policy RC1 --- content/cqrp/disclosures/mtc-disclosures.json | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/content/cqrp/disclosures/mtc-disclosures.json b/content/cqrp/disclosures/mtc-disclosures.json index daf1ba3..ac69db2 100644 --- a/content/cqrp/disclosures/mtc-disclosures.json +++ b/content/cqrp/disclosures/mtc-disclosures.json @@ -5,7 +5,7 @@ "global_disclosures": { "ca_repository_url": "https://github.com/example-ca/pki-repository", "legal_entity_and_ownership_url": "https://example-ca.com/legal/ownership-and-control.html", - "status_and_incidents_url": "https://status.example-ca.com", + "operational_status_url": "https://status.example-ca.com", "facility_certification_url": "https://example-ca.com/compliance/iso27001-global.pdf" }, "ca_cosigner_keys": [ @@ -16,7 +16,11 @@ "policy_documents_url": "https://github.com/example-ca/pki-repository/blob/main/CPS-7day.md", "reserve_keys_url": "https://github.com/example-ca/pki-repository/blob/main/upcoming_keys_7day.json", "key_generation_attestation_url": "https://example-ca.com/audits/2026-key1-attestation.pdf", - "infrastructure_architecture_url": "https://github.com/example-ca/pki-repository/blob/main/arch-key1.md" + "infrastructure_architecture_url": "https://github.com/example-ca/pki-repository/blob/main/arch-key1.md", + "full_crl_urls": [ + "http://crl.example-ca.com/mtc-2026-7day-key1.crl" + ], + "partitioned_crl_urls": [] } }, { @@ -27,7 +31,12 @@ "reserve_keys_url": "https://github.com/example-ca/pki-repository/blob/main/upcoming_keys_47day.json", "key_generation_attestation_url": "https://example-ca.com/audits/2026-key2-attestation.pdf", "infrastructure_architecture_url": "https://github.com/example-ca/pki-repository/blob/main/arch-key2.md", - "facility_certification_url": "https://example-ca.com/compliance/iso27001-secondary-dc.pdf" + "facility_certification_url": "https://example-ca.com/compliance/iso27001-secondary-dc.pdf", + "full_crl_urls": [], + "partitioned_crl_urls": [ + "http://crl.example-ca.com/mtc-2026-47day-key2-p1.crl", + "http://crl.example-ca.com/mtc-2026-47day-key2-p2.crl" + ] } } ] From 28585b2891db2b1905730ea97bde1f0b5dfc24a6 Mon Sep 17 00:00:00 2001 From: Chris Clements Date: Wed, 28 Oct 2026 09:08:24 -0400 Subject: [PATCH 04/15] Update mtc-disclosures.schema.json Align with CQRP Policy RC1 --- .../disclosures/mtc-disclosures.schema.json | 36 +++++++++++++++---- 1 file changed, 29 insertions(+), 7 deletions(-) diff --git a/content/cqrp/disclosures/mtc-disclosures.schema.json b/content/cqrp/disclosures/mtc-disclosures.schema.json index b3b7abd..979c9d8 100644 --- a/content/cqrp/disclosures/mtc-disclosures.schema.json +++ b/content/cqrp/disclosures/mtc-disclosures.schema.json @@ -30,7 +30,7 @@ "required": [ "ca_repository_url", "legal_entity_and_ownership_url", - "status_and_incidents_url", + "operational_status_url", "facility_certification_url" ], "properties": { @@ -44,10 +44,10 @@ "format": "uri", "description": "URL detailing legal entity status, beneficial ownership, and corporate control." }, - "status_and_incidents_url": { + "operational_status_url": { "type": "string", "format": "uri", - "description": "URL to public operational status and incident reporting pages." + "description": "URL to public operational status reporting pages." }, "facility_certification_url": { "type": "string", @@ -76,22 +76,24 @@ "key_sha256": { "type": "string", "pattern": "^[a-fA-F0-9]{64}$", - "description": "Hex-encoded SHA-256 hash of the CA Cosigner Key public key." + "description": "Hex-encoded SHA-256 hash of the CA Cosigner Key's DER-encoded SubjectPublicKeyInfo (SPKI)." }, "disclosures": { "type": "object", - "description": "Key-specific disclosure URLs.", + "description": "Key-specific disclosure URLs and CRL Distribution Points.", "required": [ "policy_documents_url", "reserve_keys_url", "key_generation_attestation_url", - "infrastructure_architecture_url" + "infrastructure_architecture_url", + "full_crl_urls", + "partitioned_crl_urls" ], "properties": { "policy_documents_url": { "type": "string", "format": "uri", - "description": "URL to the Markdown/AsciiDoc CPS for this specific key." + "description": "URL to the Markdown/AsciiDoc CP/CPS for this specific key." }, "reserve_keys_url": { "type": "string", @@ -112,6 +114,26 @@ "type": "string", "format": "uri", "description": "Optional override URL for facility certification if this key is hosted in a distinct facility." + }, + "full_crl_urls": { + "type": "array", + "description": "Array of HTTP URLs for all Full (complete) CRLs issued by this CA Cosigner Key. MUST be an empty array ([]) if this key only issues partitioned CRLs or is an offline Reserve key.", + "items": { + "type": "string", + "format": "uri", + "pattern": "^http://" + }, + "uniqueItems": true + }, + "partitioned_crl_urls": { + "type": "array", + "description": "Array of HTTP URLs for all Partitioned CRLs issued by this CA Cosigner Key. MUST be an empty array ([]) if this key only issues full CRLs or is an offline Reserve key.", + "items": { + "type": "string", + "format": "uri", + "pattern": "^http://" + }, + "uniqueItems": true } }, "additionalProperties": false From 8106d3151039175fa5375787494c1bea3d0bfe02 Mon Sep 17 00:00:00 2001 From: Chris Clements Date: Wed, 28 Oct 2026 09:36:04 -0400 Subject: [PATCH 05/15] Update apply.md Align with CQRP Policy RC1 --- content/cqrp/apply.md | 91 +++++++++++++++++++++++-------------------- 1 file changed, 48 insertions(+), 43 deletions(-) diff --git a/content/cqrp/apply.md b/content/cqrp/apply.md index c3fca5e..576cb6e 100644 --- a/content/cqrp/apply.md +++ b/content/cqrp/apply.md @@ -4,52 +4,54 @@ title: Chrome Quantum-resistant Root Program - Preparing and Applying for Inclus # [DRAFT] Preparing and Applying for Inclusion -## Last updated: 2026-08-14 +## Last updated: 2026-10-28 -The Chrome Quantum-resistant Root Program's (CQRP) primary commitment is to the security of Chrome's users. Chrome continuously works to improve the baseline of security on the web, and its policies, procedures, and initiatives reflect that goal. Every [Merkle Tree Certificate](https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/) Certification Authority (MTC CA) and Mirroring Cosigner in the Chrome Quantum-resistant Root Store (CQRS) is a critical link in the chain of trust relied upon by Chrome’s billions of users. Any compromise or misoperation by a single operator can have cascading, detrimental effects, with harm not limited to Subscribers of the corresponding operator. +The Chrome Quantum-resistant Root Program's (CQRP) primary commitment is to the security of Chrome's users. Chrome continuously works to improve the baseline of security on the web, and its policies, procedures, and initiatives reflect that goal. Every [Merkle Tree Certificate](https://datatracker.ietf.org/doc/html/draft-ietf-plants-merkle-tree-certs-07) Certification Authority (MTC CA) and Mirroring Cosigner in the Chrome Quantum-resistant Root Store (CQRS) is a critical link in the chain of trust relied upon by Chrome’s billions of users. Any compromise or misoperation by a single operator can have cascading, detrimental effects, with harm not limited to Subscribers of the corresponding operator. -Ultimately, in order for an operator’s inclusion request to be accepted, it must clearly and unequivocally demonstrate how their organization meets the high standards defined in the [CQRP Policy](draft-policy.md). The burden of proof rests entirely on the entity applying to proactively and unquestionably demonstrate this commitment, thereby clearly offsetting the inherent and significant security risks of inclusion. +Ultimately, in order for an operator’s inclusion request to be accepted, it must clearly and unequivocally demonstrate how its organization meets the high standards defined in the [CQRP Policy](https://googlechrome.github.io/chromerootprogram/cqrp/draft-policy/). The burden of proof rests entirely on the entity applying to proactively and unquestionably demonstrate this commitment, thereby clearly offsetting the inherent and significant security risks of inclusion. -Google includes or removes operators in the CQRS as it deems appropriate at its sole discretion. Google selects and continues to include Cosigner keys to enhance Chrome's security. Operators included in the CQRS must provide value to Chrome end users that clearly exceeds the risk of their continued inclusion. To that end, the CQRP Policy defines the minimum requirements that MTC CA Operators and Mirroring Operators must meet for both initial and continued inclusion in the CQRS. The policy is periodically updated to further promote the CQRP’s goals: **security, simplicity, predictability, transparency,** and **resilience**. +Google includes or removes operators in the CQRS as it deems appropriate at its sole discretion. Google selects and continues to include Cosigner keys to enhance Chrome's security. Operators included in the CQRS must provide value to Chrome end users that clearly exceeds the risk of their continued inclusion. To that end, the CQRP Policy defines the minimum requirements that MTC CA Operators and Mirroring Operators must meet for both initial and continued inclusion in the CQRS. The policy is periodically updated to further promote the CQRP’s goals: **security**, **simplicity**, **predictability**, **transparency**, and **resilience**. > [!NOTE] -> A future update to this process may require the use of the Common CA Database ([CCADB](https://www.ccadb.org/)) for inclusion submissions, rather than using the [Chromium Issues Tracker](https://issues.chromium.org/u/0/issues/new?component=2114629&pli=1&authuser=0&template=0). +> A future update to this process may require the use of the Common CA Database ([CCADB](https://www.ccadb.org/)) for inclusion submissions, rather than using the [Chromium Issues Tracker](https://issues.chromium.org/issues/new?component=2114629&template=2386551). -## 1. Roles and Prerequisites for Inclusion Requests +## **1. Roles and Prerequisites for Inclusion Requests** -Entities interested in applying for inclusion to the CQRS can do so under one of 2 operational roles: +As [described](https://googlechrome.github.io/chromerootprogram/cqrp/draft-policy/) in the CQRP Policy, all MTC CA Operators are also Mirroring Operators. Applying for inclusion in the CQRS represents a commitment to operate as both a Mirroring Operator and an MTC CA Operator. -1. **Mirroring Operator:** Responsible for operating a Mirroring Cosigner service to cosign issuance log views, guaranteeing ecosystem transparency and split-view resistance. A Mirroring Operator that is not also an MTC CA Operator is referred to as an “Independent Mirroring Operator.” -2. **MTC CA Operator:** Responsible for Subscriber certificate issuance and issuance log operation. All MTC CA Operators need to also fulfill the duties of a Mirroring Operator. +As detailed in Section 1.1. ("Eligibility") of the CQRP Policy, initial eligibility to apply for inclusion in the CQRS is restricted to [CT Log operators](https://certificate.transparency.dev/logs/) with at least one "[usable](https://googlechrome.github.io/CertificateTransparency/log_states.html)" log in Chrome before February 1, 2026. -Except for CT Log [operators](https://certificate.transparency.dev/logs/) with at least one “[usable](https://googlechrome.github.io/CertificateTransparency/log_states.html)” log in Chrome before February 1, 2026, demonstrating the high-availability infrastructure and operational maturity required for global certificate issuance, a CQRS Applicant applying to become an MTC CA Operator need to first be an Independent Mirroring Operator in good standing for at least 90 consecutive calendar days before submitting an MTC CA Operator inclusion request. +> [!NOTE] +> Beginning in 2027H2, a future update to the CQRP Policy is expected to allow organizations that do not meet the initial eligibility restrictions above to apply for inclusion. Those prospective operators will be required to demonstrate reliable, high-availability and consistent operation of their Mirroring Cosigner in the CQRS for a specified period before their CA Cosigners will be considered for inclusion as an MTC CA Operator. + +Though eligible CQRS Applicants are preferred to submit a complete inclusion request covering both their Mirroring Cosigner and CA Cosigner operations simultaneously, the CQRP recognizes the technical and operational effort required to deploy a complete MTC infrastructure. To help bootstrap ecosystem mirroring availability and allow operators to gain operational experience incrementally, an eligible CQRS Applicant may initially submit an inclusion request populating only the required Operator and Mirroring Cosigner fields, deferring the CA Cosigner artifacts to a subsequent update. In this case, the CQRS Applicant may omit the `facility_certification` and all `ca_cosigner_keys` information from their `mtc-disclosures.json` until applying as an MTC CA Operator. + +However, this staged onboarding path is time-bounded. An operator that initially enters the CQRS solely as a Mirroring Operator must submit a complete MTC CA Operator inclusion update within 3 years of its Mirroring Cosigner first being accepted into the CQRS. If the operator does not submit the required CA Cosigner materials within this 3-year window, or it fails to progress to MTC CA Operator inclusion, the operator should expect its Mirroring Cosigner to be phased out (transitioned to `Frozen` and subsequently `Removed`) from the CQRS. -## 2. Submission Process +## **2. Submission Process** -### 2.1. Initial Submission +### **2.1. Initial Submission** -CQRS inclusion requests are submitted using the Operator template [TODO: create and link to template] in the Chromium Issues Tracker. Depending on the intended role of the operator, specific information is required and described by the template. By creating a new issue in the Chromium Issue Tracker the entity is asserting they are organizationally distinct from all existing operators present in [cosigners.json](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json). +CQRS inclusion requests are submitted using the New MTC Operator template in the [Chromium Issues Tracker](https://issues.chromium.org/issues/new?component=2114629&template=2386551). By creating a new issue in the Chromium Issues Tracker, the entity is asserting it is organizationally distinct from all existing operators present in [cosigners.json](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json). All application artifacts need to be hosted from a publicly-accessible Repository (as defined within the Baseline Requirements). At any point during its review, the CQRP may contact the operator seeking additional or clarifying information. Operators are expected to provide the requested information promptly, and no later than 14 days unless specified otherwise. -### 2.2. Updating Submissions +### **2.2. Updating Submissions** Inclusion request submissions are expected to remain up-to-date as operational representations change. This includes updating the issue in the Chromium Issues Tracker as planned key lifecycle events become known, as detailed in the subsections below. -If an Independent Mirroring Operator intends to apply for inclusion as an MTC CA Operator, they are expected to use their preexisting issue and provide the additional template details required for MTC CA Operators. +#### **2.2.1. Submitting new Mirroring Cosigner Keys** -#### 2.2.1. Submitting new Mirroring Cosigner Keys +Existing Mirroring Operators can apply to have a new Mirroring Cosigner Key included in the CQRS by updating their existing issue on the Chromium Issues Tracker. -Existing Mirroring Operators can apply to have a new Mirroring Cosigner Key included in the CQRS by updating their existing issue on the Chromium Issue Tracker. - -#### 2.2.2. Submitting new CA Cosigner Keys +#### **2.2.2. Submitting new CA Cosigner Keys** Existing MTC CA Operators can apply to have CA Cosigner Keys rotated in the CQRS, which will be processed according to a quarterly schedule (targeted for processing on the 15th day of January, April, July, and October). This includes: -1. At least 30 days prior to the target quarterly update date, the existing MTC CA Operator will publish the new MTC CA Cosigner Certificates (i.e., Reserve CA Cosigner Keys) on its Repository, update their existing issue in the Chromium Issues Tracker with the new key information, and announce the planned addition to mtcs [at] chromium [dot] org. The announcement needs to include the URL to the MTC CA Operators [mtc-disclosures.json](https://github.com/GoogleChrome/chromerootprogram/blob/main/content/cqrp/disclosures/mtc-disclosures.schema.json) ([example](https://github.com/GoogleChrome/chromerootprogram/blob/main/content/cqrp/disclosures/mtc-disclosures.json)). -2. After the CQRP reviews the issue and the key is added to the CQRS, the MTC CA Operator needs to update the issue explicitly stating when the Reserve CA Cosigner Key(s) are expected to transition to an Active state, which is when the MTC CA Operator can expect landmarks for the newly Active CA Cosigner Key(s) to be distributed to Chrome clients. +1. At least 30 days prior to the target quarterly update date, the existing MTC CA Operator will publish the new MTC CA Cosigner Certificates (i.e., Reserve CA Cosigner Keys) on its Repository, update their existing issue in the Chromium Issues Tracker with the new key information, and announce the planned addition to mtcs [at] chromium [dot] org. The announcement needs to include the URL to the MTC CA Operator’s [mtc-disclosures.json](https://github.com/GoogleChrome/chromerootprogram/blob/main/content/cqrp/disclosures/mtc-disclosures.schema.json) ([example](https://github.com/GoogleChrome/chromerootprogram/blob/main/content/cqrp/disclosures/mtc-disclosures.json)). +2. After the CQRP reviews the issue and the key is added to the CQRS, the MTC CA Operator needs to update the issue explicitly stating when the Reserve CA Cosigner Key(s) are expected to transition to an Active state, which is when the MTC CA Operator can expect landmarks for the newly Active CA Cosigner Key(s) to be distributed to Chrome clients. -## 3. Evaluation Process +## **3. Evaluation Process** Chrome evaluates inclusion requests through a structured review pipeline, generally adhering to the following high-level milestones: @@ -57,32 +59,35 @@ Chrome evaluates inclusion requests through a structured review pipeline, genera 2. Beneficial Ownership and Due Diligence Review 3. Public Discussion Period 4. Technical Compliance and Audit Verification -5. Inclusion Decision +5. Confirming Inclusion Provides Value to Chrome Users +6. Inclusion Decision -Once an inclusion request has all required artifacts, ongoing monitoring will occur as the review progresses through the high-level milestones. +Once an inclusion request has all required artifacts, ongoing monitoring will occur as the review progresses through the high-level milestones. -All Mirroring Cosigners need to pass a minimum 30-day compliance monitoring period before becoming `Qualified`. Once `Qualified`, a Mirroring Cosigner that maintains ongoing compliance with the CQRP policy will automatically transition to `Usable` after a 70-day propagation period, at which point its cosignatures will be relied upon for Chrome client validation. During this time, the CQRP will actively monitor the Mirroring Cosigner to ensure conformance to the technical specifications and availability requirements included in the CQRP Policy. In the event that the Mirroring Cosigner does not maintain ongoing compliance with the CQRP Policy, it will not be promoted `Usable`. +All Mirroring Cosigners need to pass a minimum 30-day compliance monitoring period before becoming `Qualified`. Once `Qualified`, a Mirroring Cosigner that maintains ongoing compliance with the CQRP policy will automatically transition to `Usable` after a 70-day propagation period, at which point its cosignatures will be relied upon for Chrome client validation. During this time, the CQRP will actively monitor the Mirroring Cosigner to ensure conformance to the technical specifications and availability requirements included in the CQRP Policy. In the event that the Mirroring Cosigner does not maintain ongoing compliance with the CQRP Policy, it will not be promoted to `Usable`. All operators should expect ongoing querying of their cosigners from Google’s compliance monitoring infrastructure throughout the lifetime of the mirror and/or issuance log. -## 4. Potential Outcomes +The duration, availability, incident history, and overall compliance record of an operator's Mirroring Operator service will be material to the evaluation of any subsequent MTC CA Operator inclusion request. Once eligibility is expanded in a future policy update (targeted for 2027H2), sustained, demonstrably reliable mirroring operations in good standing, beyond the minimum period ultimately specified, will be viewed favorably. Mirroring tenure alone does not establish eligibility, and does not entitle an operator to inclusion or to any particular order of request review by the CQRP. + +## **4. Potential Outcomes** Inclusion requests may conclude with one of the following outcomes: -* **Accepted**: An inclusion application is classified as “Accepted” when an entity proactively and unequivocally demonstrates full compliance with all technical, operational, procedural, and audit requirements defined within the CQRP Policy, and clearly establishes that the value of its inclusion for Chrome end users exceeds the associated security, privacy, and operational risks. - - Upon receiving an Accepted determination, the entity's key material, endpoints, and associated trust metadata will be scheduled for inclusion in the CQRS and distributed to Chrome clients on approximately, but not limited to, a targeted quarterly release cycle. However, the CQRP makes no guarantees on the timeliness of distribution. - - Acceptance does not constitute a permanent, irrevocable, or unconditional guarantee of trust. Included operators need to continuously maintain adherence to all ongoing policy obligations - including compliance monitoring metrics (uptime, cryptographic correctness, and mirror consistency) and prompt incident reporting. The CQRP reserves the right to modify, suspend, or revoke inclusion at its sole discretion if an operator fails to sustain these standards or if the risk of continued inclusion outweighs the benefit to Chrome users. - -* **Rejected**: An inclusion application is classified as “Rejected” when an entity fails to unequivocally demonstrate that the value of its inclusion to Chrome end users clearly exceeds the associated security, privacy, or operational risks. Rejection typically results from unaddressed technical, audit, or procedural deficiencies, incomplete or inaccurate disclosures, an incident reporting history that fails to reliably demonstrate the factors that are significant to the CQRP, or a failure to satisfy the minimum requirements defined within the CQRP Policy. - - An organization whose application is Rejected is typically subject to a standard 6 month cooling-off period, beginning on the date of the formal rejection determination. During this period, the organization is ineligible to submit new or revised inclusion requests to the CQRP. This cooling-off period provides the organization sufficient time to remediate identified deficiencies, demonstrate sustained operational stability, and obtain updated, compliant audit attestations prior to re-applying. - -* **Disqualified**: An entity is classified as “Disqualified” when the CQRP determines that they present an unacceptable or unmitigable risk to Chrome end users or the integrity of the web. Disqualification is reserved for, but not limited to: - * Being the subject of multiple application Rejections without demonstrating meaningful and measurable remediation; - * Intentional misrepresentation, falsification, or material omission of facts in public disclosures, audit attestations, or program communications; - * Willful non-compliance with the CQRP Policy; or - * Critical failures, key compromises, or operational practices that demonstrate an inability or unwillingness to maintain a robust "security-first" culture. - - An entity designated as Disqualified is permanently barred from applying for or receiving inclusion in the CQRS across all current and future PKI hierarchies operated, owned, or controlled by the organization, its subsidiaries, or its affiliates. +* **Accepted**: An inclusion application is classified as "Accepted" when an entity proactively and unequivocally demonstrates full compliance with all technical, operational, procedural, and audit requirements defined within the CQRP Policy, and clearly establishes that the value of its inclusion for Chrome end users exceeds the associated security, privacy, and operational risks. + + Upon receiving an Accepted determination, the entity's key material, endpoints, and associated trust metadata will be scheduled for inclusion in the CQRS and distributed to Chrome clients on an approximately quarterly targeted release cycle (though distributions are not limited to quarterly releases). However, the CQRP makes no guarantees on the timeliness of distribution. + + Acceptance does not constitute a permanent, irrevocable, or unconditional guarantee of trust. Included operators need to continuously maintain adherence to all ongoing policy obligations - including compliance monitoring metrics (uptime, cryptographic correctness, and mirror consistency) and prompt incident reporting. The CQRP reserves the right to modify, suspend, or revoke inclusion at its sole discretion if an operator fails to sustain these standards or if the risk of continued inclusion outweighs the benefit to Chrome users. + +* **Rejected**: An inclusion application is classified as "Rejected" when an entity fails to unequivocally demonstrate that the value of its inclusion to Chrome end users clearly exceeds the associated security, privacy, or operational risks. Rejection typically results from unaddressed technical, audit, or procedural deficiencies, incomplete or inaccurate disclosures, an incident reporting history that fails to reliably demonstrate the factors that are significant to the CQRP, or a failure to satisfy the minimum requirements defined within the CQRP Policy. + + An organization whose application is Rejected is typically subject to a standard 6-month cooling-off period, beginning on the date of the formal rejection determination. During this period, the organization is ineligible to submit new or revised inclusion requests to the CQRP. This cooling-off period provides the organization sufficient time to remediate identified deficiencies, demonstrate sustained operational stability, and obtain updated, compliant audit attestations prior to re-applying. + +* **Disqualified**: An entity is classified as "Disqualified" when the CQRP determines that they present an unacceptable or unmitigable risk to Chrome end users or the integrity of the web. Disqualification is reserved for, but not limited to: + * Being the subject of multiple application Rejections without demonstrating meaningful and measurable remediation; + * Intentional misrepresentation, falsification, or material omission of facts in public disclosures, audit attestations, or program communications; + * Willful non-compliance with the CQRP Policy; or + * Critical failures, key compromises, or operational practices that demonstrate an inability or unwillingness to maintain a robust "security-first" culture. + + An entity designated as Disqualified is permanently barred from applying for or receiving inclusion in the CQRS across all current and future PKI hierarchies operated, owned, or controlled by the organization, its subsidiaries, or its affiliates. From 0f90869578a654561af70835871ffc1aaadfd378 Mon Sep 17 00:00:00 2001 From: Chris Clements Date: Wed, 28 Oct 2026 13:02:54 -0400 Subject: [PATCH 06/15] Update draft-policy.md Update the draft policy to RC1. --- content/cqrp/draft-policy.md | 506 +++++++++++++++++++---------------- 1 file changed, 270 insertions(+), 236 deletions(-) diff --git a/content/cqrp/draft-policy.md b/content/cqrp/draft-policy.md index 4c5ab58..777013c 100644 --- a/content/cqrp/draft-policy.md +++ b/content/cqrp/draft-policy.md @@ -1,9 +1,9 @@ --- -title: Chrome Quantum-resistant Root Program Policy, Version 0.3.0 +title: Chrome Quantum-resistant Root Program Policy, Version 0.4.0 --- -# [DRAFT] Chrome Quantum-resistant Root Program Policy, Version 0.3.0 +# [DRAFT] Chrome Quantum-resistant Root Program Policy, Version 0.4.0 -## Last updated: 2026-08-14 +## Last updated: 2026-10-28 ## Table of Contents @@ -31,7 +31,7 @@ title: Chrome Quantum-resistant Root Program Policy, Version 0.3.0 - [2.4.3.1. MTC CA Cosigner Certificate Profile](#2431-mtc-ca-cosigner-certificate-profile) - [2.4.3.2. Subscriber TLS Server Authentication Certificate Profile](#2432-subscriber-tls-server-authentication-certificate-profile) - [2.4.3.3. CRL Profile](#2433-crl-profile) - - [2.4.4. Preissuance Linting](#244-preissuance-linting) + - [2.4.4. Linting](#244-linting) - [2.4.5. Criteria for Chrome Usability](#245-criteria-for-chrome-usability) - [2.5. MTC CA Issuance Log](#25-mtc-ca-issuance-log) - [2.5.1. Issuance Log Operations](#251-issuance-log-operations) @@ -58,18 +58,23 @@ title: Chrome Quantum-resistant Root Program Policy, Version 0.3.0 - [3.2.3. Cosigning Timeliness](#323-cosigning-timeliness) - [3.2.4. Data Retention and Log Pruning](#324-data-retention-and-log-pruning) - [3.2.5. Service Availability and Reporting](#325-service-availability-and-reporting) - - [3.2.6. Log Inconsistency Reporting](#326-log-inconsistency-reporting) + - [3.2.6. Log Consistency](#326-log-consistency) - [3.3. Mirroring Cosigner States](#33-mirroring-cosigner-states) - [3.4. Mirroring Cosigner Lifecycle and Rotation](#34-mirroring-cosigner-lifecycle-and-rotation) - [References](#references) -## Introduction +## **Introduction** -The Chrome Quantum-resistant Root Program (CQRP) establishes the minimum requirements for [Merkle Tree Certificate](https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/) [TODO: point to final/latest spec before v1.0.0 of this policy] Certification Authorities (referred to as "MTC CAs") to be trusted by default in Chrome. +The Chrome Quantum-resistant Root Program (CQRP) establishes the minimum requirements for [Merkle Tree Certificate](https://datatracker.ietf.org/doc/html/draft-ietf-plants-merkle-tree-certs-07) Certification Authorities (referred to as "MTC CAs") to be trusted by default in Chrome. -As [announced](https://security.googleblog.com/2026/02/cultivating-robust-and-efficient.html) in February 2026, Chrome will not add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store. Instead, the Chrome Quantum-resistant Root Store (CQRS) relies entirely on MTC CAs to decouple connection security strength from TLS handshake payload size while integrating transparency directly into the issuance process. +As [announced](https://security.googleblog.com/2026/02/cultivating-robust-and-efficient.html) in February 2026, Chrome will not add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store. Instead, the Chrome Quantum-resistant Root Store (CQRS) relies entirely on MTC CAs to decouple connection security strength from TLS handshake payload size while integrating transparency directly into the issuance process. -Unlike a traditional root store consisting of X.509 certificates acting as trust anchors for certificate chain validation and accompanying metadata, the CQRS encompasses both MTC CA Operators (i.e., TLS server authentication certificate issuers responsible for domain control validation and Merkle Tree generation) and Mirroring Operators (i.e., entities responsible for replicating and cosigning log views to guarantee transparency and split-view resistance). The complete list of MTC CA and Mirroring Cosigners included in the CQRS is published in [cosigners.json](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json). +This policy does not apply to or impact CAs that are not trusted by default in Chrome and only issue certificates to an enterprise organization (sometimes called "enterprise," "private," or "locally trusted" CAs used for internal resources like corporate intranet sites or applications that do not directly interact with external users of the public Internet). For private PKI use cases, Chrome [supports](https://chromestatus.com/feature/5174590524489728) traditional X.509 certificates and trust anchors using ML-DSA in TLS 1.3 as of Chrome 150. + +Unlike a traditional root store consisting of X.509 certificates acting as trust anchors for certificate chain validation and accompanying metadata, the CQRS encompasses both MTC CAs (i.e., TLS server authentication certificate issuers responsible for domain control validation and Merkle Tree generation) and Mirrors (i.e., entities responsible for replicating and cosigning log views to guarantee transparency and split-view resistance). The complete list of MTC CAs and Mirroring Cosigners included in the CQRS is published in [https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json), with keys provided in [https://www.gstatic.com/mtcs/cosigners/v1/cosigners.pem](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.pem). + +> [!NOTE] +> `cosigners.json` and `cosigners.pem` are published solely for Chrome, CQRS operators, and monitors, and may contain keys that are not unconditionally trusted by Chrome. They MUST NOT be used for MTC validation in non-Chrome TLS clients, as unauthorized reliance endangers third-party users, Chrome users, and the broader ecosystem. Google provides no SLA or stability guarantees for unauthorized users and may modify these files in any way without notice; permitted consumers should cache recent versions locally. The CQRS and corresponding policy are distinct from the existing: @@ -81,177 +86,178 @@ The CQRS and corresponding policy are distinct from the existing: Inclusion in the Chrome Root Store does not guarantee admission into the CQRS, nor is inclusion in the Chrome Root Store a prerequisite for inclusion in the CQRS. -Because this area is evolving rapidly this policy will change over time. Stakeholders can expect an emphasis on **security, simplicity, predictability, transparency,** and **resilience.** To respond effectively to emerging security risks and standards, Chrome reserves the right to modify this policy as necessary. Although Chrome intends to provide reasonable notice for policy updates, advance notice is not guaranteed. Participants in the CQRS are expected to maintain the operational agility and technical capabilities required to implement policy changes without disrupting ecosystem availability. +Because this area is evolving rapidly, this policy will change over time. Stakeholders can expect an emphasis on **security, simplicity, predictability, transparency,** and **resilience.** To respond effectively to emerging security risks and standards, Google reserves the right to modify this policy as necessary. Although Google intends to provide reasonable notice for policy updates, advance notice is not guaranteed. Participants in the CQRS are expected to maintain the operational agility and technical capabilities required to implement policy changes without disrupting ecosystem availability. Any questions regarding this policy can be directed to chrome-quantum-resistant-root-program [at] google [dot] com. -### Preparing and Applying for Inclusion +### **Preparing and Applying for Inclusion** -Organizations are welcome to apply for inclusion in the CQRS as MTC CA Operators or Independent Mirroring Operators if they meet the minimum requirements detailed in this policy and follow the submission guidelines detailed in [Preparing and Applying for Inclusion](apply.md). +Organizations are welcome to apply for inclusion in the CQRS as an MTC CA Operator if they meet the minimum requirements detailed in this policy and follow the submission guidelines detailed in [Preparing and Applying for Inclusion](https://googlechrome.github.io/chromerootprogram/cqrp/apply/). -### Chrome's Ongoing Commitment to Transport Security +### **Chrome's Ongoing Commitment to Transport Security** The CQRP is purpose-driven and designed to serve Chrome users' security needs. Its existence and this corresponding policy represent Google's [ongoing commitment](https://transparencyreport.google.com/https/overview?hl=en) to upholding secure and reliable network connections in Chrome. -In support of this commitment, Google, as it deems appropriate and at its sole discretion, includes or removes MTC Operators and Independent Mirroring Operators in the CQRS. The selection and ongoing inclusion of these operators is done to enhance the security of Chrome. Inclusion in the root store, both initially and sustained, is not guaranteed to any CQRS Applicant, MTC CA Operator, or Independent Mirroring Operator. +In support of this commitment, Google, as it deems appropriate and at its sole discretion, includes or removes MTC CA and Mirroring Cosigners in the CQRS. The selection and ongoing inclusion of these operators is done to enhance the security of Chrome. Inclusion in the root store, both initially and sustained, is not guaranteed to any CQRS Applicant or MTC CA Operator. -## Change History +## **Change History** | Version | Date | Note | | :---- | :---- | :---- | -| 0.3.0 | 2026.08.14 | Third draft release with additional feedback considered, a reorganization of sections, and new subsection headers. | +| 0.4.0 (RC 1.0.0) | 2026.10.28 | Fourth draft release with additional feedback considered and updated to align with draft-ietf-plants-merkle-tree-certs-07. This draft is considered Release Candidate (RC) Version 1.0.0. | +| 0.3.0 | 2026.08.14 | Third draft release with additional feedback considered, a reorganization of sections, and new subsection headers. | | 0.2.0 | 2026.06.17 | Second draft release with feedback considered. | | 0.1.0 | 2026.05.14 | Initial draft release for feedback. | -## Definitions +## **Definitions** The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://www.rfc-editor.org/info/bcp14) when, and only when, they appear in all capitals, as shown here. -**CQRS Applicant**: A legal entity that has an open inclusion request submitted to Google Chrome in the [Chromium Issues Tracker](https://issues.chromium.org/u/0/issues/new?component=2114629&pli=1&authuser=0&template=0) [TODO: create and link to template]. +**Note:** This policy applies BCP 14 keywords as defined above. Separately, and as a matter of program intent, the CQRP often uses SHOULD in part to phase in requirements whose immediate mandate would outpace available tooling or ecosystem maturity. -**MTC CA Operator**: A legal entity included in the CQRS that possesses or controls the private key(s) capable of issuing Subscriber certificates and generating checkpoints for the associated issuance log. All MTC CA Operators are also Mirroring Operators. +**CQRS Applicant**: A legal entity that has an open inclusion request submitted to Google Chrome in the [Chromium Issues Tracker](https://issues.chromium.org/issues/new?component=2114629&template=2386551). -**Mirroring Operator**: A legal entity included in the CQRS that maintains a synchronized copy of MTC CA issuance logs (i.e., a mirror) and possesses or controls the private key(s) capable of cosigning views of those issuance logs. +**Inconsistent Merkle Tree View (or Split-View)**: A state where an MTC CA's issuance log or a Mirroring Cosigner's view of an issuance log presents different, conflicting versions of its log history to various parties (e.g., cosigners, relying parties, or monitors). -**Independent Mirroring Operator**: A Mirroring Operator that is not also an MTC CA Operator. +**Key Sunset**: The process by which Chrome deprecates and phases out default trust in an MTC CA Cosigner Key. To safely sunset a key and prevent retroactive issuance, Chrome establishes a Key Sunset Date technically enforced in client configurations through bounded minimum and maximum certificate serial numbers and log instances. Certificates linked to inclusion proofs outside this explicitly bounded window will not be accepted by Chrome clients. This is analogous to the SCTNotAfter feature used by the Chrome Root Store to gradually phase out trust in CA key material. -**Inconsistent Merkle Tree View (or Split-View)**: A state where an MTC CA's issuance log or a Mirroring Cosigner's view of an issuance log presents different, conflicting versions of its log history to various parties (e.g., cosigners, relying parties, or monitors). +**Mirroring Operator**: A legal entity included in the CQRS that maintains a synchronized copy of MTC CA issuance logs (i.e., a mirror) and possesses or controls the private key(s) capable of cosigning views of those issuance logs. -**Key Sunset**: The process by which Chrome deprecates and phases out default trust in an MTC CA Cosigner Key. To safely sunset a key and prevent retroactive issuance, Chrome establishes a Key Sunset Date technically enforced in client configurations through bounded minimum and maximum certificate serial numbers and log instances. Certificates linked to inclusion proofs outside this explicitly bounded window will not be accepted by Chrome clients. This is analogous to the SCTNotAfter feature used by the Chrome Root Store to gradually phase-out trust in CA key material. +**MTC CA Operator**: A legal entity included in the CQRS that possesses or controls the private key(s) capable of issuing Subscriber certificates and generating checkpoints for the associated issuance log. All MTC CA Operators are also Mirroring Operators. -## 1. Participation in the Root Store +**Planned Maintenance**: A service interruption announced on the operator's public status page no less than 48 hours before it begins, and limited to the duration announced. Any other service interruption, including any portion of a maintenance window extending beyond its announced end time, is considered "unplanned." -Unless noted, the requirements in this section apply to both MTC CA Operators and Independent Mirroring Operators. +## **1. Participation in the Root Store** -### 1.1. Eligibility +### **1.1. Eligibility** -Initial eligibility for inclusion in the CQRS as an MTC CA Operator is restricted to [organizations](https://certificate.transparency.dev/logs/) responsible for operating a “[usable](https://googlechrome.github.io/CertificateTransparency/log_states.html)” Certificate Transparency (CT) Log prior to February 1, 2026. These organizations have already demonstrated the operational excellence and high-availability infrastructure required to run global security services that underpin default TLS connections in Chrome. Since MTC technology shares significant architectural similarities with CT, these operators are uniquely qualified to ensure MTCs are able to get off the ground quickly and successfully. +Initial eligibility to [apply for inclusion](https://googlechrome.github.io/chromerootprogram/cqrp/apply/) in the CQRS is restricted to [organizations](https://certificate.transparency.dev/logs/) responsible for operating a "[usable](https://googlechrome.github.io/CertificateTransparency/log_states.html)" Certificate Transparency (CT) Log prior to February 1, 2026. These organizations have already demonstrated the operational excellence and high-availability infrastructure required to run global security services that underpin default TLS connections in Chrome. Since MTC technology shares significant architectural similarities with CT, these operators are uniquely qualified to ensure MTCs are able to get off the ground quickly and successfully. > [!NOTE] -> Requirements for additional MTC CA Operators (i.e., organizations that do not satisfy the above initial eligibility restrictions) will be established in a future version of this policy. At a minimum, prospective MTC CA Operators will be expected to first demonstrate operational capability and high-availability infrastructure reliability by successfully operating as a trusted Independent Mirroring Operator in the CQRS, as defined by this policy, for a specified period prior to applying for MTC CA Operator inclusion. - -There are no such eligibility restrictions placed on Independent Mirroring Operators. +> A future update to this policy is expected to establish requirements and open applications for additional MTC CA Operators (i.e., organizations that do not satisfy the above initial eligibility restrictions). Once eligible to apply, these prospective MTC CA Operators will be required to minimally first apply as a Mirroring Operator and demonstrate operational capability and high-availability infrastructure reliability by successfully operating a trusted Mirroring Cosigner in the CQRS, as defined by this policy, for a specified period before their CA Cosigners will be considered for inclusion in the CQRS. -### 1.2. Beneficial Ownership +### **1.2. Beneficial Ownership** -During the inclusion request process, CQRS Applicants MUST provide comprehensive ownership disclosures to enable the CQRP to fully evaluate the applicant's ultimate beneficial corporate ownership, parent entities, and corporate control structure. In its public Repository (as defined within the Baseline Requirements), the operator MUST disclose: +MTC Operators and CQRS Applicants MUST provide comprehensive ownership disclosures so the CQRP can fully evaluate the entity's ultimate beneficial corporate ownership, parent entities, and corporate control structure. In its public Repository (as defined within the CA/Browser Forum "[Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates](https://cabforum.org/baseline-requirements-documents/)" (Baseline Requirements)), the operator MUST disclose: -* Legal Entity Identification: Full legal name, entity type, jurisdiction of incorporation, official corporate registration number, and registered principal business address. -* Corporate Hierarchy: Full legal name, jurisdiction, and corporate registration number of the ultimate parent entity, along with a complete listing of all intermediate parent and subsidiary entities connecting the operator to its ultimate parent. -* Beneficial Ownership: Legal name, jurisdiction of incorporation, and exact percentage of equity or voting interest for any legal entity directly or indirectly holding a 25% or greater ownership or voting control interest in the operator. -* CQRS Affiliations: An explicit listing of any other CQRS participant that shares common ownership, parent entities, or corporate control with the operator, or an explicit statement confirming that no such relationships exist. +* Legal Entity Identification: Full legal name, entity type, jurisdiction of incorporation, official corporate registration number, and registered principal business address. +* Corporate Hierarchy: Full legal name, jurisdiction, and corporate registration number of the ultimate parent entity, along with a complete listing of all intermediate parent and subsidiary entities connecting the operator to its ultimate parent. +* Beneficial Ownership: Legal name, jurisdiction of incorporation, and exact percentage of equity or voting interest for any legal entity directly or indirectly holding a 25% or greater ownership or voting control interest in the operator. -Following inclusion, operators MUST continuously maintain transparent ownership records and update its disclosure for any material changes in legal structure, ultimate corporate control, or beneficial ownership. +Operators MUST continuously maintain transparent ownership records and update their disclosure for any material changes in legal structure, ultimate corporate control, or beneficial ownership. -When ownership intends to transfer, trust in the new operator is not automatically transferred. To provide sufficient time to evaluate the security, operational, and trustworthiness implications of the new controlling entity prior to the transfer of trust, MTC CA Operators and Independent Mirroring Operators MUST, where permissible by law, notify mtcs [at] chromium [dot] org at least 30 calendar days before any impending: +When an operator intends to transfer ownership, trust in the new operator is not automatically transferred. To provide sufficient time to evaluate the security, operational, and trustworthiness implications of the new controlling entity prior to the transfer of trust, MTC CA Operators MUST, where permissible by law, notify mtcs [at] chromium [dot] org at least 30 calendar days before any impending: -* changes in ownership resulting in a transfer of effective control, or changes in operating control, +* changes in ownership resulting in a transfer of effective control, or changes in operating control, * cessations of operations, or * other change control events involving components that would materially affect the ongoing operations or perceived trustworthiness of CA Cosigner or Mirroring Cosigner Keys included in the CQRS (e.g., changes to operational location(s), etc.). Not limited to the circumstances above, the CQRP reserves the right to require re-application to the CQRS. -### 1.3. Operator Independence +### **1.3. Operator Independence** -To prevent single points of failure, every entity participating in the CQRS, whether an MTC CA Operator (and by default also a Mirroring Operator) or an Independent Mirroring Operator, MUST be completely distinct from all other operators in the CQRS. Organizational independence is maintained through transparency, continuous monitoring, and ongoing re-evaluation processes. +To prevent single points of failure, every entity participating in the CQRS MUST be completely distinct from all other operators in the CQRS. Organizational independence is maintained through transparency, continuous monitoring, and ongoing re-evaluation processes. -For the purposes of this policy, an entity is 'distinct' from another operator if and only if they are separate legal, corporate, and operational entities that share no common ownership, ultimate corporate control, parent companies, administrative access, or control over cosigner key material. +For the purposes of this policy, an entity is "distinct" from another operator if and only if they are separate legal, corporate, and operational entities that share no common ownership, ultimate corporate control, parent companies, administrative access, or control over cosigner key material. -### 1.4. Facilities and Geographic Diversity +### **1.4. Facilities and Geographic Diversity** -To provide baseline assurance of physical, environmental, and operational security, all MTC CA Operator and Mirroring Operator infrastructure SHOULD be hosted in facilities certified under ISO/IEC 27001 or an equivalent security framework, with compliance independently audited and publicly reported on at least an annual basis. +To provide baseline assurance of physical, environmental, and operational security, all MTC CA Operator infrastructure MUST (and Mirroring Operator infrastructure SHOULD) be hosted in facilities that maintain an active ISO/IEC 27001 certification, AICPA SOC 2 Type II / SOC 3 attestation, or an equivalent security framework audited at least annually by an independent third party. Operators MAY satisfy this requirement through the inherited facility certifications of their underlying cloud or colocation provider. When an operator deploys infrastructure across multiple physical locations, those locations SHOULD be distributed across diverse geographic regions (e.g., North America, Europe, Asia-Pacific) to prevent regional single points of failure. -Specific only to MTC CA Operators: +Specific only to MTC CA Operator infrastructure: -* Infrastructure responsible for Subscriber certificate issuance and landmark generation, as detailed in Section 2. (“Minimum Requirements for MTC CA Operators”), SHOULD be distributed across at least 2 distinct Regional Internet Registries. -* Because this policy strictly bounds the total number of Active CA Cosigner Keys an MTC CA Operator can maintain at any given time, as detailed in Section 2.6.2. (“CA Cosigner Key Use”), MTC CA Operators MUST strategically manage their key allowance to accommodate any current or future regional deployment needs. Additional CA Cosigner Key allowances will not be granted solely to support regional deployments or bypass key limits in Chrome. +* Components responsible for Subscriber certificate issuance and landmark generation, as detailed in Section 2. ("Minimum Requirements for MTC CA Operators"), SHOULD be distributed across at least 2 distinct Regional Internet Registries. +* Because this policy strictly bounds the total number of Active CA Cosigner Keys an MTC CA Operator can maintain at any given time, as detailed in Section 2.6.2. ("CA Cosigner Key Use"), MTC CA Operators MUST strategically manage their key allowance to accommodate any current or future regional deployment needs. Additional CA Cosigner Key allowances will not be granted solely to support regional deployments or bypass key limits in Chrome. Inclusion or usability standards will not be reduced solely to satisfy geographic diversity preferences. -## 2. Minimum Requirements for MTC CA Operators +## **2. Minimum Requirements for MTC CA Operators** -The requirements in this section only apply to MTC CA Operators. +### **2.1. Public General Availability** -### 2.1. Public General Availability +To ensure the CQRS supports the diverse needs of the web, MTC CA Operators MUST offer Subscriber certificate issuance as a service generally available to the public. An issuance service is considered generally available if it is open to any qualifying Subscriber under publicly documented criteria, and is not restricted to an operator's internal infrastructure or corporate affiliates. This requirement does not prohibit the MTC CA Operator from also offering other certificate issuance services that are not generally available to the public, provided those services do not negatively impact the availability of the CA Cosigner(s) trusted by default in Chrome. To manage risk and ensure system stability during initial deployment, upon initial inclusion in the CQRS, an MTC CA Operator MAY conduct a phased rollout for up to 60 calendar days, during which certificate issuance MAY be restricted to a controlled set of Subscribers. Following the conclusion of this period, the MTC CA Operator MUST transition the service to full public general availability. -To ensure the CQRS supports the diverse needs of the web, MTC CA Operators MUST offer Subscriber certificate issuance as a service generally available to the public. This requirement does not prohibit the MTC CA Operator from also offering other certificate issuance services that are not generally available to the public, provided those services do not negatively impact the availability of the CA Cosigner(s) trusted by default in Chrome. To manage risk and ensure system stability during initial deployment, upon initial inclusion in the CQRS, an MTC CA Operator MAY conduct a phased rollout for up to 60 calendar days, during which certificate issuance MAY be restricted to a controlled set of Subscribers. Following the conclusion of this period, the MTC CA Operator MUST transition the service to full public general availability. +To ensure that inclusion in the CQRS provides equitable public value, MTC CA Operators MUST NOT condition the acceptance of a certificate request or the issuance of a certificate on the Subscriber’s use of other services, products, or platforms offered by the MTC CA Operator or its affiliates (e.g., hosting or CDN services). This requirement does not prohibit the MTC CA Operator from requiring the use of its own platform or account management services for the purpose of authentication, quota management, or abuse prevention, provided these access mechanisms are made generally available to the public. -To ensure that inclusion in the CQRS provides equitable public value, MTC CA Operators MUST NOT condition the acceptance of a certificate request or the issuance of a certificate on the Subscriber’s use of other services, products, or platforms offered by the MTC CA Operator or any affiliated entity. This requirement does not prohibit the MTC CA Operator from requiring the use of its own platform or account management services for the purpose of authentication, quota management, or abuse prevention, provided these access mechanisms are made generally available to the public. - -#### 2.1.1. Disclosures Manifest +#### **2.1.1. Disclosures Manifest** MTC CA Operators MUST create, publish, and continuously maintain an [mtc-disclosures.json](https://github.com/GoogleChrome/chromerootprogram/blob/main/content/cqrp/disclosures/mtc-disclosures.schema.json) ([example](https://github.com/GoogleChrome/chromerootprogram/blob/main/content/cqrp/disclosures/mtc-disclosures.json)). The manifest MUST: -* be hosted at a publicly accessible URL within the operator’s public Repository; -* conform to the latest version of the MTC Disclosures schema; -* accurately specify all mandatory global disclosure URLs (including the operator’s public Repository, legal entity and beneficial ownership disclosures, operational status page, and facility security certifications); -* accurately specify all key-specific disclosure URLs for each CA Cosigner Key included in the CQRS; and +* be hosted at a publicly accessible URL within the operator’s public Repository; +* conform to the latest version of the MTC Disclosures schema within 14 days of the publication thereof; +* accurately specify all mandatory global disclosure URLs (including the operator’s public Repository, legal entity and beneficial ownership disclosures, operational status page, and facility security certifications); +* accurately specify all key-specific disclosure URLs for each CA Cosigner Key included in the CQRS; and * be updated within 14 calendar days of any material change to any contained URL or disclosure metadata. -### 2.2. Service Uptime and Maintenance Notifications - -The MTC CA Operator SHOULD maintain continuous availability of its Subscriber certificate issuance services. As the ecosystem relies on automated renewal of certificates, and prolonged downtime risks widespread TLS breakage for website operators, the MTC CA Operator MUST NOT experience any single, unplanned service outage exceeding 24 consecutive hours, during which certificate issuance and management is unavailable to Subscribers through any of the operator’s endpoints. Any planned scheduled maintenance that will interrupt these services MUST be publicly announced before the maintenance begins, minimally on the MTC CA Operator’s public status page (described below). To provide Subscribers with sufficient time to pre-renew certificates and adjust automation schedules, this announcement SHOULD be published no less than 48 hours before the outage begins. +### **2.2. Service Uptime and Maintenance Notifications** -MTC CA Operators MUST maintain a freely accessible, public status page that reports real-time operational health and availability for all MTC services. To ensure availability during primary system outages, the status page SHOULD be hosted on infrastructure operationally independent of the CA’s primary issuance endpoints. +The MTC CA Operator SHOULD maintain continuous availability of its Subscriber certificate issuance services. As the ecosystem relies on automated renewal of certificates, and prolonged downtime risks widespread TLS breakage for website operators, the MTC CA Operator MUST NOT experience any single, unplanned service outage exceeding 24 consecutive hours, during which certificate issuance and management is unavailable to Subscribers through any of the operator’s endpoints. All Planned Maintenance MUST be publicly announced, minimally on the MTC CA Operator's public status page (described below). -The status page MUST: +MTC CA Operators MUST maintain a freely accessible, public status page that reports the current operational health and availability for all MTC services. The status page SHOULD: -* display real-time operational status for each primary service component, including Subscriber certificate issuance endpoints (i.e., ACME API), issuance log operations, and landmark generation services; -* provide real-time status updates, root-cause summaries, and estimated resolution timelines during active service degradations, API error spikes, or outages; and -* maintain a publicly viewable archive of all past service incidents and maintenance events for a minimum of 12 months. +* be hosted on infrastructure operationally independent of the CA’s primary issuance endpoints to ensure availability during primary system outages; +* display the current operational status (e.g., normal/within SLA, degraded performance, service disruption, scheduled maintenance) for each primary service component - including Subscriber certificate issuance endpoints (i.e., ACME API), Domain Control Validation (DCV) services, ACME Renewal Information (ARI) endpoints, issuance log operations, landmark generation services, CRL distribution endpoints (if applicable), and Mirroring Cosigner endpoints - updated promptly upon detecting any change in service availability or performance; +* provide timely status updates throughout active service degradations or disruptions, detailing affected components, operational impact, and estimated resolution timelines as substantive information becomes available, followed by a post-incident root-cause summary (or a direct link to the corresponding public incident report required under Section 2.7.3.1. ("Incident Reports")); and +* maintain a publicly viewable archive of all past service incidents and maintenance events for a minimum of 365 days. -### 2.3. PKI Policy Governance +### **2.3. PKI Policy Governance** -#### 2.3.1. CA/Browser Forum TLS Server Authentication Baseline Requirements +#### **2.3.1. CA/Browser Forum TLS Server Authentication Baseline Requirements** -MTC CA Operators that issue TLS server authentication Subscriber certificates trusted in Chrome by default MUST adhere to the latest version of the CA/Browser Forum "Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates" ([Baseline Requirements](https://cabforum.org/working-groups/server/baseline-requirements/requirements/)), except as described in the remainder of this policy. Because MTCs fundamentally differ from traditional X.509 certificates, this policy modifies, strengthens, limits, or exempts MTC CAs from certain Baseline Requirements. In the event of any conflict or incompatibility between the Baseline Requirements and this policy, the requirements of this policy SHALL take precedence. +MTC CA Operators that issue TLS server authentication Subscriber certificates trusted in Chrome by default MUST adhere to the latest version of the Baseline Requirements, except as described in the remainder of this policy. Because MTCs fundamentally differ from traditional X.509 certificates, this policy modifies, strengthens, limits, or exempts MTC CAs from certain Baseline Requirements. In the event of any conflict or incompatibility between the Baseline Requirements and this policy, the requirements of this policy SHALL take precedence. -#### 2.3.2. MTC CA Operator Policies +#### **2.3.2. MTC CA Operator Policies** MTC CA Operators MUST accurately describe the policies and practices of their MTC CA(s) within a combined CP/CPS that is: -* freely publicly available for examination; -* available in an authoritative English language version; -* available in Markdown (i.e., .md) or AsciiDoc (i.e., .adoc) and hosted in a public Repository where all historical versions are maintained and accessible; -* authoritative for all CA Cosigner Keys included in the CQRS; -* focused only on the specific PKI use case of issuing TLS server authentication MTCs to websites; -* explicitly states adherence to the latest published version of this policy in its Section 1.1; +* freely publicly available for examination; +* available in an authoritative English language version; +* available in Markdown (i.e., .md) or AsciiDoc (i.e., .adoc) and hosted in a public Repository where all historical versions are maintained and accessible (e.g., preserved as discrete versioned documents, or accessible via immutable release tags corresponding to each version identified in the document's change history); +* authoritative for all CA Cosigner Keys included in the CQRS; +* focused only on the specific PKI use case of issuing TLS server authentication MTCs to websites; * sufficiently detailed to assess the operations of the CA(s) and compliance with these expectations and the Baseline Requirements, and MUST NOT conflict with either of these requirements, except for the Baseline Requirements modifications permitted by this CQRP Policy. -The combined CP/CPS SHOULD be structured in accordance with [RFC 3647](https://datatracker.ietf.org/doc/html/rfc3647). For every applicable requirement in the CQRP Policy and Baseline Requirements, the combined CP/CPS MUST: +In Section 1.1 of the combined CP/CPS, the MTC CA Operator MUST explicitly state adherence to the latest published version of this policy, as well as adherence to the Baseline Requirements as modified, limited, or exempted by this policy. The MTC CA Operator is exempt from the requirement in Baseline Requirements Section 2.2 to state that the Baseline Requirements take precedence over the CP/CPS; the statement MUST instead confirm that the in-force CQRP policy takes precedence over the Baseline Requirements in the event of any conflict or inconsistency. The MTC CA Operator MAY fulfill this requirement by using a clause such as the following: + +\[!NOTE] "[Name of MTC CA Operator] conforms to the current version of the Chrome Quantum-resistant Root Program (CQRP) Policy and the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates as modified by the CQRP Policy. In the event of any inconsistency between the Baseline Requirements and the CQRP Policy, the CQRP Policy takes precedence." + +The combined CP/CPS SHOULD be structured in accordance with [RFC 3647](https://www.rfc-editor.org/info/rfc3647). For every applicable requirement in the CQRP Policy and Baseline Requirements, the combined CP/CPS MUST: * Contain sufficient CA-specific detail to allow a technically competent reviewer to understand how the operator implements applicable controls. To satisfy this requirement, where underlying specifications (such as the Baseline Requirements) permit operational variation or optionality, the combined CP/CPS MUST explicitly state the chosen method, parameter, constraint, or implementation mechanism used by the CA (e.g., detailing the exact Domain Control Validation sub-methods utilized, rather than citing the section generally). * Describe the operator's current implementation commitments, including relevant operational parameters, constraints, and design choices. These SHOULD be explicit, bounded, and testable, particularly where applicable requirements permit discretion or variation. * Be self-contained, ensuring that any referenced external documents or specifications are publicly accessible and directly hyperlinked so that conformance can be evaluated without requiring excessive interpretive reconstruction across unlinked or undisclosed secondary documents. -MTC CA Operators MUST include in Section 1.1 or 2.2 of their combined CP/CPS a structured table chronologically disclosing all CA Cosigner Keys and corresponding certificate subjects governed by the policy. For each key, the disclosure MUST specify: +MTC CA Operators MUST include in Section 1.1 of their combined CP/CPS a structured table chronologically disclosing all CA Cosigner Keys and corresponding certificate subjects governed by the policy. For each key, the disclosure MUST specify: * The full Certificate Subject Distinguished Name (if a corresponding certificate exists); * The SHA-256 fingerprint of the SubjectPublicKeyInfo (Key ID); * The cryptographic algorithm and parameter set (e.g., ML-DSA-44); and * The key generation date and reference to the corresponding Key Generation Ceremony Report. -MTC CA Operators MUST publish exhaustive certificate profiles adhering to the profiles specified in Section 2.4.3. (“Certificate and CRL Profiles”) of this policy. Specifically: +MTC CA Operators MUST publish exhaustive certificate profiles adhering to the profiles specified in Section 2.4.3. ("Certificate and CRL Profiles") of this policy. Specifically: + +* The MTC CA Operator MUST publish in its Repository a separate certificate profile corresponding to each Reserved Certificate Policy Identifier (as defined within the Baseline Requirements) that might appear in Subscriber Certificates issued by MTC CAs it operates. The MTC CA Operator SHOULD generate and maintain these profiles via automated export or continuous synchronization from the active configuration of its issuance systems. +* Each profile MUST exhaustively enumerate every field and extension the MTC CA is capable of including in a Subscriber certificate issued under that Reserved Certificate Policy Identifier. For each field and extension, the profile MUST explicitly specify presence (always, never, or optional), criticality, permitted values, permitted encodings, and, where applicable, permitted ordering and cardinality. +* Any field or extension not explicitly enumerated and specified in the applicable certificate profile MUST NOT be present in Subscriber certificates issued under that profile. +* The effective date of a certificate profile MUST NOT precede the date on which it was published in the MTC CA Operator’s Repository. +* The MTC CA Operator MUST retain and continue to publish each superseded profile, together with its effective date range, until all remaining Subscriber certificates relying upon it have expired. Superseded profiles MUST remain directly retrievable as discrete artifacts or endpoints in the Repository (relying solely on Git commit history is not sufficient). -* For each MTC CA capable of issuing Subscriber certificates, the MTC CA Operator MUST publish a machine-readable certificate profile in its Repository corresponding to each Reserved Certificate Policy Identifier that might appear in Subscriber certificates. The MTC CA Operator SHOULD generate and maintain these machine-readable profiles via automated export or continuous synchronization from the active configuration of its issuance systems. -* Each profile MUST exhaustively enumerate every field and extension the MTC CA is capable of including in a Subscriber certificate issued under that Reserved Certificate Policy Identifier. For each field and extension, the profile MUST explicitly specify required presence (MUST, MAY, or MUST NOT), criticality, permitted values, permitted encodings, and, where applicable, permitted ordering and cardinality. -* Any field or extension not explicitly enumerated and specified in the applicable machine-readable certificate profile MUST NOT be present in Subscriber certificates issued under that profile. -* The effective date of a machine-readable certificate profile MUST NOT precede the date on which it was published in the MTC CA Operator’s Repository. -* The MTC CA Operator MUST retain and continue to publish each superseded profile, together with its effective date range, until all remaining Subscriber certificates relying upon it have expired. +> [!NOTE] +> To prevent drift between documented and enforced configurations, a future update to this policy is expected to require structured certificate profiles exported directly from the MTC CA's issuance system. -Because a CP/CPS is considered a binding operational commitment it needs to provide meaningful transparency into how the CA practically operates, rather than just acknowledging the rules it must follow, a CP/CPS MUST NOT simply copy, paraphrase, or restate the requirements as a substitute for describing the CA's actual implementation. +Because a CP/CPS is considered a binding operational commitment, it needs to provide meaningful transparency into how the CA practically operates, rather than just acknowledging the rules it must follow. A CP/CPS MUST NOT simply copy, paraphrase, or restate the requirements as a substitute for describing the CA's actual implementation. The requirements in this section do not prohibit MTC CA Operators from maintaining additional policy documents, which may also be considered authoritative by other stakeholders. However, the consolidated policy document made available to the CQRP MUST NOT conflict with any additional policy documents that might exist for the corresponding PKI. -### 2.4. Certificate Issuance Lifecycle and Profiles +### **2.4. Certificate Issuance Lifecycle and Profiles** -For the purpose of this policy, MTC Subscriber certificate issuance occurs when the CA Cosigner private key is applied to sign an issuance log checkpoint that incorporates the corresponding `TBSCertificateLogEntry` into the Merkle Tree. +For the purpose of this policy and the expectations of the Baseline Requirements, MTC Subscriber certificate issuance (including the "certificate signing operation") occurs when the CA Cosigner private key is first applied to sign an issuance log checkpoint that incorporates the corresponding `TBSCertificateLogEntry` into the Merkle Tree. MTC CA Operators MUST provide both Standalone and Landmark-relative certificates. -#### 2.4.1. Domain Control Validation +#### **2.4.1. Domain Control Validation** -MTC CA Operators MUST validate domain control in accordance with Section 3.2.2.4 (“Validation of Domain Value”) and Section 3.2.2.5 (“Authentication of IP Address”) of the Baseline Requirements, subject to the following modifications: +MTC CA Operators MUST validate domain control in accordance with Section 3.2.2.4 ("Validation of Domain Authorization or Control") and Section 3.2.2.5 ("Authentication for an IP Address") of the Baseline Requirements, subject to the following modifications: The following domain control validation methods are being deprecated in the Baseline Requirements and MUST NOT ever be relied upon: @@ -267,34 +273,37 @@ The following domain control validation methods are being deprecated in the Base Domain control validation data reuse MUST be limited to a maximum of 10 days. -#### 2.4.2. Automation Support +#### **2.4.2. Automation Support** + +To enable reliable, rapid issuance and renewal without manual intervention, Subscriber certificates MUST be able to be issued and retrieved using an ACME-based service. The ACME service SHOULD conform to [RFC 8555](https://www.rfc-editor.org/info/rfc8555) and interoperate with standard ACME clients without requiring custom client-side software modifications for account registration, domain authorization, order processing, certificate issuance and management, and retrieval workflows. Any divergences from RFC 8555 MUST be documented in Section 4.1.2 of the combined CP/CPS. -To enable reliable, rapid issuance and renewal without manual intervention, Subscriber certificates MUST be able to be issued and retrieved using an ACME-based service. The ACME service MUST conform to [RFC 8555](https://datatracker.ietf.org/doc/html/rfc8555) and interoperate with standard ACME clients without requiring custom client-side software modifications for account registration, domain authorization, order processing, certificate issuance and management, and retrieval workflows. Any divergences from RFC 8555 MUST be documented in the combined CP/CPS. +The MTC CA MUST support ACME Renewal Information (ARI) ([RFC 9773](https://www.rfc-editor.org/info/rfc9773)) and use it as a mechanism by which Subscribers can be signaled to renew certificates in advance of scheduled expiry or in response to a revocation event. ARI adoption and client responsiveness are essential to ecosystem resilience and agility. -The MTC CA MUST support ACME Renewal Information (ARI) ([RFC 9773](https://datatracker.ietf.org/doc/rfc9773/)) and use it as a mechanism by which Subscribers can be signaled to renew certificates in advance of scheduled expiry or in response to a revocation event. ARI adoption and client responsiveness are essential to ecosystem resilience and agility. +To evaluate whether Subscriber ACME clients reliably poll and act upon ARI signals, MTC CAs issuing Subscriber certificates with validity periods exceeding 7 days SHOULD conduct operational ARI testing. -No less than quarterly, MTC CAs issuing Subscriber certificates with validity periods exceeding 7 days MUST perform operational ARI testing to evaluate whether Subscriber ACME clients reliably poll and act upon ARI signals. +When conducting operational ARI testing: -Specific to this operational ARI testing: +* No less than quarterly, the MTC CA Operator SHOULD randomly select a sample of no fewer than the lesser of (1) 3.0% of its time-valid Subscriber certificates with validity periods exceeding 7 days, or (2) 100,000 such certificates. +* For each sampled certificate, the MTC CA Operator SHOULD publish a modified ARI renewal window recommending an accelerated renewal timeline that begins within 24 hours of sample selection and spans no more than 72 hours in total duration. +* Within 14 calendar days of completing each operational ARI test cycle, the MTC CA Operator SHOULD publish [{test_cycle_id}-ari-operational-test-report.json](https://github.com/GoogleChrome/chromerootprogram/blob/main/content/cqrp/disclosures/ari-operational-test-report.schema.json) ([example](https://github.com/GoogleChrome/chromerootprogram/blob/main/content/cqrp/disclosures/ari-operational-test-report.json)) in a publicly disclosed location. +* Public reports SHOULD contain aggregated summary metrics (such as total certificates sampled, overall renewal pass rates within the window, and aggregated renewal latency percentiles). +* MTC CA Operators SHOULD contact Subscribers whose ACME clients failed to renew sampled certificates to identify technical or operational obstacles to ARI adoption. +* MTC CA Operators SHOULD aggregate identified adoption challenges and communicate them to mtcs [at] chromium [dot] org. +* All historical ARI testing reports SHOULD be preserved and made publicly accessible at that publicly disclosed location. +* It is NOT RECOMMENDED that MTC CA Operators revoke sampled certificates unless explicitly requested by the Subscriber. -* The MTC CA Operator MUST select a random sample comprising no less than 3% of its time-valid and unrevoked Subscriber certificates whose validity exceeds 7 days and whose `notBefore` timestamp is within the last 336 hours. -* For each sampled certificate, the MTC CA Operator MUST publish a modified ARI renewal window recommending an accelerated renewal timeline that begins within 24 hours of sample selection and spans no more than 72 hours in total duration. -* Within 14 calendar days of completing each operational ARI test cycle, the MTC CA Operator MUST publish [{test_cycle_id}-ari-operational-test-report.json](https://github.com/GoogleChrome/chromerootprogram/blob/main/content/cqrp/disclosures/ari-operational-test-report.schema.json) ([example](https://github.com/GoogleChrome/chromerootprogram/blob/main/content/cqrp/disclosures/ari-operational-test-report.json)) in its Repository. -* If the MTC CA Operator maintains Subscriber contact information (such as through External Account Binding (EAB) associations or email addresses provided during ACME account registration), the MTC CA Operator SHOULD contact Subscribers whose ACME clients failed to renew sampled certificates during operational ARI testing. - * This outreach SHOULD inform the Subscriber of the test outcome, outline the security and resilience benefits of ARI, and seek to identify technical or operational challenges to successful ARI adoption. - * MTC CA Operators SHOULD aggregate these identified challenges and communicate them to chrome-quantum-resistant-root-program [at] google [dot] com before the next operational ARI testing is performed. -* All historical ARI testing reports MUST be preserved and made publicly accessible in the operator’s Repository. -* It is NOT RECOMMENDED that MTC CA Operators revoke sampled certificates unless explicitly requested by the Subscriber. +> [!NOTE] +> A future update to this policy is expected to require periodic operational ARI testing and public reporting. -The MTC CA MUST also support the ACME Profiles Extension ([draft-ietf-acme-profiles](https://datatracker.ietf.org/doc/draft-ietf-acme-profiles/)) and use it as a mechanism to allow ACME clients to dynamically discover and select among different certificate lifetimes and formats (such as short-lived versus longer validity and Standalone versus Landmark-relative) over a single, unified ACME endpoint without requiring custom client modifications. +The MTC CA SHOULD also support the ACME Profiles Extension ([draft-ietf-acme-profiles](https://datatracker.ietf.org/doc/draft-ietf-acme-profiles/)) and use it as a mechanism to allow ACME clients to dynamically discover and select among different certificate profiles offered by the CA. -#### 2.4.3. Certificate and CRL Profiles +#### **2.4.3. Certificate and CRL Profiles** The subsections below detail the profile requirements for MTC CA Cosigner Certificates, Subscriber TLS Certificates, and CRLs. -##### 2.4.3.1. MTC CA Cosigner Certificate Profile +##### **2.4.3.1. MTC CA Cosigner Certificate Profile** -MTC CA Cosigner Certificates MUST conform to the MTC CA Certificate Profile defined in the MTC [specification](https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/) [TODO: point to final/latest spec before v1.0.0 of this policy] and the mtc-tlog [specification](https://github.com/C2SP/C2SP/blob/main/mtc-tlog.md) [TODO: point to final/latest spec before v1.0.0 of this policy]. MTC CA Operators are exempt from the signature algorithm and key size restrictions specified in Section 6.1.5 ("Key Sizes and Algorithms") and Section 7.1.3 ("Algorithm Identifiers") of the Baseline Requirements when using the ML-DSA ([RFC 9881](https://www.rfc-editor.org/rfc/rfc9881.html)) keys permitted by this policy. +MTC CA Cosigner Certificates MUST conform to the MTC CA Certificate Profile defined in the MTC [specification](https://datatracker.ietf.org/doc/html/draft-ietf-plants-merkle-tree-certs-07) and the mtc-tlog [specification](https://c2sp.org/mtc-tlog@v0.1.0). MTC CA Operators are exempt from the signature algorithm and key size restrictions specified in Section 6.1.5 ("Key Sizes and Algorithms") and Section 7.1.3 ("Algorithm Identifiers") of the Baseline Requirements when using the ML-DSA ([RFC 9881](https://www.rfc-editor.org/info/rfc9881)) keys permitted by this policy. In addition to the above listed specifications, these certificates MUST adhere to the following cryptographic constraints: @@ -325,18 +334,15 @@ In addition to the above listed specifications, these certificates MUST adhere t | Extension | Presence | Critical | Description | | :---- | :---- | :---- | :---- | -| `keyUsage` | MUST | YES | MUST be defined in accordance with the MTC [specification](https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/) [TODO: point to final/latest spec before v1.0.0 of this policy].

Additionally, if the CA Cosigner key issues Subscriber certificates with greater than 7-day validity, `cRLSign` MUST also be present. | - -> [!NOTE] -> MTC CA Cosigner Certificates are expected to use the final OID for the `id-pe-mtcCertificationAuthority` extension once defined in the MTC [specification](https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/) [TODO: point to final/latest spec before v1.0.0 of this policy]. +| `keyUsage` | MUST | YES | MUST be defined in accordance with the MTC [specification](https://datatracker.ietf.org/doc/html/draft-ietf-plants-merkle-tree-certs-07). `cRLSign` MUST also be present. | -##### 2.4.3.2. Subscriber TLS Server Authentication Certificate Profile +##### **2.4.3.2. Subscriber TLS Server Authentication Certificate Profile** -MTC CA Operators MUST provide Subscriber certificates in the Standalone and Landmark-relative formats, both derived from the same underlying `TBSCertificateLogEntry` and defined in the MTC [specification](https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/) [TODO: point to final/latest spec before v1.0.0 of this policy]. +MTC CA Operators MUST provide Subscriber certificates in the Standalone and Landmark-relative formats, both derived from the same underlying `TBSCertificateLogEntry` and defined in the MTC [specification](https://datatracker.ietf.org/doc/html/draft-ietf-plants-merkle-tree-certs-07). For the purposes of this profile, MTC CA Operators are exempt from the serial number CSPRNG entropy requirements specified in Section 7.1.2.1 ("Serial Number") of the Baseline Requirements. -Except as modified above or where specified in the tables below, Subscriber certificates MUST comply with all requirements of the the "Subscriber (Server) Certificate Profile" defined in the Baseline Requirements: +Except as modified above or where specified in the tables below, Subscriber certificates MUST comply with all requirements of the "Subscriber (Server) Certificate Profile" defined in the Baseline Requirements: @@ -349,7 +355,7 @@ Except as modified above or where specified in the tables below, Subscriber cert + + + +
serialNumber -

MUST be defined in accordance with the MTC specification [TODO: point to final/latest spec before v1.0.0 of this policy].

+

MUST be defined in accordance with the MTC specification.

In addition to the algorithms and key sizes permitted by the Baseline Requirements, MTC CA Operators MAY issue Subscriber certificates using ML-DSA keys. When an ML-DSA key is used, the CA MUST indicate the algorithm using one of the following identifiers:

  • ML-DSA-44 (OID: 2.16.840.1.101.3.4.3.17), or
    • @@ -378,84 +384,100 @@ Except as modified above or where specified in the tables below, Subscriber cert
subject MUST be empty if certificatePolicies asserts {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) domain-validated(1)} (2.23.140.1.2.1) as defined in the Baseline Requirements.
validity +

notBefore: MUST be a time no more than 24 hours prior to, and no later than, the CA Cosigner signing operation that first incorporates the corresponding TBSCertificateLogEntry into an issuance log checkpoint.

+

notAfter: When evaluated against the notBefore date as defined in RFC 5280, the difference between notBefore and notAfter MUST be equal to or less than the maximum validity period authorized for the issuing CA Cosigner (i.e., either 7 days or 47 days depending on the key constraints in Section 2.6.2. (“CA Cosigner Key Use”)).

+
| Extension | Presence | Critical | Description | | :---- | :---- | :---- | :---- | | `certificatePolicies` | MUST | NO | MUST include the `policyIdentifier` field and SHOULD only assert `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) domain-validated(1)} (2.23.140.1.2.1)` as defined in the Baseline Requirements. Other Reserved Certificate Policy Identifiers from the Baseline Requirements MAY be asserted instead. | +| `keyUsage` | MUST | YES | MUST only assert `digitalSignature`. | | `extKeyUsage` | MUST | NO | MUST only include `id-kp-serverAuth` (OID: `1.3.6.1.5.5.7.3.1`). | | `issuerAlternativeName` | MAY | NO | MAY include an arbitrary cosmetic name (e.g., for the commercial entity the Subscriber engaged to cause the issuance of the certificate). If included, this cosmetic name MUST be encoded as a `directoryName` within the `GeneralNames` structure, and SHOULD be represented using the `organizationName` (O) and/or `commonName` (CN) attributes. Other `GeneralName` types MUST NOT be used for this cosmetic purpose. | | Signed Certificate Timestamp List | MUST NOT | - | - | -##### 2.4.3.3. CRL Profile +##### **2.4.3.3. CRL Profile** MTC CA Operators are exempt from the signature algorithm and encoding restrictions specified in Section 7.1.3.2 ("Signature AlgorithmIdentifier") of the Baseline Requirements when signing CRLs. Instead, CRLs MUST be signed using an Active CA Cosigner Key in accordance with Section 2.6.2. ("CA Cosigner Key Use") of this policy. -#### 2.4.4. Preissuance Linting +#### **2.4.4. Linting** + +For the purposes of Section 4.3.1.2 ("Pre-Issuance Linting") of the Baseline Requirements, MTC CA Operators SHOULD perform pre-issuance linting on `TBSCertificateLogEntry` structures prior to issuance log entry inclusion. This pre-issuance linting SHOULD block Subscriber certificate issuance (i.e., prevent a `TBSCertificateLogEntry` from being added to the MTC CA’s issuance log) for any certificate that does not conform to the applicable certificate profile in effect at the time of issuance. -For the purposes of Section 4.3.1.2 ("Pre-Issuance Linting") of the Baseline Requirements, MTC CA Operators SHOULD perform pre-issuance linting on `TBSCertificateLogEntry` structures prior to issuance log entry inclusion. As open-source and industry linting tools add support for MTC formats, MTC CA Operators SHOULD integrate newly released MTC linter rules into their pre-issuance pipelines within 60 calendar days of their public release. +MTC CA Operators SHOULD perform post-issuance linting on Standalone certificates prior to Subscriber delivery. -Effective September 15, 2027: +MTC CA Operators SHOULD publish a public mapping in their Repository that identifies, for each requirement expressed in a certificate profile defined in their CP/CPS (see Section 2.3.2. ("MTC CA Operator Policies")), the corresponding checks performed by their pre-issuance linting workflow(s) or issuance system controls. Where a profile requirement is not evaluated by linting, the CA SHOULD explicitly identify whether the requirement is enforced by construction within its underlying issuance system architecture, or identify it as unenforced. -* Pre-issuance linting MUST block Subscriber certificate issuance (i.e., prevent a `TBSCertificateLogEntry` from being added to the MTC CA’s issuance log) for any certificate that does not conform to the applicable machine-readable certificate profile in effect at the time of issuance. -* MTC CA Operators MUST publish a public mapping in their Repository that identifies, for each requirement expressed in a machine-readable certificate profile defined in their CP/CPS (see Section 2.3.2. (“MTC CA Operator Policies”)), the corresponding checks performed by their pre-issuance linting workflow(s). Where a profile requirement is not enforced by pre-issuance linting, the CA MUST explicitly identify it as unenforced. +As open-source and industry linting tools add support for MTC formats, MTC CA Operators SHOULD integrate newly released MTC linter rules into their pre-issuance pipelines within 60 calendar days of their public release. -#### 2.4.5. Criteria for Chrome Usability +> [!NOTE] +> A future update to this policy is expected to require automated pre-issuance linting against the MTC CA Operator's published certificate profiles. + +When an MTC CA Operator becomes aware of a flawed private key generation method, or a demonstrated method or vulnerability that exposes a Subscriber's Private Key to compromise, the operator SHOULD update its pre-issuance validation systems to prevent future certificate issuance using keys generated by that method. MTC CA Operators are exempt from the requirement in Section 4.9.1.1 of the Baseline Requirements to scan extant public keys or revoke extant Subscriber certificates as a result of that discovery, and MAY rely on pre-issuance blocking and the natural expiration of extant certificates. + +#### **2.4.5. Criteria for Chrome Usability** -To guarantee that the certificate's issuance log inclusion has been independently witnessed and to protect Chrome clients from localized log tampering or split-views created by the MTC CA, Subscriber certificates MUST meet the following cosignature minimums to be usable in Chrome: +To guarantee that a certificate's inclusion in an issuance log has been independently witnessed and to protect Chrome clients against log tampering or split-views created by an MTC CA, Subscriber certificates MUST meet the following criteria to be trusted by Chrome: -* Standalone certificates MUST have at least 2 cosignatures. One of these MUST be from the MTC CA Operator, and one MUST be from a Mirroring Cosigner recognized by Chrome and not operated by the MTC CA Operator. -* In order for landmarks to be served by Chrome's Landmark Service, all checkpoints MUST be served with a minimum of 2 cosignatures. One of these MUST be from the MTC CA Operator and one MUST be from a Mirroring Cosigner recognized by Chrome and not operated by the MTC CA Operator. +* Standalone certificates MUST include an MTCProof containing at least 2 valid subtree signatures over the covering subtree. One of these MUST be from the MTC CA Operator's CA Cosigner, and one MUST be from a Mirroring Cosigner recognized by Chrome as `Usable` (or `Frozen`, if the cosignature was generated prior to the freeze point) and not operated by or affiliated with the MTC CA Operator. +* Landmark-relative certificates are only trusted by Chrome if the corresponding landmark is verified and its subtrees are published as trusted subtrees by Chrome’s Landmark Service. Chrome’s Landmark Service will only publish trusted subtrees for a landmark when the MTC CA has published a valid signed checkpoint for the corresponding issuance log at a tree size equal to or greater than that of the landmark; and at least one Mirroring Cosigner recognized by Chrome and not operated by or affiliated with the MTC CA Operator has published or cosigned a valid signed checkpoint for the corresponding issuance log at a tree size equal to or greater than that of the landmark. -### 2.5. MTC CA Issuance Log +MTC CAs are not required to delay the publication of their own signed checkpoints at the issuance log's primary checkpoint endpoint while awaiting Mirror cosignatures. -#### 2.5.1. Issuance Log Operations +### **2.5. MTC CA Issuance Log** -##### 2.5.1.1. Technical Specifications +#### **2.5.1. Issuance Log Operations** -The MTC CA Operator MUST operate an issuance log that cryptographically binds all issued Subscriber certificates into a verifiable Merkle Tree and MUST be made publicly available in accordance with the mtc-tlog [specification](https://github.com/C2SP/C2SP/blob/main/mtc-tlog.md) [TODO: point to final/latest spec before v1.0.0 of this policy]. +##### **2.5.1.1. Technical Specifications** -To guarantee interoperability between MTC CAs, mirrors, monitors, and ACME clients across the ecosystem, the issuance log MUST strictly implement the API endpoints, cryptographic formats, and Merkle Tree structures defined in the MTC [specification](https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/) [TODO: point to final/latest spec before v1.0.0 of this policy] and the tlog-tiles [specification](https://github.com/C2SP/C2SP/blob/main/tlog-tiles.md) [TODO: point to final/latest spec before v1.0.0 of this policy]. +The MTC CA Operator MUST operate an issuance log that cryptographically binds all issued Subscriber certificates into a verifiable Merkle Tree and that MUST be made publicly available in accordance with the mtc-tlog [specification](https://c2sp.org/mtc-tlog@v0.1.0). -##### 2.5.1.2. Issuance Log Mirroring and Continuity +To guarantee interoperability between MTC CAs, mirrors, monitors, and ACME clients across the ecosystem, the issuance log MUST strictly implement the API endpoints, cryptographic formats, and Merkle Tree structures defined in the MTC [specification](https://datatracker.ietf.org/doc/html/draft-ietf-plants-merkle-tree-certs-07) and the tlog-tiles [specification](https://c2sp.org/tlog-tiles@v1.0.0). -To ensure Subscriber certificate information is widely available, MTC CA Operators MUST attempt to submit all issuance log updates to all Chrome-recognized Mirroring Cosigners in `Candidate`, `Qualified`, and `Usable` states described in Section 3.3. (“Mirroring Cosigner States”). Chrome will monitor to ensure that mirror checkpoints remain synchronized with the current issuer checkpoint in accordance with the 5-minute timeliness SLA defined in Section 3.2.3. (“Cosigning Timeliness”). +##### **2.5.1.2. Issuance Log Mirroring and Continuity** -To prevent log fragmentation and ensure consistent oversight, MTC CA Operators MUST issue Subscriber certificates to only one issuance log at a time per Active CA Cosigner Key. If an issuance log becomes inoperable, the MTC CA Operator MAY rotate to a new issuance log to maintain issuance availability. Every rotation to a new issuance log for the same Active CA Cosigner Key MUST be publicly reported as an incident, as specified in Section 2.7.3. (“Public Reporting on Incidents”). Rotation to a new issuance log or the subsequent retirement of a CA Cosigner Key does not invalidate Subscriber certificates previously issued to the inoperable issuance log. If the CA chooses to retire the associated CA Cosigner Key as a result of the issuance log failure, Chrome may apply a Key Sunset Date, as described in Section 2.6.3. (“CA Cosigner Key Lifecycle & Rotation”) to allow previously issued certificates to remain trusted by Chrome clients until their natural expiry. +To ensure Subscriber certificate information is widely available, MTC CA Operators MUST attempt to submit all issuance log updates to all Chrome-recognized Mirroring Cosigners in `Candidate`, `Qualified`, and `Usable` states described in Section 3.3. ("Mirroring Cosigner States"). Chrome will monitor to ensure that cosigned mirror checkpoints and supporting log tiles are made available on mirror endpoints in accordance with the timeliness SLA defined in Section 3.2.3. ("Cosigning Timeliness"). -##### 2.5.1.3. Data Retention and Log Pruning +To prevent log fragmentation and ensure consistent oversight, MTC CA Operators MUST issue Subscriber certificates to only one issuance log at a time per Active CA Cosigner Key. If an issuance log becomes inoperable, the MTC CA Operator MAY rotate to a new issuance log to maintain issuance availability. Every rotation to a new issuance log for the same Active CA Cosigner Key MUST be publicly reported as an incident, as specified in Section 2.7.3. ("Publicly Reporting on Incidents"). Rotation to a new issuance log or the subsequent retirement of a CA Cosigner Key does not invalidate Subscriber certificates previously issued to the inoperable issuance log. If the CA chooses to retire the associated CA Cosigner Key as a result of the issuance log failure, Chrome may apply a Key Sunset Date, as described in Section 2.6.3. ("CA Cosigner Key Lifecycle & Rotation") to allow previously issued certificates to remain trusted by Chrome clients until their natural expiry. -To sufficiently allow for real-time ecosystem monitoring and short-term post-incident triage of soon-to-be or recently expired Subscriber certificates, MTC CA Operators MUST ensure that log entries remain available in the corresponding issuance log for at least 35 days after the end of the certificate's validity period. +##### **2.5.1.3. Data Retention and Log Pruning** -To further prevent fragmented or hidden issuance logs and ensure monitors can predictably track all active issuance, Chrome enforces a strict upper bound on the number of issuance logs associated with a single CA Cosigner Key. For any given CA Cosigner Key, Chrome will only trust issuance log numbers 0 through 4. When transitioning to a new issuance log, the MTC CA Operator MUST use the next sequential issuance log number. Subscriber certificates issued to an issuance log number of 5 or greater will not be trusted by Chrome clients. +MTC CA Operators MUST NOT prune any log entry with a serial number greater than or equal to the `safe_to_prune_before` value published by Chrome in [`cosigners.json`](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json). For capacity planning, operators SHOULD retain entries for at least 35 days after the end of the certificate's validity period (Chrome updates `safe_to_prune_before` to reflect entries that have been revoked or expired for at least 35 days). -##### 2.5.1.4. Service Availability and Reporting +To further prevent fragmented or hidden issuance logs and ensure monitors can predictably track all active issuance, Chrome enforces a strict upper bound on the number of issuance logs associated with a single CA Cosigner Key. For any given CA Cosigner Key, Chrome will only trust issuance log numbers 1 through 5. When transitioning to a new issuance log, the MTC CA Operator MUST use the next sequential issuance log number. Subscriber certificates issued to an issuance log number of 6 or greater will not be trusted by Chrome clients. + +##### **2.5.1.4. Service Availability and Reporting** The MTC CA issuance log MUST maintain high availability for read operations: -* Each log endpoint MUST maintain a request success rate (where a successful response is returned for a well-formed request) of at least 99.9% evaluated over any 72 hour period. This ensures short-term but persistent errors are addressed independently of the 30-day overall requirement below. -* Each log endpoint MUST maintain a request success rate of at least 99.0% evaluated over any rolling 30-calendar-day period. This ensures that a single, large disruption, or a series of severe, non-consecutive outages, is addressed even if the system recovers in under 72 hours. +* Each log endpoint MUST maintain a request success rate (where a successful response is returned for a well-formed request) of at least 99.9% evaluated over any 72-hour period. This ensures sustained, low-grade request failures (e.g., due to rate limiting) are addressed independently of the 30-day overall requirement below. +* Each log endpoint MUST maintain a request success rate of at least 99.0% evaluated over any rolling 30-calendar-day period. This bounds cumulative downtime over a month and ensures that a single, large disruption, or a series of severe, non-consecutive outages, is addressed even if the system recovers in under 72 hours. -Any planned scheduled maintenance that will interrupt issuance log service MUST be publicly announced in advance, minimally on the MTC CA Operator’s public status page. This announcement SHOULD be published no less than 48 hours before the outage begins. +Any Planned Maintenance that will interrupt these services MUST be publicly announced in advance in accordance with the definition of Planned Maintenance in this policy (note that Planned Maintenance does not exempt endpoints from the availability requirements above). -Upon becoming aware of any event that results in a failure to meet either availability requirement, the MTC Operator MUST submit a public incident report following the guidance in Section 2.7.3.1. (“Incident Reports”). The availability SLAs for a specific CA Cosigner Key's issuance log apply only until its final retention (Key Sunset Date + maximum permitted certificate lifetime + 35 days) has elapsed, after which Chrome no longer monitors the endpoint. +Upon becoming aware of any event that results in a failure to meet either availability requirement, the MTC CA Operator MUST submit a public incident report following the guidance in Section 2.7.3.1. ("Incident Reports"). The availability SLAs for a specific CA Cosigner Key's issuance log apply only until its final retention (Key Sunset Date + maximum permitted certificate lifetime + 35 days) has elapsed, after which Chrome no longer monitors the endpoint. -#### 2.5.2. Issuance Log Cryptographic Integrity +#### **2.5.2. Issuance Log Cryptographic Integrity** The foundational security guarantee of the CQRS is the immutability of the MTC CA issuance log. If an MTC CA issuance log presents a split-view or cannot serve its data in a cryptographically verifiable way, it is considered a catastrophic failure. Any non-cryptographically verifiable issuance log MUST automatically discontinue Subscriber certificate issuance and the MTC CA Operator MUST issue a public incident report. Such failures MAY result in the CA Cosigner’s removal from the CQRS. -### 2.6. CA Cosigners +### **2.6. CA Cosigners** Each CA Cosigner MUST operate in full conformance with this policy throughout its entire operational lifecycle, beginning at the time of key generation and continuing until the key is removed from the CQRS. -#### 2.6.1. CA Cosigner Key Generation +#### **2.6.1. CA Cosigner Key Generation** -To protect key material from unauthorized extraction, duplication, or misuse, CA Cosigner private keys MUST be generated, maintained, and perform all cryptographic operations within a Hardware Security Module (HSM) that is formally validated to FIPS 140-3 Level 3 or Common Criteria (CC) EAL 4+ (or higher). This requirement does not preclude the creation of secure, encrypted key backups or wrapped key transfers for disaster recovery or HSM migration, provided that the plaintext key material never exists outside of a validated HSM boundary and that all backup or transfer operations are performed under multi-person control by individuals in authorized Trusted Roles. +To protect key material from unauthorized extraction, duplication, or misuse, CA Cosigner private keys MUST be generated, maintained, and perform all cryptographic operations within a Hardware Security Module (HSM) that is formally validated to FIPS 140-3 Level 3 or Common Criteria (CC) EAL 4+ (or higher). This requirement does not preclude the creation of secure, encrypted key backups or wrapped key transfers for disaster recovery or HSM migration, provided that the plaintext key material never exists outside of a validated HSM boundary and that all backup or transfer operations are performed under multi-person control by individuals in authorized Trusted Roles (as defined in the Network and Certificate System Security Requirements). -For the purposes of Section 6.1.1.1 ("CA Key Pair Generation") of the Baseline Requirements, MTC CA Cosigner Keys are considered to be CA Key Pairs for a Root Certificate. +For the purposes of Section 6.1.1.1 ("CA Key Pair Generation") of the Baseline Requirements, MTC CA Cosigner Keys are considered to be CA Key Pairs for a Root Certificate. -For the purposes of Section 1.2.1 of the Network and Certificate System Security Requirements (incorporated by reference in the Baseline Requirements) MTC CA Cosigner Keys and Mirroring Cosigner Keys are not considered Root CA Systems. +For the purposes of Section 1.2.1 of the Network and Certificate System Security Requirements (incorporated by reference in the Baseline Requirements), MTC CA Cosigner Keys and Mirroring Cosigner Keys are not considered Root CA Systems. If the HSM employed to generate and store the required CA Cosigner key pair has not yet achieved full Cryptographic Module Validation Program (CMVP) certification for ML-DSA ([RFC 9881](https://www.rfc-editor.org/rfc/rfc9881.html)) and ML-KEM ([RFC 9935](https://datatracker.ietf.org/doc/rfc9935/)) in an Approved Mode of operation, the generation and use of the key is permitted provided that: @@ -465,83 +487,86 @@ If the HSM employed to generate and store the required CA Cosigner key pair has Effective January 1, 2029, the HSM storing CA Cosigner Keys not already trusted by Chrome MUST possess a CMVP certification explicitly covering ML-DSA and ML-KEM. This intends to allow sufficient time for hardware vendors and testing laboratories to fully implement and execute the new post-quantum validation programs. > [!NOTE] -> A future update to this policy is expected to allow the use of a single-tenant Cloud HSM to fulfill the requirements of this section, provided that the service architecture guarantees the following: -> -> * The CA Cosigner private key is generated directly within the FIPS/CC validated hardware boundary and is strictly non-exportable in plaintext form under any circumstance. -> * The cryptographic module enforces strict logical separation of roles, ensuring that the CA's Cosigner Key material cannot be accessed, used, or modified by unauthorized individuals. -> * Access and activation controls exist and ensure that key material cannot be accessed, activated, or authorized solely by cloud infrastructure, hosting, or facility staff. All key activation quorums and cryptographic authorizations MUST require the direct, interactive participation of personnel explicitly appointed to authorized MTC CA Trusted Roles. -> * All cryptographic operations (e.g., signing) utilizing the private key occur entirely within the validated hardware boundary; the key is never loaded into external host or client software memory to execute the operation. +> A future update to this policy is expected to allow the use of a single-tenant Cloud HSM to fulfill the requirements of this section. Additionally, a future update may require publicly verifiable cryptographic key attestation from the HSM to cryptographically prove that each CA Cosigner Key was natively generated within (i.e., not imported into), is non-exportable in plaintext from, and remains protected by a compliant HSM. -MTC CA Operators MUST collect written evidence from a Qualified Auditor (as defined within the Baseline Requirements) using their approved format for key generation ceremonies, that identifies the date(s) and approximate location(s) of the key generation ceremony and attests to the operator's adherence to the requirements defined in Section 6.1.1.1 ("CA Key Pair Generation") and 6.2 ("Private Key Protection and Cryptographic Module Engineering Controls") of the Baseline Requirements. These audit letters MUST be hosted in the MTC CA Operator’s Repository. +MTC CA Operators MUST collect written evidence from a Qualified Auditor (as defined within the Baseline Requirements) using their approved format for key generation ceremonies, that identifies the date(s) and approximate location(s) of the key generation ceremony and attests to the operator's adherence to the requirements defined in Section 6.1.1.1 ("CA Key Pair Generation") and 6.2 ("Private Key Protection and Cryptographic Module Engineering Controls") of the Baseline Requirements. These audit attestations MUST be hosted in the MTC CA Operator’s Repository. -#### 2.6.2. CA Cosigner Key Use +#### **2.6.2. CA Cosigner Key Use** CA Cosigner Keys MUST only be used in support of the MTC CA and its ancillary functions. To maintain a flat trust hierarchy, MTC CAs MUST NOT issue Subordinate CA certificates of any kind. -To encourage ecosystem agility, ensure rotation mechanisms are routinely exercised, and bound the operational impact of a potential undetected key compromise, a CA Cosigner Key will be trusted for a maximum of 6 years once included in the CQRS. +To encourage ecosystem agility, ensure rotation mechanisms are routinely exercised, and bound the operational impact of a potential undetected key compromise, a CA Cosigner Key will be trusted for a maximum of 2280 days (approximately 6 years) once included in the CQRS. To ensure resilience against operational disruption and support disaster recovery, an MTC CA Operator MUST maintain in good standing a minimum of 3 and a maximum of 6 CA Cosigner Keys included in the CQRS, which MUST be composed as follows: | Cosigner Key | Algorithm | Maximum Subscriber Validity | Additional Requirements | | :---- | :---: | :---- | :---- | | Active CA Cosigner #1 (Required) | ML-DSA-44 | 7 days | MUST be online and used for ongoing Subscriber certificate issuance. SHOULD generate landmarks approximately every hour, and MUST NOT exceed a total of 220 landmarks over any 7-day period. | -| Reserve CA Cosigner #1 (Required) This key is reserved for use in a planned key rotation event. | ML-DSA-44 | N/A | MUST be maintained in a secure offline state by the MTC CA Operator, meaning the private key is physically air-gapped or logically disabled, and bringing the key into an active state requires interactive, multi-person authorization. | -| Reserve CA Cosigner #2 (Required) This key is reserved for use in a disaster recovery event. | ML-DSA-44 | N/A | MUST be maintained in a secure offline state by the MTC CA Operator, meaning the private key is physically air-gapped or logically disabled, and bringing the key into an active state requires interactive, multi-person authorization. | -| Active CA Cosigner #2 (Optional) Active CA Cosigner #3 (Optional) Active CA Cosigner #4 (Optional) | ML-DSA-44\* | 47 days\*\* | MUST be online and used for ongoing Subscriber certificate issuance. SHOULD generate landmarks approximately every 4 hours, and MUST NOT exceed a total of 370 landmarks over any 47-day period.\*\*\* | +| Reserve CA Cosigner #1 (Required) This key is reserved for use in a planned key rotation or disaster recovery event. | ML-DSA-44 | N/A | MUST be maintained in a secure offline state by the MTC CA Operator, meaning the private key is physically air-gapped or logically disabled, and bringing the key into an active state requires interactive, multi-person authorization. | +| Reserve CA Cosigner #2 (Required) This key is reserved for use in a planned key rotation or disaster recovery event. | ML-DSA-44 | N/A | MUST be maintained in a secure offline state by the MTC CA Operator, meaning the private key is physically air-gapped or logically disabled, and bringing the key into an active state requires interactive, multi-person authorization. | +| Active CA Cosigner #2 (Optional) Active CA Cosigner #3 (Optional) Active CA Cosigner #4 (Optional) | ML-DSA-44* | 47 days* | MUST be online and used for ongoing Subscriber certificate issuance. Landmark generation MUST correspond to the maximum certificate validity issued by the CA Cosigner: Up to 7-day validity: SHOULD generate landmarks approximately every hour, and MUST NOT exceed a total of 220 landmarks over any 7-day period. Exceeding 7-day validity (up to 47 days): SHOULD generate landmarks approximately every 4 hours, and MUST NOT exceed a total of 370 landmarks over any 47-day period. | > [!NOTE] -> (\*) A future policy update is expected to allow use of up to 3 ML-DSA-87 CA Cosigner Keys. These keys (\*\*) MUST only issue 7-day certificates, and (\*\*\*) SHOULD generate landmarks approximately every hour, and MUST NOT exceed a total of 220 landmarks over any 7-day period. In general, the use of ML-DSA-44 keys and a 7-day Subscriber certificate validity is RECOMMENDED. +> (*) While ML-DSA-44 keys and a 7-day Subscriber certificate validity are RECOMMENDED, a future update to this policy is expected to allow the use of up to 3 ML-DSA-87 Active CA Cosigner Keys (which will be restricted to a maximum Subscriber certificate validity of 7 days). -#### 2.6.3. CA Cosigner Key Lifecycle and Rotation +#### **2.6.3. CA Cosigner Key Lifecycle and Rotation** MTC CA Operators are responsible for managing the lifecycle of their CA Cosigner Keys in coordination with the CQRP and the ecosystem to ensure a seamless transition during planned rotations. To facilitate this transition and safely stage the update across Chrome clients, MTC CA Operators MUST submit requests to add or remove CA Cosigner Keys from the CQRS at least 30 calendar days in advance of a quarterly scheduled update, utilizing key material that was generated no more than 4 years prior to the request submission date. Key additions and removals will only be targeted for processing on the 15th day of January, April, July, and October. -To facilitate a key rotation schedule, an individual CA Cosigner Key SHOULD NOT be used for Subscriber certificate issuance for more than 4 years. MTC CA Operators SHOULD establish a regular key ceremony schedule to refresh Active CA Cosigner Keys, utilizing a designated Reserve CA Cosigner Key to facilitate planned rotations while preserving an offline Reserve key for emergency disaster recovery. Operators MAY rotate multiple Active keys during a single ceremony event to optimize operational overhead. +To facilitate a key rotation schedule, an individual CA Cosigner Key SHOULD NOT be used for Subscriber certificate issuance for more than 1550 days (approximately 4 years). MTC CA Operators SHOULD establish a regular key ceremony schedule to refresh Active CA Cosigner Keys, utilizing designated Reserve CA Cosigner Keys to facilitate planned rotations. While operators MUST maintain 2 offline Reserve CA Cosigner Keys in the CQRS at all times, operators MAY transition both Reserve keys to Active during a single CQRS update to rotate multiple Active keys at once, provided that replacement Reserve keys are simultaneously introduced in the same batch to maintain ongoing disaster recovery readiness. -MTC CA Operators MAY issue Subscriber certificates concurrently from multiple Active CA Cosigner Keys; however, issuance MUST be limited to Active CA Cosigner Keys defined in Section 2.6.2. (“CA Cosigner Key Use”). When an MTC CA Operator is ready to retire an Active CA Cosigner Key from the CQRS, they MUST notify chrome-quantum-resistant-root-program [at] google [dot] com. Following this notification, Chrome will establish and apply a Key Sunset Date for that specific key. Chrome clients will not trust any Subscriber certificates issued by that key after the established sunset date. +MTC CA Operators MAY issue Subscriber certificates concurrently from multiple Active CA Cosigner Keys; however, issuance MUST be limited to Active CA Cosigner Keys defined in Section 2.6.2. ("CA Cosigner Key Use"). When an MTC CA Operator is ready to retire an Active CA Cosigner Key from the CQRS, they MUST notify mtcs [at] chromium [dot] org. Following this notification, Chrome will establish and apply a Key Sunset Date for that specific key. Chrome clients will not trust any Subscriber certificates issued by that key after the established sunset date. A key rotation schedule might look something akin to: -
         | Y1  | Y2  | Y3  | Y4  | Y5  | Y6  | Y7  | Y8  | Y9  | Y10 |
----------|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|
-Key 1    | [A] | [-] |     |     |     |     |     |     |     |     |
-Key 2    | [A] | [A] | [-] |     |     |     |     |     |     |     |
-Key 3    | [A] | [A] | [A] | [-] |     |     |     |     |     |     |
-Key 4    | [A] | [A] | [A] | [A] | [-] |     |     |     |     |     |
-Key 5    | [+] | [A] | [A] | [A] | [A] | [-] |     |     |     |     |
-Key 6    | [+] | [+] | [A] | [A] | [A] | [A] | [-] |     |     |     |
-Key 7    |     | [+] | [+] | [A] | [A] | [A] | [A] | [-] |     |     |
-Key 8    |     |     | [+] | [+] | [A] | [A] | [A] | [A] | [-] |     |
-Key 9    |     |     |     | [+] | [+] | [A] | [A] | [A] | [A] | [-] |
-Key 10   |     |     |     |     | [+] | [+] | [A] | [A] | [A] | [A] |
-Key 11   |     |     |     |     |     | [+] | [+] | [A] | [A] | [A] |
-Key 12   |     |     |     |     |     |     | [+] | [+] | [A] | [A] |
-
+
         | Y1  | Y2  | Y3  | Y4  | Y5  | Y6  | Y7  | Y8  | Y9  | Y10 | Y11 | Y12 | Y13 | Y14 | Y15 |
+---------|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|
+Key 1    | [A] | [-] |     |     |     |     |     |     |     |     |     |     |     |     |     |
+Key 2    | [A] | [A] | [-] |     |     |     |     |     |     |     |     |     |     |     |     |
+Key 3    | [A] | [A] | [A] | [-] |     |     |     |     |     |     |     |     |     |     |     |
+Key 4    | [A] | [A] | [A] | [A] | [-] |     |     |     |     |     |     |     |     |     |     |
+Key 5    | [+] | [A] | [A] | [A] | [A] | [-] |     |     |     |     |     |     |     |     |     |
+Key 6    | [+] | [+] | [A] | [A] | [A] | [A] | [-] |     |     |     |     |     |     |     |     |
+Key 7    |     | [+] | [+] | [A] | [A] | [A] | [A] | [-] |     |     |     |     |     |     |     |
+Key 8    |     |     | [+] | [+] | [A] | [A] | [A] | [A] | [-] |     |     |     |     |     |     |
+Key 9    |     |     |     | [+] | [+] | [A] | [A] | [A] | [A] | [-] |     |     |     |     |     |
+Key 10   |     |     |     |     | [+] | [+] | [A] | [A] | [A] | [A] | [-] |     |     |     |     |
+Key 11   |     |     |     |     |     | [+] | [+] | [A] | [A] | [A] | [A] | [-] |     |     |     |
+Key 12   |     |     |     |     |     |     | [+] | [+] | [A] | [A] | [A] | [A] | [-] |     |     |
+Key 13   |     |     |     |     |     |     |     | [+] | [+] | [A] | [A] | [A] | [A] | [-] |     |
+Key 14   |     |     |     |     |     |     |     |     | [+] | [+] | [A] | [A] | [A] | [A] | [-] |
+Key 15   |     |     |     |     |     |     |     |     |     | [+] | [+] | [A] | [A] | [A] | [A] |
+ 
 Legend:
  [ + ] = Reserve (Offline / Inactive)
  [ A ] = Active (Online, issuing Subscriber certificates)
- [ - ] = Retired & Removed (Key Sunset applied, removed from CQRS, no longer trusted by Chrome)

+ [ - ] = Retired & Removed (Key Sunset Date applied to bound trust to previously issued certificates; removed from CQRS after those certificates expire)
The maximum limits of 4 Active CA Cosigner Keys and 2 Reserve CA Cosigner Keys are evaluated against the net effective state of the MTC CA Operator’s keys after a batch of updates is processed (e.g., on the 15th of the month), rather than the queueing state. A processed retirement of a key immediately frees up a slot in its respective category (Active or Reserve). An MTC CA Operator with the maximum number of keys (i.e., 4 Active and 2 Reserve) MAY submit an addition/activation request, provided they simultaneously submit a retirement request in the same processing batch. Because both actions are processed together, the net resulting state will not exceed the limit. A valid rotation and invalid addition might look something like: * An operator currently has 4 Active keys and 2 Reserve keys. They submit a request to retire and remove 1 Active key, transition 1 Reserve key to Active, and add 1 new Reserve key. Upon processing, the net result is 4 Active and 2 Reserve keys. This is valid. -* An operator currently has 4 Active keys. They submit a request to transition 1 Reserve key to Active, but do not submit a retirement for an existing Active key. Because the processed result would be 5 Active keys, the update request will be rejected. This is invalid. +* An operator currently has 4 Active keys. They submit a request to transition 1 Reserve key to Active, but do not submit a retirement for an existing Active key. Because the processed result would be 5 Active keys, the update request will be rejected. This is invalid. -### 2.7. Oversight and Incident Reporting +### **2.7. Oversight and Incident Reporting** -#### 2.7.1. Annual Third Party Audits +#### **2.7.1. Annual Third Party Audits** At this time, MTC CAs are exempt from the annual, contiguous audit requirements detailed in Section 8 ("Compliance Audit and Other Assessments") of the Baseline Requirements. This exemption exists because current compliance evaluation criteria are bound to traditional X.509 architectures and may not accurately apply to MTC operations, especially while the underlying standards remain in active development. -#### 2.7.2. Timely and Transparent Communications +In lieu of annual third-party audits, the CQRP may at any time require an MTC CA Operator to provide operational and system artifacts or execute directed compliance exercises to independently verify conformance with this policy. These exercises will be scoped to avoid disrupting Subscriber operations and may include, for example, timed certificate issuances for designated test domains under the control of the MTC CA Operator or the CQRP using standard validation and issuance workflows to evaluate issuance logging and mirroring. If such a request is made, the CQRP will work with the MTC CA Operator to identify reasonable timelines and disclosure methodologies, and the MTC CA Operator would need to complete the exercise and provide the requested data within the established timeframe. + +> [!NOTE] +> To promote issuance transparency and increase accountability, a future update to this policy is expected to require MTC CA Operators to publish privacy-preserving validation data describing the domain control validation relied upon for each issuance, bound to the corresponding issuance log entry. + +#### **2.7.2. Timely and Transparent Communications** The CQRP may request additional information from an MTC CA Operator to verify that the commitments and obligations outlined in this policy are being met, or when updates to policy requirements are being considered. To ensure timely resolution of compliance questions and swift evaluation of potential ecosystem risks, MTC CA Operators MUST provide the requested information within 14 calendar days unless specified otherwise. -#### 2.7.3. Publicly Reporting on Incidents +#### **2.7.3. Publicly Reporting on Incidents** -If an MTC CA Operator fails to meet this policy's commitments (excluding the requirements detailed in Section 3. (“Minimum Requirements for Mirroring Operators"), which have their own notification process) it is considered a publicly reportable incident. A reportable incident includes, but is not limited to: +If an MTC CA Operator fails to meet this policy's commitments (excluding the requirements detailed in Section 3. ("Minimum Requirements for Mirroring Operators"), which have their own notification process), it is considered a publicly reportable incident. A reportable incident includes, but is not limited to: * a known or suspected compromise of any CA Cosigner Key. * presenting conflicting Merkle Tree views or signing inconsistent checkpoints. @@ -549,9 +574,9 @@ If an MTC CA Operator fails to meet this policy's commitments (excluding the req * failure to meet the availability requirements from this policy. * any other situation that may impact the MTC CA's integrity, trustworthiness, or compatibility. -##### 2.7.3.1. Incident Reports +##### **2.7.3.1. Incident Reports** -To maintain transparency and enable the CQRP and the broader community to independently evaluate the severity and systemic risks of an event, rather than relying solely on the operator's internal assessment, MTC CA Operators MUST publicly disclose and/or respond to incident reports, regardless of perceived impact. Reports MUST be submitted in accordance with the current version of the [CCADB Incident Reporting Guidelines](https://www.ccadb.org/cas/incident-report). The CQRP uses the information in the public disclosure as the basis for evaluating incidents. +To maintain transparency and enable the CQRP and the broader community to independently evaluate the severity and systemic risks of an event, rather than relying solely on the operator's internal assessment, MTC CA Operators MUST publicly disclose and/or respond to incident reports, regardless of perceived impact. Reports MUST be submitted in accordance with the current version of the [CCADB Incident Reporting Guidelines](https://www.ccadb.org/cas/incident-report) format and timelines. The CQRP uses the information in the public disclosure as the basis for evaluating incidents. To ensure the CQRP is immediately alerted to severe vulnerabilities or active compromises while a safe public disclosure plan is actively coordinated, if the MTC CA Operator has not yet publicly disclosed an incident, they MUST notify chrome-quantum-resistant-root-program [at] google [dot] com and include an initial timeline for public disclosure. @@ -559,12 +584,12 @@ MTC CA Operators MUST be detailed, candid, timely, and transparent in describing Factors that are significant to the CQRP when evaluating incidents include, but are not limited to: -* a demonstration of understanding of the root causes of an incident, -* a substantive commitment and timeline to changes that clearly and persuasively address the root cause, -* past history by the MTC CA Operator in its incident handling and its follow through on commitments, and, +* a demonstration of understanding of the root causes of an incident, +* a substantive commitment and timeline to changes that clearly and persuasively address the root cause, +* past history by the MTC CA Operator in its incident handling and its follow-through on commitments, and, * the severity of the security impact of the incident. -##### 2.7.3.2. Communicating with Chrome During Incidents +##### **2.7.3.2. Communicating with Chrome During Incidents** The CQRP prioritizes and remains committed to promoting public disclosure and discussion of incidents, as they can affect the entire Internet, not just Chrome and its users. The CQRP’s sole responsibility when responding to incidents is upholding the safety and security of Chrome's users. @@ -574,71 +599,71 @@ As standard practice, the CQRP does not: * advise on or approve an operator’s proposed or planned response to an incident; or * offer guarantees of specific outcomes in response to the course of action deemed most appropriate by the operator. -## 3. Minimum Requirements for Mirroring Operators +## **3. Minimum Requirements for Mirroring Operators** -The requirements in this section apply to MTC CA Operators and Independent Mirroring Operators. - -To ensure the availability of Subscriber certificate information, MTC CA Operators MUST operate a Mirroring Cosigner usable by all other CA Cosigners included in Chrome’s [cosigners.json](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json). This operational requirement contributes to a decentralized, highly available web of transparency. +To ensure the availability of Subscriber certificate information, MTC CA Operators MUST operate a Mirroring Cosigner usable by all other CA Cosigners included in Chrome’s [`cosigners.json`](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json). This operational requirement contributes to a decentralized, highly available web of transparency. While reference implementations may distinguish between a "witness" (consistency verification) and a "mirror" (durable storage), a Chrome-recognized Mirroring Cosigner MUST perform both roles. It MUST verify log consistency prior to cosigning and MUST maintain public availability of the mirrored log data. -### 3.1. Mirroring Cosigner Key Generation and Use +### **3.1. Mirroring Cosigner Key Generation and Use** -Each Mirroring Operator MUST operate a single Mirroring Cosigner Key. To ensure consistent interoperability, minimize bandwidth overhead, and optimize signature verification performance across all Chrome clients, Mirroring Cosigner Keys MUST be ML-DSA-44 (OID: 2.16.840.1.101.3.4.3.17) (RFC 9881). Cosignatures MUST be generated and formatted in accordance with the tlog-cosignature [specification](https://github.com/C2SP/C2SP/blob/main/tlog-cosignature.md) [TODO: point to final/latest spec before v1.0.0 of this policy]. +Even during a planned key rotation coordinated under Section 3.4. ("Mirroring Cosigner Lifecycle and Rotation"), the CQRP will designate at most one Mirroring Cosigner Key per Mirroring Operator as `Usable` in [`cosigners.json`](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json) at any given time. To ensure consistent interoperability, minimize bandwidth overhead, and optimize signature verification performance across all Chrome clients, Mirroring Cosigner Keys MUST be ML-DSA-44 (OID: 2.16.840.1.101.3.4.3.17) ([RFC 9881](https://www.rfc-editor.org/info/rfc9881)). Cosignatures MUST be generated and formatted in accordance with the tlog-cosignature [specification](https://c2sp.org/tlog-cosignature@v1.1.0). -While the use of a HSM for generating Mirroring Cosigner Keys is OPTIONAL, operators MUST ensure these keys are protected against misuse. +While the use of an HSM for generating and storing Mirroring Cosigner Keys is OPTIONAL, operators MUST ensure these keys are protected against misuse, and MUST promptly notify mtcs [at] chromium [dot] org in the event of any known or suspected Mirroring Cosigner Key compromise. Mirroring Cosigner Keys MUST be dedicated exclusively to cosigning issuance log checkpoints and views as defined in this policy. Mirroring Operators MUST NOT utilize Mirroring Cosigner Keys for any other cryptographic function or external purpose. -To facilitate a key rotation schedule, an individual Mirroring Cosigner Key SHOULD NOT be used for more than 4 years. +To facilitate a key rotation schedule, an individual Mirroring Cosigner Key SHOULD NOT be used for more than 1550 days (approximately 4 years). -### 3.2. Mirroring Cosigner Operations +### **3.2. Mirroring Cosigner Operations** -#### 3.2.1. Technical Specifications +#### **3.2.1. Technical Specifications** -Mirroring Cosigners MUST strictly implement the API endpoints, cryptographic formats, and validation logic defined in the MTC [specification](https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/) [TODO: point to final/latest spec before v1.0.0 of this policy], the mtc-tlog [specification](https://github.com/C2SP/C2SP/blob/main/mtc-tlog.md) [TODO: point to the final/latest spec before v1.0.0 of this policy] the tlog-mirror [specification](https://github.com/C2SP/C2SP/blob/main/tlog-mirror.md) [TODO: point to final/latest spec before v1.0.0 of this policy], and and the tlog-cosignature [specification](https://github.com/C2SP/C2SP/blob/main/tlog-cosignature.md) [TODO: point to final/latest spec before v1.0.0 of this policy]. +Mirroring Cosigners MUST strictly implement the API endpoints, cryptographic formats, and validation logic defined in the MTC [specification](https://datatracker.ietf.org/doc/html/draft-ietf-plants-merkle-tree-certs-07), the mtc-tlog [specification](https://c2sp.org/mtc-tlog@v0.1.0), the tlog-mirror [specification](https://c2sp.org/tlog-mirror@v0.1.0), and the tlog-cosignature [specification](https://c2sp.org/tlog-cosignature@v1.1.0).  -#### 3.2.2. Log Discovery and Synchronization +#### **3.2.2. Log Discovery and Synchronization** -Mirroring Cosigners MUST consume Chrome’s [cosigners.json](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json) at least every 24 hours to ensure newly added CA Cosigners are promptly recognized and eligible for mirroring. Upon a CA Cosigner Key no longer being included in [cosigners.json](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json), Mirroring Cosigners MAY stop mirroring the corresponding issuance log(s). +Mirroring Cosigners MUST consume Chrome’s [`cosigners.json`](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json) at least every 24 hours to ensure newly added CA Cosigners are promptly recognized and incorporated into their active mirroring configurations. Upon a CA Cosigner Key no longer being included in [`cosigners.json`](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json), Mirroring Cosigners MAY stop mirroring the corresponding issuance log(s). -#### 3.2.3. Cosigning Timeliness +#### **3.2.3. Cosigning Timeliness** -To ensure clients receive timely cryptographic proofs, Mirroring Cosigners: +To ensure clients and monitors receive timely cryptographic proofs and to prevent the issuance of unobservable cosignatures, Mirroring Cosigners: -* SHOULD ensure that the newly cosigned checkpoint, along with all supporting log tiles and entries necessary to cryptographically verify it, is available on its public endpoints immediately after cosignature issuance. -* MUST ensure that the cosigned checkpoint and all supporting log tiles and entries are available on its public endpoints within 5 minutes of cosignature issuance. +* SHOULD ensure that the newly cosigned checkpoint, along with all supporting log tiles and entries necessary to cryptographically verify it, is available on their public endpoints immediately after cosignature issuance. +* MUST ensure that the cosigned checkpoint and all supporting log tiles and entries are available on their public endpoints within 10 minutes of cosignature issuance, and SHOULD consistently achieve availability within 5 minutes under normal operating conditions. -#### 3.2.4. Data Retention and Log Pruning +#### **3.2.4. Data Retention and Log Pruning** -Mirroring Cosigners MUST ensure that log entries remain available for at least 35 days after the end of the certificate's validity period. To guarantee that mirrors function as complete, highly available backups of the transparency ecosystem and do not create premature data unavailability, Mirroring Cosigners 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 once 90 days have elapsed since the end of the certificate's validity period. +Mirroring Cosigners MUST NOT prune any log entry with a serial number greater than or equal to the `safe_to_prune_before` value published by Chrome in [`cosigners.json`](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json). For capacity planning, operators SHOULD retain entries for at least 35 days after the end of the certificate's validity period. To guarantee that mirrors function as complete, highly available backups of the transparency ecosystem and do not create premature data unavailability, Mirroring Cosigners 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. -#### 3.2.5. Service Availability and Reporting +#### **3.2.5. Service Availability and Reporting** Mirroring Cosigners MUST maintain high availability for both read and write operations: -* Each mirror endpoint MUST maintain a request success rate (where a successful response is returned for a well-formed request) of at least 99.9% evaluated over any 72 hour period. This ensures short-term but persistent errors are addressed independently of the 30-day overall requirement below. -* Each mirror endpoint MUST maintain a request success rate of at least 99.0% evaluated over any rolling 30-calendar-day period. This ensures that a single, large disruption, or a series of severe, non-consecutive outages, is addressed even if the system recovers in under 3 days. +* Each mirror endpoint MUST maintain a request success rate (where a successful response is returned for a well-formed request) of at least 99.9% evaluated over any 72-hour period. This ensures sustained, low-grade request failures (e.g., due to rate limiting) are addressed independently of the 30-day overall requirement below. +* Each mirror endpoint MUST maintain a request success rate of at least 99.0% evaluated over any rolling 30-calendar-day period. This bounds cumulative downtime over a month and ensures that a single, large disruption, or a series of severe, non-consecutive outages, is addressed even if the system recovers in under 3 days. -Any planned scheduled maintenance that will interrupt these services MUST be publicly announced before the maintenance begins. This announcement SHOULD be published no less than 48 hours before the outage begins. +Any Planned Maintenance that will interrupt these services MUST be publicly announced in advance in accordance with the definition of Planned Maintenance in this policy (note that Planned Maintenance only exempts write operations from the 72-hour availability requirement above; write operations MUST still meet the 30-calendar-day requirement, and read operations are not exempt from either requirement). Upon becoming aware of any event that results in a failure to meet either availability requirement, the Mirroring Operator MUST notify mtcs [at] chromium [dot] org within 1 calendar day. This initial notification SHOULD include a high-level description of the incident and an estimated timeline for service restoration. Following the resolution of such an incident, the Mirroring Operator MUST submit a post-mortem report to mtcs [at] chromium [dot] org within 14 calendar days of service being sufficiently restored. This report SHOULD outline the technical and procedural safeguards that failed and the mitigations enacted to prevent recurrence. -#### 3.2.6. Log Inconsistency Reporting +#### **3.2.6. Log Consistency** + +Mirroring Cosigners MUST strictly enforce append-only consistency for every mirrored issuance log. Generating a valid cosignature over an MTC CA log state that is cryptographically inconsistent with the Mirroring Cosigner's prior view of that log constitutes a critical operational failure by the Mirroring Cosigner. This failure to enforce append-only consistency will result in the mirror's transition to the `Frozen` state, and may result in the removal of the operator from Chrome's [`cosigners.json`](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json). -To aid in the discovery of log incidents such as split-views, Mirroring Operators SHOULD report any checkpoint discovered from an issuance log that is inconsistent with the mirror's previous checkpoint for that log to mtcs [at] chromium [dot] org. Generating a valid cosignature over an MTC CA log state that is cryptographically inconsistent with the Mirroring Cosigner's prior view of that log constitutes a critical operational failure by the Mirroring Cosigner. This failure to enforce append-only consistency will result in the mirror's transition to the `Frozen` state, and may result in the removal of the Mirroring Operator from Chrome's [cosigners.json](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json). +If a Mirroring Operator has credible evidence that an MTC CA Cosigner Key is compromised, is presenting a split-view, or is causing severe operational degradation (e.g., denial-of-service), the Mirroring Cosigner MAY temporarily suspend cosigning new checkpoints for that specific issuance log prior to the key's removal from [`cosigners.json`](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json), provided the Mirroring Operator immediately notifies mtcs [at] chromium [dot] org with the supporting evidence and continues to serve read requests for previously mirrored data. -### 3.3. Mirroring Cosigner States +### **3.3. Mirroring Cosigner States** To safely introduce and retire Mirroring Cosigners without disrupting the broader ecosystem, Chrome recognizes the following distinct operational states. Only cosignatures from `Usable` or `Frozen` (if the cosignature was generated prior to the freeze point) Mirroring Cosigners count toward the minimum Chrome client trust requirements defined in Section 2.4.5. ("Criteria for Chrome Usability"). -* `Candidate`: The initial state of a Mirroring Cosigner that is under consideration to be included in the CQRS. During this time, Mirroring Cosigners MUST be fully capable of cosigning and mirroring all MTC CAs included in the CQRS. `Candidate` cosignatures, whether embedded within a Standalone certificate or attached to a published landmark, do not contribute to Chrome client validation. -* `Qualified`: The state of a Mirroring Cosigner that has successfully completed its monitoring period and demonstrated adherence to all availability requirements. The new Mirroring Cosigner has been added to Chrome and published in [cosigners.json](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json), but can not yet be guaranteed to have propagated to all Chrome clients. -* `Usable`: The state of a Mirroring Cosigner that has been `Qualified` for at least 70 calendar days. Cosignatures from a `Usable` cosigner may be relied upon to satisfy the client validation requirements for both Standalone and Landmark-relative certificates. -* `Frozen`: The state of a Mirroring Cosigner that is no longer actively generating new cosignatures or observing new MTC CAs, but continues to provide high-availability read access to mirrored logs. Cosignatures generated prior to the freeze point remain valid for Chrome client validation. +* `Candidate`: The initial state of a Mirroring Cosigner that is under consideration to be included in the CQRS. To facilitate ecosystem discovery and compliance monitoring, `Candidate` Mirroring Cosigners are published in [`cosigners.json`](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json) and [`cosigners.pem`](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.pem), but are not yet distributed to Chrome clients. During this time, Mirroring Cosigners MUST be fully capable of cosigning and mirroring all MTC CAs included in the CQRS. `Candidate` cosignatures, whether embedded within a Standalone certificate or attached to a published landmark, do not contribute to Chrome client validation. +* `Qualified`: The state of a Mirroring Cosigner that has successfully completed its minimum 30-calendar-day monitoring period and demonstrated adherence to all availability requirements. The Mirroring Cosigner’s state is updated in [`cosigners.json`](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json) and its key and metadata have begun distribution to Chrome clients, but cannot yet be guaranteed to have propagated to all Chrome clients. +* `Usable`: The state of a Mirroring Cosigner that has been `Qualified` for at least 70 calendar days. Cosignatures from a `Usable` cosigner may be relied upon to satisfy the client validation requirements for both Standalone and Landmark-relative certificates. +* `Frozen`: The state of a Mirroring Cosigner that is no longer actively generating new cosignatures or observing new MTC CAs, but continues to provide high-availability read access to mirrored logs. Cosignatures generated prior to the freeze point remain valid for Chrome client validation. * `Removed`: The terminal state for a Mirroring Cosigner that is no longer trusted by Chrome. This may be due to the Mirroring Cosigner being shut down by the operator, violating this policy, suffering a catastrophic compromise, or other critical failure. Cosignatures from a `Removed` cosigner are immediately invalid and do not contribute to Chrome client validation, even if embedded within an otherwise valid Standalone certificate. -### 3.4. Mirroring Cosigner Lifecycle and Rotation +### **3.4. Mirroring Cosigner Lifecycle and Rotation** To ensure a seamless transition during planned retirement or replacement of Mirroring Cosigners and to minimize disruption to the ecosystem, Mirroring Operators MUST manage the lifecycle of their Mirroring Cosigner Keys in coordination with the CQRP. @@ -646,16 +671,26 @@ Mirroring Operators MUST notify mtcs [at] chromium [dot] org at least 30 calenda * The unique identifier of the Mirroring Cosigner. * The planned date for the Mirroring Cosigner to transition to the `Frozen` state. -* The planned date for the Mirroring Cosigner to be `Removed` from Chrome's [cosigners.json](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json). +* The planned date for the Mirroring Cosigner to be `Removed` from Chrome's [`cosigners.json`](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json). * A clear rationale for the planned transition (e.g., replacement with a new mirror, operational changes, etc.). -The CQRP reserves the right to request adjustments to proposed state transition or key rotation timelines, or require additional information, to ensure the continued security, transparency, and operational stability of the ecosystem. New Mirroring Cosigners can be submitted to the CQRP by following Section 1.1.2. (“New Mirroring Cosigners”) of [Preparing and Applying for Inclusion](apply.md). +During a planned key rotation, a Mirroring Operator MAY concurrently operate a retiring key and a designated replacement key: -## References +* The retiring key MUST remain in the `Usable` state until the replacement key has completed its qualification period and transitioned from `Qualified` to `Usable`. +* Upon the replacement key transitioning to `Usable`, the retiring key MUST transition to the `Frozen` state and cease generating new cosignatures. +* The retiring key MUST remain in the `Frozen` state, maintaining high-availability read access to mirrored log data, until all certificates relying upon its past cosignatures have expired or until it is transitioned to `Removed` in coordination with the CQRP. -[BCP 14](https://www.rfc-editor.org/info/bcp14), Best Current Practice 14. +The CQRP reserves the right to request adjustments to proposed state transition or key rotation timelines, or require additional information, to ensure the continued security, transparency, and operational stability of the ecosystem. New Mirroring Cosigners can be submitted to the CQRP by following Section 2. ("Submission Process") of [Preparing and Applying for Inclusion](https://googlechrome.github.io/chromerootprogram/cqrp/apply/). -[RFC 3647](https://datatracker.ietf.org/doc/html/rfc3647), Request for Comments: 3647, Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. S. Chokhani, W. Ford, R. Sabett, C. Merrill, S. Wu. November 2003. +## **References** + +Unless a specific revision or version tag is specified below, references to external specifications, standards, and requirements documents in this policy refer to the most recent published version, or any subsequent superseding release. Where a specific version of a specification is cited below, any transitive specifications it normatively references apply at the versions specified therein. + +[BCP 14](https://www.rfc-editor.org/info/bcp14), Best Current Practice 14 (RFC 2119, RFC 8174): Key words for use in RFCs to Indicate Requirement Levels. S. Bradner, B. Leiba. + +[RFC 3647](https://www.rfc-editor.org/info/rfc3647), Request for Comments: 3647, Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. S. Chokhani, W. Ford, R. Sabett, C. Merrill, S. Wu. + +[RFC 5280](https://www.rfc-editor.org/info/rfc5280), Request for Comments: 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk. [RFC 8555](https://www.rfc-editor.org/info/rfc8555), Request for Comments: 8555, Automatic Certificate Management Environment (ACME). R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten. @@ -663,21 +698,20 @@ The CQRP reserves the right to request adjustments to proposed state transition [RFC 9881](https://www.rfc-editor.org/info/rfc9881), Request for Comments: 9881, Internet X.509 Public Key Infrastructure Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA). J. Massimo, P. Kampanakis, S. Turner, B. E. Westerbaan. -[RFC 9935](https://datatracker.ietf.org/doc/rfc9935/), Request for Comments: 9935, Internet X.509 Public Key Infrastructure Algorithm Identifiers for the Key-Encapsulation Mechanism (ML-KEM). J. Massimo, P. Kampanakis, S. Turner, B. E. Westerbaan. - -DRAFT [ACME Profiles Extension](https://datatracker.ietf.org/doc/draft-ietf-acme-profiles/), Internet-Draft: draft-ietf-acme-profiles. A. Gable. [TODO: point to final/latest spec before v1.0.0 of this policy] +[RFC 9935](https://www.rfc-editor.org/info/rfc9935), Request for Comments: 9935, Internet X.509 Public Key Infrastructure Algorithm Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM). S. Turner, P. Kampanakis, J. Massimo, B. E. Westerbaan. -DRAFT [Merkle Tree Certificates](https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/), Internet-Draft: draft-ietf-plants-merkle-tree-certs. D. Benjamin, D. O'Brien, B. E. Westerbaan, L. Valenta, F. Valsorda. April 2026. [TODO: point to final/latest spec before v1.0.0 of this policy] +[ACME Profiles Extension](https://datatracker.ietf.org/doc/draft-ietf-acme-profiles/), Internet-Draft: draft-ietf-acme-profiles. A. Gable. -DRAFT [Merkle Tree Certificates With Tiled Transparency Logs](https://github.com/C2SP/C2SP/blob/main/mtc-tlog.md), [TODO: point to final/latest spec before v1.0.0 of this policy] +[Merkle Tree Certificates](https://datatracker.ietf.org/doc/html/draft-ietf-plants-merkle-tree-certs-07), Internet-Draft: draft-ietf-plants-merkle-tree-certs-07. D. Benjamin, D. O'Brien, B. E. Westerbaan. -DRAFT [Transparent Log Mirrors](https://github.com/C2SP/C2SP/blob/main/tlog-mirror.md), [TODO: point to final/latest spec before v1.0.0 of this policy] +[Merkle Tree Certificates With Tiled Transparency Logs](https://c2sp.org/mtc-tlog@v0.1.0), Community Cryptography Specification Project: mtc-tlog@v0.1.0. A. Gable, D. Benjamin, J. DeBlasio, M. McPherrin. -DRAFT [Tiled Transparency Logs](https://github.com/C2SP/C2SP/blob/main/tlog-tiles.md), [TODO: point to final/latest spec before v1.0.0 of this policy] +[Transparency Log Mirrors](https://c2sp.org/tlog-mirror@v0.1.0), Community Cryptography Specification Project: tlog-mirror@v0.1.0. A. Cutter, D. Benjamin, L. Valenta. -DRAFT [Transparency Log Cosignatures](https://github.com/C2SP/C2SP/blob/main/tlog-cosignature.md), [TODO: point to final/latest spec before v1.0.0 of this policy] +[Tiled Transparency Logs](https://c2sp.org/tlog-tiles@v1.0.0), Community Cryptography Specification Project: tlog-tiles@v1.0.0. R. Cox, F. Valsorda. -[Baseline Requirements](https://cabforum.org/baseline-requirements-documents/), CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. CA/Browser Forum. +[Transparency Log Cosignatures](https://c2sp.org/tlog-cosignature@v1.1.0), Community Cryptography Specification Project: tlog-cosignature@v1.1.0. A. Cutter, F. Valsorda, R. Dahlberg. -[Network and Certificate System Security Requirements](https://cabforum.org/working-groups/netsec/requirements/). CA/Browser Forum. +[Baseline Requirements](https://cabforum.org/baseline-requirements-documents/), CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates. CA/Browser Forum. +[Network and Certificate System Security Requirements](https://cabforum.org/working-groups/netsec/requirements/), CA/Browser Forum Network and Certificate System Security Requirements. CA/Browser Forum. From 97c9d771016b7befc033a83e23fdddff088c0de2 Mon Sep 17 00:00:00 2001 From: Chris Clements Date: Wed, 28 Oct 2026 13:05:42 -0400 Subject: [PATCH 07/15] Update testing.md Nit: change to mtcs [at] chromium [dot] org --- content/cqrp/testing.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/cqrp/testing.md b/content/cqrp/testing.md index 0e5d2fe..13df945 100644 --- a/content/cqrp/testing.md +++ b/content/cqrp/testing.md @@ -3,7 +3,7 @@ title: Chrome Quantum-resistant Root Program - Testing Instructions --- # Testing Instructions -## Last updated: October 16, 2026 +## Last updated: October 28, 2026 As [announced](https://blog.google/security/cultivating-a-robust-and-efficient-quantum-safe-https/) in February 2026, Chrome will not add traditional X.509 certificates containing post-quantum cryptography to its root store. Instead, Chrome will rely on Merkle Tree Certificates (MTCs) to mitigate the impact of post-quantum key and signature size increases while integrating transparency directly into the issuance process. @@ -97,10 +97,10 @@ Operators should also expect that Chrome monitors would verify that: 3. Mirrors provide consistent, append-only views of mirrored logs. 4. Log entries remain available for at least 35 days after the corresponding certificate's validity period ends. -Chrome may send notifications to the Operator when availability and correctness failures are observed. During the testing phase, these notifications are purely to support Operators in developing robust implementations, and we encourage (but do not require) sharing postmortems and development challenges or milestones to [mtcs@chromium.org](mailto:mtcs@chromium.org) so that everyone can benefit from lessons learned. +Chrome may send notifications to the Operator when availability and correctness failures are observed. During the testing phase, these notifications are purely to support Operators in developing robust implementations, and we encourage (but do not require) sharing postmortems and development challenges or milestones to mtcs [at] chromium [dot] org so that everyone can benefit from lessons learned. ### Where should I share my findings and feedback? -Please share your implementation experiences and challenges on [mtcs@chromium.org](mailto:mtcs@chromium.org)! The hope is that everyone in the ecosystem can benefit from these learnings. +Please share your implementation experiences and challenges on mtcs [at] chromium [dot] org! The hope is that everyone in the ecosystem can benefit from these learnings. ### What happens to my test setup when Phase 2 (production inclusion in the default Chrome Quantum-resistant Root Store) launches in 2027? The test setup can persist at the MTC CA Operators' discretion. We will maintain Chrome's testing infrastructure until Chrome accepts the first Phase 3 eligible MTC CA Operators. From 34fb31fb73cde8858586ecf15cba2d267307dd2e Mon Sep 17 00:00:00 2001 From: Chris Clements Date: Wed, 28 Oct 2026 13:19:08 -0400 Subject: [PATCH 08/15] Update ari-operational-test-report.schema.json Fixes applied: - sample_percentage in Schema: Changed "minimum": 3.0 to "exclusiveMinimum": 0.0 so CAs hitting the 100,000-certificate cap (on >3.33M eligible certificates) don't fail schema validation. - results.items.required in Schema: Added "renewal_timestamp" to the required array. - $id / $schema URLs: Changed /tree/main/ to /blob/main/ --- .../disclosures/ari-operational-test-report.schema.json | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/content/cqrp/disclosures/ari-operational-test-report.schema.json b/content/cqrp/disclosures/ari-operational-test-report.schema.json index b01fd32..c9e9f93 100644 --- a/content/cqrp/disclosures/ari-operational-test-report.schema.json +++ b/content/cqrp/disclosures/ari-operational-test-report.schema.json @@ -1,6 +1,6 @@ { "$schema": "https://json-schema.org/draft/2020-12/schema", - "$id": "https://github.com/GoogleChrome/chromerootprogram/tree/main/content/cqrp/disclosures/ari-operational-test-report.schema.json", + "$id": "https://github.com/GoogleChrome/chromerootprogram/blob/main/content/cqrp/disclosures/ari-operational-test-report.schema.json", "title": "MTC CA Operational ARI Test Report Schema", "description": "Schema for reporting quarterly operational ACME Renewal Information (ARI) client responsiveness test cycles.", "type": "object", @@ -65,9 +65,9 @@ }, "sample_percentage": { "type": "number", - "minimum": 3.0, + "exclusiveMinimum": 0.0, "maximum": 100.0, - "description": "Percentage of eligible certificates sampled (MUST be at least 3.0%)." + "description": "Percentage of eligible certificates sampled (SHOULD be at least 3.0%, unless the 100,000-certificate cap applies)." } }, "additionalProperties": false @@ -138,6 +138,7 @@ "issuance_log_entry_index", "ari_renewal_window", "outcome", + "renewal_timestamp", "time_to_renewal_seconds" ], "properties": { From 6436946bbcef50d1792abfe45132520d53824867 Mon Sep 17 00:00:00 2001 From: Chris Clements Date: Wed, 28 Oct 2026 13:21:08 -0400 Subject: [PATCH 09/15] Update ari-operational-test-report.json Parity with the fixes just applied to the schema. --- .../disclosures/ari-operational-test-report.json | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/cqrp/disclosures/ari-operational-test-report.json b/content/cqrp/disclosures/ari-operational-test-report.json index 5c31f50..5f529b4 100644 --- a/content/cqrp/disclosures/ari-operational-test-report.json +++ b/content/cqrp/disclosures/ari-operational-test-report.json @@ -1,5 +1,5 @@ { - "$schema": "https://github.com/GoogleChrome/chromerootprogram/tree/main/content/cqrp/disclosures/ari-operational-test-report.schema.json", + "$schema": "https://github.com/GoogleChrome/chromerootprogram/blob/main/content/cqrp/disclosures/ari-operational-test-report.schema.json", "test_cycle_id": "2026-Q3-ARI-TEST-01", "sample_selection": { "timestamp": "2026-08-05T00:00:00Z", @@ -18,10 +18,10 @@ { "software": "Certbot", "version": "2.6.0", - "total": 500, - "passed": 490, - "failed": 10, - "pass_rate_percentage": 98.0 + "total": 800, + "passed": 760, + "failed": 40, + "pass_rate_percentage": 95.0 }, { "software": "acme.sh", @@ -43,18 +43,18 @@ }, "results": [ { - "serial_number": "03A4F891BCDE0012", + "serial_number": "100000", "issuance_log_entry_index": 1048576, "ari_renewal_window": { "start": "2026-08-05T12:00:00Z", "end": "2026-08-08T12:00:00Z" }, "outcome": "pass", - "renewal_timestamp": "2026-08-05T16:00:00Z", + "renewal_timestamp": "2026-08-05T16:00:00Z", "time_to_renewal_seconds": 14400 }, { - "serial_number": "03A4F891BCDE0013", + "serial_number": "100001", "issuance_log_entry_index": 1048577, "ari_renewal_window": { "start": "2026-08-05T12:00:00Z", From 65afd952ae2311470563e2354831ebd357ef7e11 Mon Sep 17 00:00:00 2001 From: Chris Clements Date: Wed, 28 Oct 2026 13:35:07 -0400 Subject: [PATCH 10/15] Update draft-policy.md Nit: change 3 days to 72 hours --- content/cqrp/draft-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/cqrp/draft-policy.md b/content/cqrp/draft-policy.md index 777013c..330f268 100644 --- a/content/cqrp/draft-policy.md +++ b/content/cqrp/draft-policy.md @@ -641,7 +641,7 @@ Mirroring Cosigners MUST NOT prune any log entry with a serial number greater th Mirroring Cosigners MUST maintain high availability for both read and write operations: * Each mirror endpoint MUST maintain a request success rate (where a successful response is returned for a well-formed request) of at least 99.9% evaluated over any 72-hour period. This ensures sustained, low-grade request failures (e.g., due to rate limiting) are addressed independently of the 30-day overall requirement below. -* Each mirror endpoint MUST maintain a request success rate of at least 99.0% evaluated over any rolling 30-calendar-day period. This bounds cumulative downtime over a month and ensures that a single, large disruption, or a series of severe, non-consecutive outages, is addressed even if the system recovers in under 3 days. +* Each mirror endpoint MUST maintain a request success rate of at least 99.0% evaluated over any rolling 30-calendar-day period. This bounds cumulative downtime over a month and ensures that a single, large disruption, or a series of severe, non-consecutive outages, is addressed even if the system recovers in under 72 hours. Any Planned Maintenance that will interrupt these services MUST be publicly announced in advance in accordance with the definition of Planned Maintenance in this policy (note that Planned Maintenance only exempts write operations from the 72-hour availability requirement above; write operations MUST still meet the 30-calendar-day requirement, and read operations are not exempt from either requirement). From e1a08e803b2e6ab9c9550e2b6b6e13047cca6c35 Mon Sep 17 00:00:00 2001 From: Chris Clements Date: Wed, 28 Oct 2026 13:37:50 -0400 Subject: [PATCH 11/15] Update apply.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Nits: - change `facility_certification` to `facility_certification_url` so it matches the actual property name in mtc-disclosures.schema.json. - publicly-accessible Repository → publicly accessible Repository to match the unhyphenated style in the Policy. --- content/cqrp/apply.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/cqrp/apply.md b/content/cqrp/apply.md index 576cb6e..7bb38d8 100644 --- a/content/cqrp/apply.md +++ b/content/cqrp/apply.md @@ -24,7 +24,7 @@ As detailed in Section 1.1. ("Eligibility") of the CQRP Policy, initial eligibil > [!NOTE] > Beginning in 2027H2, a future update to the CQRP Policy is expected to allow organizations that do not meet the initial eligibility restrictions above to apply for inclusion. Those prospective operators will be required to demonstrate reliable, high-availability and consistent operation of their Mirroring Cosigner in the CQRS for a specified period before their CA Cosigners will be considered for inclusion as an MTC CA Operator. -Though eligible CQRS Applicants are preferred to submit a complete inclusion request covering both their Mirroring Cosigner and CA Cosigner operations simultaneously, the CQRP recognizes the technical and operational effort required to deploy a complete MTC infrastructure. To help bootstrap ecosystem mirroring availability and allow operators to gain operational experience incrementally, an eligible CQRS Applicant may initially submit an inclusion request populating only the required Operator and Mirroring Cosigner fields, deferring the CA Cosigner artifacts to a subsequent update. In this case, the CQRS Applicant may omit the `facility_certification` and all `ca_cosigner_keys` information from their `mtc-disclosures.json` until applying as an MTC CA Operator. +Though eligible CQRS Applicants are preferred to submit a complete inclusion request covering both their Mirroring Cosigner and CA Cosigner operations simultaneously, the CQRP recognizes the technical and operational effort required to deploy a complete MTC infrastructure. To help bootstrap ecosystem mirroring availability and allow operators to gain operational experience incrementally, an eligible CQRS Applicant may initially submit an inclusion request populating only the required Operator and Mirroring Cosigner fields, deferring the CA Cosigner artifacts to a subsequent update. In this case, the CQRS Applicant may omit the `facility_certification_url` and all `ca_cosigner_keys` information from their `mtc-disclosures.json` until applying as an MTC CA Operator. However, this staged onboarding path is time-bounded. An operator that initially enters the CQRS solely as a Mirroring Operator must submit a complete MTC CA Operator inclusion update within 3 years of its Mirroring Cosigner first being accepted into the CQRS. If the operator does not submit the required CA Cosigner materials within this 3-year window, or it fails to progress to MTC CA Operator inclusion, the operator should expect its Mirroring Cosigner to be phased out (transitioned to `Frozen` and subsequently `Removed`) from the CQRS. @@ -34,7 +34,7 @@ However, this staged onboarding path is time-bounded. An operator that initially CQRS inclusion requests are submitted using the New MTC Operator template in the [Chromium Issues Tracker](https://issues.chromium.org/issues/new?component=2114629&template=2386551). By creating a new issue in the Chromium Issues Tracker, the entity is asserting it is organizationally distinct from all existing operators present in [cosigners.json](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json). -All application artifacts need to be hosted from a publicly-accessible Repository (as defined within the Baseline Requirements). At any point during its review, the CQRP may contact the operator seeking additional or clarifying information. Operators are expected to provide the requested information promptly, and no later than 14 days unless specified otherwise. +All application artifacts need to be hosted from a publicly accessible Repository (as defined within the Baseline Requirements). At any point during its review, the CQRP may contact the operator seeking additional or clarifying information. Operators are expected to provide the requested information promptly, and no later than 14 days unless specified otherwise. ### **2.2. Updating Submissions** From c0a8e1b955432b4536968688d4437beafc9cee64 Mon Sep 17 00:00:00 2001 From: Chris Clements Date: Wed, 28 Oct 2026 13:42:35 -0400 Subject: [PATCH 12/15] Update mtc-disclosures.schema.json - Support staged Mirroring-first onboarding by allowing `ca_cosigner_keys` and `global_disclosures.facility_certification_url` to be omitted until applying as an MTC CA Operator (enforced conditionally via `if`/`then` when `ca_cosigner_keys` is present). - Update `policy_documents_url` and `facility_certification_url` descriptions to reflect the combined CP/CPS and accepted facility certification frameworks (ISO/IEC 27001, SOC 2 Type II / SOC 3). - Add `minLength: 1` validation to `operator_name` and `friendly_name`. - Update `$id` URL from `/tree/main/` to `/blob/main/`. --- .../disclosures/mtc-disclosures.schema.json | 38 +++++++++++++------ 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/content/cqrp/disclosures/mtc-disclosures.schema.json b/content/cqrp/disclosures/mtc-disclosures.schema.json index 979c9d8..051ee42 100644 --- a/content/cqrp/disclosures/mtc-disclosures.schema.json +++ b/content/cqrp/disclosures/mtc-disclosures.schema.json @@ -1,14 +1,13 @@ { "$schema": "https://json-schema.org/draft/2020-12/schema", - "$id": "https://github.com/GoogleChrome/chromerootprogram/tree/main/content/cqrp/disclosures/mtc-disclosures.schema.json", + "$id": "https://github.com/GoogleChrome/chromerootprogram/blob/main/content/cqrp/disclosures/mtc-disclosures.schema.json", "title": "MTC CA Operator Disclosures Schema", - "description": "Schema for MTC CA Operator disclosures supporting per-key and global disclosure URLs.", + "description": "Schema for MTC CA and Mirroring Operator disclosures supporting per-key and global disclosure URLs.", "type": "object", "required": [ "operator_name", "last_updated", - "global_disclosures", - "ca_cosigner_keys" + "global_disclosures" ], "properties": { "$schema": { @@ -17,7 +16,8 @@ }, "operator_name": { "type": "string", - "description": "Legal name of the MTC CA Operator." + "minLength": 1, + "description": "Legal name of the Operator." }, "last_updated": { "type": "string", @@ -26,18 +26,17 @@ }, "global_disclosures": { "type": "object", - "description": "Operator-wide disclosures applicable across all CA Cosigner Keys.", + "description": "Operator-wide disclosures applicable across all operations and CA Cosigner Keys.", "required": [ "ca_repository_url", "legal_entity_and_ownership_url", - "operational_status_url", - "facility_certification_url" + "operational_status_url" ], "properties": { "ca_repository_url": { "type": "string", "format": "uri", - "description": "URL to the CA Operator's public repository where items like policy documents, Subscriber agreements, and historical revisions reside." + "description": "URL to the Operator's public repository where items like policy documents, Subscriber agreements, certificate profiles, and historical revisions reside." }, "legal_entity_and_ownership_url": { "type": "string", @@ -52,14 +51,14 @@ "facility_certification_url": { "type": "string", "format": "uri", - "description": "URL to ISO/IEC 27001 or equivalent facility audit certification." + "description": "URL to ISO/IEC 27001, AICPA SOC 2 Type II / SOC 3, or equivalent facility audit certification. Required when applying or operating as an MTC CA Operator." } }, "additionalProperties": false }, "ca_cosigner_keys": { "type": "array", - "description": "List of disclosures specific to each CA Cosigner Key operated by the CA.", + "description": "List of disclosures specific to each CA Cosigner Key included in the CQRS. May be omitted by applicants initially onboarding solely as a Mirroring Operator.", "minItems": 1, "items": { "type": "object", @@ -71,6 +70,7 @@ "properties": { "friendly_name": { "type": "string", + "minLength": 1, "description": "Human-readable name for the CA Cosigner Key." }, "key_sha256": { @@ -93,7 +93,7 @@ "policy_documents_url": { "type": "string", "format": "uri", - "description": "URL to the Markdown/AsciiDoc CP/CPS for this specific key." + "description": "URL to the Markdown/AsciiDoc combined CP/CPS governing this key." }, "reserve_keys_url": { "type": "string", @@ -143,5 +143,19 @@ } } }, + "if": { + "required": [ + "ca_cosigner_keys" + ] + }, + "then": { + "properties": { + "global_disclosures": { + "required": [ + "facility_certification_url" + ] + } + } + }, "additionalProperties": false } From c4f803fa83e44fcec53439d0159a94b35c504f89 Mon Sep 17 00:00:00 2001 From: Chris Clements Date: Wed, 28 Oct 2026 13:43:50 -0400 Subject: [PATCH 13/15] Update mtc-disclosures.json Match the schema changes. --- content/cqrp/disclosures/mtc-disclosures.json | 38 +++++++++++++++---- 1 file changed, 31 insertions(+), 7 deletions(-) diff --git a/content/cqrp/disclosures/mtc-disclosures.json b/content/cqrp/disclosures/mtc-disclosures.json index ac69db2..bea1521 100644 --- a/content/cqrp/disclosures/mtc-disclosures.json +++ b/content/cqrp/disclosures/mtc-disclosures.json @@ -1,5 +1,5 @@ { - "$schema": "https://github.com/GoogleChrome/chromerootprogram/tree/main/content/cqrp/disclosures/mtc-disclosures.schema.json", + "$schema": "https://github.com/GoogleChrome/chromerootprogram/blob/main/content/cqrp/disclosures/mtc-disclosures.schema.json", "operator_name": "Example Security CA Inc.", "last_updated": "2026-08-05T10:00:00Z", "global_disclosures": { @@ -10,11 +10,11 @@ }, "ca_cosigner_keys": [ { - "friendly_name": "Example MTC CA 2026 7-Day Key 1", + "friendly_name": "Example MTC CA 2026 7-Day Active Key 1", "key_sha256": "40328aac349197c2daccd7b8ca66b17f3e44d2d5fa66acc7d0a8c2924802fbfa", "disclosures": { - "policy_documents_url": "https://github.com/example-ca/pki-repository/blob/main/CPS-7day.md", - "reserve_keys_url": "https://github.com/example-ca/pki-repository/blob/main/upcoming_keys_7day.json", + "policy_documents_url": "https://github.com/example-ca/pki-repository/blob/main/CP-CPS.md", + "reserve_keys_url": "https://github.com/example-ca/pki-repository/blob/main/reserve_keys.json", "key_generation_attestation_url": "https://example-ca.com/audits/2026-key1-attestation.pdf", "infrastructure_architecture_url": "https://github.com/example-ca/pki-repository/blob/main/arch-key1.md", "full_crl_urls": [ @@ -24,11 +24,11 @@ } }, { - "friendly_name": "Example MTC CA 2026 47-Day Key 2", + "friendly_name": "Example MTC CA 2026 47-Day Active Key 2", "key_sha256": "8f3b211a549197c2daccd7b8ca66b17f3e44d2d5fa66acc7d0a8c2924802eabc", "disclosures": { - "policy_documents_url": "https://github.com/example-ca/pki-repository/blob/main/CPS-47day.md", - "reserve_keys_url": "https://github.com/example-ca/pki-repository/blob/main/upcoming_keys_47day.json", + "policy_documents_url": "https://github.com/example-ca/pki-repository/blob/main/CP-CPS.md", + "reserve_keys_url": "https://github.com/example-ca/pki-repository/blob/main/reserve_keys.json", "key_generation_attestation_url": "https://example-ca.com/audits/2026-key2-attestation.pdf", "infrastructure_architecture_url": "https://github.com/example-ca/pki-repository/blob/main/arch-key2.md", "facility_certification_url": "https://example-ca.com/compliance/iso27001-secondary-dc.pdf", @@ -38,6 +38,30 @@ "http://crl.example-ca.com/mtc-2026-47day-key2-p2.crl" ] } + }, + { + "friendly_name": "Example MTC CA 2026 Reserve Key 1", + "key_sha256": "c19a440b712397c2daccd7b8ca66b17f3e44d2d5fa66acc7d0a8c29248029901", + "disclosures": { + "policy_documents_url": "https://github.com/example-ca/pki-repository/blob/main/CP-CPS.md", + "reserve_keys_url": "https://github.com/example-ca/pki-repository/blob/main/reserve_keys.json", + "key_generation_attestation_url": "https://example-ca.com/audits/2026-reserve1-attestation.pdf", + "infrastructure_architecture_url": "https://github.com/example-ca/pki-repository/blob/main/arch-reserve1.md", + "full_crl_urls": [], + "partitioned_crl_urls": [] + } + }, + { + "friendly_name": "Example MTC CA 2026 Reserve Key 2", + "key_sha256": "d28b551c823497c2daccd7b8ca66b17f3e44d2d5fa66acc7d0a8c29248029902", + "disclosures": { + "policy_documents_url": "https://github.com/example-ca/pki-repository/blob/main/CP-CPS.md", + "reserve_keys_url": "https://github.com/example-ca/pki-repository/blob/main/reserve_keys.json", + "key_generation_attestation_url": "https://example-ca.com/audits/2026-reserve2-attestation.pdf", + "infrastructure_architecture_url": "https://github.com/example-ca/pki-repository/blob/main/arch-reserve2.md", + "full_crl_urls": [], + "partitioned_crl_urls": [] + } } ] } From 3038824739248f3008b8682b295c3621760ac6c3 Mon Sep 17 00:00:00 2001 From: Ryan Dickson Date: Wed, 28 Oct 2026 14:15:01 -0400 Subject: [PATCH 14/15] Update Python version to 3.13 in workflow --- .github/workflows/pages.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/pages.yaml b/.github/workflows/pages.yaml index 182d85b..d12081c 100644 --- a/.github/workflows/pages.yaml +++ b/.github/workflows/pages.yaml @@ -30,7 +30,7 @@ jobs: - name: Set up Python uses: actions/setup-python@42375524e23c412d93fb67b49958b491fce71c38 # v5.4.0 with: - python-version: '3.13.1' + python-version: '3.13' cache: 'pipenv' # Install pipenv From a3e33af4b6347e8c70c267f38b4f580aa3943ce4 Mon Sep 17 00:00:00 2001 From: Ryan Dickson Date: Wed, 28 Oct 2026 14:15:36 -0400 Subject: [PATCH 15/15] Update Python version in Pipfile --- Pipfile | 1 - 1 file changed, 1 deletion(-) diff --git a/Pipfile b/Pipfile index a2a6c8e..10e1e2d 100644 --- a/Pipfile +++ b/Pipfile @@ -12,4 +12,3 @@ pyyaml = "*" [requires] python_version = "3.13" -python_full_version = "3.13.1"