diff --git a/.github/workflows/pages.yaml b/.github/workflows/pages.yaml index 2da9708..182d85b 100644 --- a/.github/workflows/pages.yaml +++ b/.github/workflows/pages.yaml @@ -2,7 +2,6 @@ name: Build and Deploy Site # Controls when the workflow will run on: - # Triggers the workflow on push or pull request events but only for the "main" branch push: branches: [ "main" ] pull_request: @@ -11,23 +10,27 @@ on: # Allows you to run this workflow manually from the Actions tab workflow_dispatch: +permissions: + contents: read + # A workflow run is made up of one or more jobs that can run sequentially or in parallel jobs: # This workflow contains two jobs: "build" and "deploy" build: - # The type of runner that the job will run on runs-on: ubuntu-latest + permissions: + contents: read - # Steps represent a sequence of tasks that will be executed as part of the job steps: - # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it - - uses: actions/checkout@v4 + - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 + with: + persist-credentials: false # Install Python - name: Set up Python - uses: actions/setup-python@v4 + uses: actions/setup-python@42375524e23c412d93fb67b49958b491fce71c38 # v5.4.0 with: - python-version: '3.13.1' # Change this to your desired Python version + python-version: '3.13.1' cache: 'pipenv' # Install pipenv @@ -48,13 +51,14 @@ jobs: # Upload site, does not deploy - name: Upload static files as artifact id: deployment - uses: actions/upload-pages-artifact@v3 # or specific "vX.X.X" version tag for this action + uses: actions/upload-pages-artifact@56afc609e74202658d3ffba0e8f6dda462b719fa # v3.0.1 with: path: output_html/ # Deployment job deploy: needs: build + if: github.ref == 'refs/heads/main' # Grant GITHUB_TOKEN the permissions required to make a Pages deployment permissions: @@ -67,4 +71,4 @@ jobs: steps: - name: Deploy to GitHub Pages id: deployment - uses: actions/deploy-pages@v4 # or specific "vX.X.X" version tag for this action + uses: actions/deploy-pages@d6db90164ac5ed86f2b6aed7e0febac5b3c0c03e # v4.0.5 diff --git a/README.md b/README.md index 5e2128d..9665bd9 100644 --- a/README.md +++ b/README.md @@ -1,39 +1,29 @@ -# Chrome Root Program +# Google Chrome Root Programs Google Chrome relies on Certification Authority systems ("CAs") to issue certificates to websites. Chrome uses these certificates to help ensure the connections it makes on behalf of its users are properly secured. Chrome accomplishes this by verifying that a website's certificate was issued by a recognized CA, while also performing additional evaluations of the HTTPS connection's security properties. Certificates not issued by a CA recognized by Chrome or a user's local settings can cause users to see warnings and error pages. -When making HTTPS connections, Chrome refers to a list of root certificates from CAs that have demonstrated why continued trust in them is justified. This list is known as a "Root Store." CA certificates included in the [Chrome Root Store](https://g.co/chrome/root-store) are selected on the basis of publicly available and verified information, such as that within the Common CA Database ([CCADB](https://ccadb.org/)), and ongoing reviews by the Chrome Root Program. +To secure the web today and prepare for the post-quantum future, Chrome operates two distinct root programs: -In Chrome 105, Chrome began a platform-by-platform transition from relying on the host operating system's Root Store to its own on Windows, macOS, ChromeOS, Linux, and Android. This change makes Chrome more secure and promotes consistent user and developer experiences across platforms. Apple policies prevent the Chrome Root Store and corresponding Chrome Certificate Verifier from being used on Chrome for iOS. Learn more about the Chrome Root Store and Chrome Certificate Verifier [here](https://chromium.googlesource.com/chromium/src/+/main/net/data/ssl/chrome_root_store/faq.md). +* **[The Chrome Root Program](content/crp/policy.md)**: [Launched in 2022](https://blog.chromium.org/2022/09/announcing-launch-of-chrome-root-program.html), this program establishes the minimum requirements for self-signed root CA certificates to be included in the [Chrome Root Store](https://g.co/chrome/root-store) by default, providing consistent and reliable security for HTTPS connections across platforms. The authoritative policy is available at [https://g.co/chrome/root-policy](https://g.co/chrome/root-policy). +* **[The Chrome Quantum-resistant Root Program](content/cqrp/draft-policy.md)**: Designed for the post-quantum era, this program uses Merkle Tree Certificates (MTCs) to deliver quantum-safe security without slowing down page connections. Learn more about Google's planned adoption of MTCs on the [Google Security Blog](https://blog.google/security/cultivating-a-robust-and-efficient-quantum-safe-https/). -The Chrome Root Program Policy establishes the minimum requirements for self-signed root CA certificates to be included as trusted in a default installation of Chrome. This GitHub repository contains a Markdown-formatted version of the authoritative version available [here](https://g.co/chrome/root-policy). +Any questions regarding the Chrome Root Program can be directed to `chrome-root-program [at] google [dot] com`. -Any questions regarding the Chrome Root Program Policy can be directed to chrome-root-program [at] google [dot] com. +Any questions regarding the Chrome Quantum-Resistant Root Program can be directed to `chrome-quantum-resistant-root-program [at] google [dot] com`. -## Updating the Policy +## Updating the CRP Policy -The site is deployed on commits to `main`. To add a new policy revision: +The site is deployed automatically on commits to `main`. To add a new Chrome Root Program policy revision: -- Archive the current version in `content/policy-archive/` (create the directory - and copy it to the proper index.md file). +- Archive the current version in `content/policy-archive/` (create the directory and copy the current policy to the proper version file). - Update `config.yaml`: - - Update `context.versions` array so that the path for the now archived - version is no longer marked as `current` - - Add a new entry at the bottom of the array for the next version, with an - archive path, `path: content/policy-archive/policy-version-NEW-VERSION`. - The file and folder do not need to exist. - - Bump `context.current_version` to the next version value. It should match - the version number in at the end of the versions array. Be sure all version - numbers are in quotes so they are interpreted as strings, not floats. -- Update `content/index.md` with the new content. This way the PR will show a - diff of the new policies in index.md. + - Update `context.versions` array so that the path for the now archived version is no longer marked as `current`. + - Add a new entry at the bottom of the array for the next version, with an archive path, `path: content/policy-archive/policy-version-NEW-VERSION`. + - Bump `context.current_version` to the next version value. It should match the version number at the end of the versions array. Be sure all version numbers are in quotes so they are interpreted as strings, not floats. +- Update `content/crp/policy.md` with the new policy content. This can all be done in a single pull request. The diff in the PR will show the diff between the two policy versions. ### A note on links -Links in Markdown to other documents in this repository should end in `md`, e.g. -`[Policy](index.md)`. Links in raw HTML, e.g. `` should not. This make the links in the Github UI -work for Markdown, and results in a correctly-compiled site. Hardcoded HTML -links will not resolve correctly in previews. +Links in Markdown to other documents in this repository should end in `.md`, e.g. `[Policy](content/crp/policy.md)`. Links in raw HTML, e.g. `` should not. This makes the links in the GitHub UI work for Markdown while also resulting in a correctly compiled static site. Hardcoded HTML links will not resolve correctly in previews. diff --git a/content/cqrp/apply.md b/content/cqrp/apply.md new file mode 100644 index 0000000..0d64b47 --- /dev/null +++ b/content/cqrp/apply.md @@ -0,0 +1,6 @@ +--- +title: Chrome Quantum-resistant Root Program - Apply for Inclusion +--- +# Apply for Inclusion + +Coming soon. diff --git a/content/cqrp/draft-policy.md b/content/cqrp/draft-policy.md new file mode 100644 index 0000000..705cac8 --- /dev/null +++ b/content/cqrp/draft-policy.md @@ -0,0 +1,6 @@ +--- +title: Chrome Quantum-resistant Root Program Policy +--- +# Chrome Quantum-resistant Root Program Policy + +Coming soon. diff --git a/content/cqrp/faq.md b/content/cqrp/faq.md new file mode 100644 index 0000000..bc723d1 --- /dev/null +++ b/content/cqrp/faq.md @@ -0,0 +1,25 @@ +--- +title: Chrome Quantum-resistant Root Program - Frequently Asked Questions +--- +# Frequently Asked Questions + +[TOC] + +### Does Chrome support use of ML-DSA certificates? +Yes. Beginning in [Chrome 150](https://chromestatus.com/feature/5174590524489728), Chrome supports ML-DSA in private PKI hierarchies, making it possible to test non-MTC post-quantum X.509 certificates locally or within enterprise environments. + +### Why does Chrome not support ML-DSA in the Chrome Quantum-resistant Root Store? +Post-quantum cryptographic algorithms such as ML-DSA feature significantly larger key and signature sizes than classical algorithms (like RSA or ECDSA). In a traditional PKI model using X.509 certificates, sending heavy, serialized chains of post-quantum signatures and Certificate Transparency (CT) proofs during every TLS handshake creates severe bandwidth penalties and increases connection latency across the web. + +Instead of traditional X.509 chains, Chrome uses **Merkle Tree Certificates (MTCs)** developed in the [IETF PLANTS working group](https://datatracker.ietf.org/group/plants/about/): + +* **Lightweight Proofs**: CAs sign a single "Tree Head" representing millions of certificates. The server sends only a compact Merkle Tree proof of inclusion rather than full signature chains. +* **Decoupled Payload Size**: Cryptographic strength is decoupled from transmitted data size, preserving fast handshake speeds. +* **Built-in Transparency**: Transparency is an intrinsic property of MTC issuance, making it impossible to issue a certificate without including it in a public tree, eliminating the need for extra CT overhead in the TLS handshake. + +### When will MTCs be usable in Chrome? +Chrome's rollout of Merkle Tree Certificates spans three distinct phases: + +- **Phase 1 (Underway)**: Feasibility study conducted in collaboration with Cloudflare to evaluate real-world performance and security of MTC connections. Experimental MTC connections are dual-backed by traditional X.509 certificates for safe fallback. +- **Phase 2 (Target: Q1 2027)**: Initial public MTC bootstrapping. Qualified CT Log operators (operating usable CT logs in Chrome prior to February 1, 2026) will be invited to participate in running initial public MTC issuance logs and mirrors. +- **Phase 3 (Target: Q3 2027)**: Launch of the Chrome Quantum-resistant Root Store (CQRS) and onboarding of prospective MTC CA Operators under the Chrome Quantum-resistant Root Program Policy. This phase will also introduce optional downgrade protections for sites using quantum-resistant certificates. diff --git a/content/cqrp/root-store.md b/content/cqrp/root-store.md new file mode 100644 index 0000000..e9d9e7d --- /dev/null +++ b/content/cqrp/root-store.md @@ -0,0 +1,164 @@ +--- +title: Chrome Quantum-resistant Root Program - CQRP Root Store +--- + +# CQRP Root Store + +Below is the list of **MTC CA Cosigners** and **Mirror Cosigners** included in the Chrome Quantum-resistant Root Store. + +Data is fetched directly from [`https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json`](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json). + +
+ ⏳ Loading cosigners data... +
+ + + + + + diff --git a/content/cqrp/testing.md b/content/cqrp/testing.md new file mode 100644 index 0000000..3334ecd --- /dev/null +++ b/content/cqrp/testing.md @@ -0,0 +1,105 @@ +--- +title: Chrome Quantum-resistant Root Program - Testing Instructions +--- +# Testing Instructions + +## Last updated: July 17, 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. + +To support development and interoperability with Chrome, we are providing a mechanism to submit non-production cosigners for inclusion in Chrome to be used for general testing and validation. Applications will begin in July 2026, and will be open to any organization currently operating either traditional root CAs or CT logs included in Chrome. + +This FAQ aims to provide clarity on the test and validation trust store. + +## Frequently Asked Questions (FAQ) + +[TOC] + +### Does Chrome support use of ML-DSA certificates? +Yes. Beginning in [Chrome 150](https://chromestatus.com/feature/5174590524489728), Chrome supports ML-DSA in private PKI hierarchies, making it possible to test non-MTC post-quantum X.509 certificates locally or within enterprise environments. + +### What is Chrome providing for testing? +We are offering a dedicated MTC root store explicitly for the purposes of end-to-end testing and validation. This test root store will be delivered to Chrome clients, but not trusted for production use. Instead, Chrome clients can be individually configured to enable trust of MTCs from these specific test issuers. Chrome M152 is expected to have support for testing Standalone and Landmark-relative MTCs. + +Additionally, Chrome may monitor the logs included in this testing phase for availability and correctness, similar to how it currently monitors CT logs. + +### How can I request access to include my organization's cosigners in the testing root store and when will that access be provided? +Organizations currently operating either traditional root CAs or CT logs included in Chrome can request the inclusion of testing cosigners by creating a new issue in the [Chromium Issue Tracker](https://issues.chromium.org/) (use the *New Test MTC CA Operator* template). + +Chrome will begin processing requests starting July 31, 2026, and aim to include these cosigner keys in the test root store within two weeks of reviewing the request. We will follow up on the issue tracker once the root store has been updated. + +### How do I enable the testing root store in Chrome? +The testing root store is only supported in Chrome 152 or later (currently Chrome Canary). + +You can enable the experimental features using `chrome://flags`: + +1. Open Chrome Canary and navigate to `chrome://flags`. +2. Search for and enable the following two flags: + - **`verify-mtcs`** + - **`test-root-store`** +3. Click **Relaunch** at the bottom of the page. + +MTC test root store anchors and cosigner metadata are updated dynamically via Chrome’s Component Updater: + +1. Navigate to `chrome://components`. +2. Locate the **PKI Metadata Fastpush** component. +3. Click **Check for update**. +4. Wait until the status displays **Component updated** or **Up-to-date**. +5. Relaunch Chrome to ensure the newly downloaded test anchors are loaded. + +### How can I verify that my connection is using an MTC? +To verify that your site successfully established a connection using MTCs: + +1. Open DevTools (`F12` or `Cmd` + `Option` + `I`). +2. Go to the **Security** tab and refresh the page. +3. Under **Connection Details**, confirm the negotiated algorithms: + - **Signature / Cosignature Algorithm**: `ML-DSA-44` (or different) + - **Key Exchange**: `X25519MLKEM768` (ML-KEM) + +### What can I expect `cosigners.json` to include? +The JSON can be found at: [https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json). + +- This file respects the schema provided at: [https://www.gstatic.com/mtcs/cosigners/v1/cosigners_schema.json](https://www.gstatic.com/mtcs/cosigners/v1/cosigners_schema.json). +- Keys referenced in the JSON are available at: [https://www.gstatic.com/mtcs/cosigners/v1/cosigners.pem](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.pem). + +### Are constraints such as certificate lifetimes and algorithms strictly enforced in testing? +Yes. Testing certificates will be subject to the same validation logic as production certificates. This includes restrictions to 7-day or 47-day maximum validity. For both Mirroring and CA Cosigners, we will accept only **ML-DSA-44** (OID: `2.16.840.1.101.3.4.3.17`, RFC 9881) cosigning keys. There is no equivalent key restriction on the test Subscriber certificates. + +Though not technically enforced by the client, practices such as the use of strict domain control validation or the use of Hardware Security Modules are encouraged to maximize the value of this testing infrastructure. + +### Am I required to run a mirror during the testing phase? +Yes. As Chrome will be enforcing realistic cosigner requirements (e.g., requiring mirroring cosignatures on Standalone certificates), we ask that participants in the testing phase contribute a Mirroring Cosigner usable by all CA Cosigners to ensure adequate and realistic mirroring capacity is available. + +The CA Cosigner issuance log should 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/) (specifically `draft-ietf-plants-merkle-tree-certs-05`) and the `tlog-tiles` [specification](https://github.com/C2SP/C2SP/blob/main/tlog-tiles.md). The Mirroring Cosigner should implement the API endpoints, cryptographic formats, and validation logic defined in the MTC specification and the `tlog-mirror` [specification](https://github.com/C2SP/C2SP/blob/main/tlog-mirror.md). + +### How many cosignatures are required for Chrome to validate my test certificate? +Chrome clients will enforce the same cosignature requirements to validate a certificate in the testing phase as with production certificates. Standalone certificates must have at least two cosignatures. One must be from the MTC CA Operator, and one must be from a Mirroring Cosigner recognized by the Chrome test root store. Chrome's servers will similarly ensure that issuer logs are mirrored before trusting subtrees for Landmark-relative certificates. + +### What exactly might Chrome monitor for "availability and correctness"? +Chrome’s compliance monitoring infrastructure may continuously query both the test MTC CA issuance logs and Mirroring Cosigner endpoints throughout their lifetime. The monitoring would focus on uptime metrics, cryptographic integrity, and adherence to technical specifications, intending to be a feedback loop for MTC CA Operators from Chrome. + +Development on Chrome's monitoring infrastructure is ongoing, but Operators can expect that Chrome would monitor for availability and uptime by looking for: + +1. Endpoints (both issuance logs and mirrors) maintaining at least 99% uptime over a 30-day rolling window (no more than 7.2 hours of downtime per month). +2. Endpoints not experiencing a daily uptime below 99.9% for more than 3 consecutive days. +3. A majority of mirror checkpoints remaining within a few minutes of the current issuer checkpoint. + +Operators should also expect that Chrome monitors would verify that: + +1. API endpoints, cryptographic formats, and validation logic all match the definitions in the MTC [specification](https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/), as well as the [tlog-tiles](https://github.com/C2SP/C2SP/blob/main/tlog-tiles.md) (for CAs) and [tlog-mirror](https://github.com/C2SP/C2SP/blob/main/tlog-mirror.md) (for mirrors) specifications. +2. Merkle trees served cryptographically validate. +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. + +### 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. + +### 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. + +Notably, cosigner keys accepted as part of the testing trust store will not be accepted for production use in Chrome. MTC CA Operators will need to generate new cosigner keys and fully adhere to the CQRP Policy to be included in Phase 2 or later launches. + +### How are approved test CAs and mirrors designated in `cosigners.json`? +All cosigners approved for the testing phase are included in [`cosigners.json`](https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json) with a `realm` property of `"UNTRUSTED_VALIDATION_ONLY"`. This explicitly distinguishes test cosigners from production CAs (`"PUBLICLY_TRUSTED"`), ensuring Chrome clients restrict test keys to validation testing only and never trust them for production certificate validation. diff --git a/content/apply-for-inclusion.md b/content/crp/apply-for-inclusion.md similarity index 90% rename from content/apply-for-inclusion.md rename to content/crp/apply-for-inclusion.md index 358f16d..9f953e9 100644 --- a/content/apply-for-inclusion.md +++ b/content/crp/apply-for-inclusion.md @@ -1,5 +1,5 @@ --- -title: Apply for Inclusion +title: Chrome Root Program - Apply for Inclusion --- # Apply for Inclusion @@ -11,11 +11,11 @@ Because of this significant and inherent security risk, our Chrome Root Store in Google includes or removes self-signed root CA certificates in the Chrome Root Store as it deems appropriate at its sole discretion. The selection and ongoing inclusion of CA certificates is done to enhance the security of Chrome. CA certificates included in the Chrome Root Store must provide value to Chrome end users that clearly exceeds the risk of their continued inclusion. -To that end, the Chrome Root Program Policy defines the [minimum requirements](../index) that must be met by CA Owners for both initial and continued inclusion in the Chrome Root Store. The policy is periodically updated to further promote the Chrome Root Program's goals of [security, agility, and simplicity](../moving-forward-together). Generally, all pending inclusion applications submitted to Google Chrome in the Common CA Database (CCADB) should adhere to the latest version of the Chrome Root Program Policy, including any specific criteria for Applicants. If an existing inclusion application submitted in the CCADB doesn't meet the requirements of a revised policy or updated Applicant-specific criteria, the CA Owner should request a reversion of their CCADB case status back to "CA Providing Data." This allows the CA Owner to modify their inclusion application and demonstrate sufficient alignment with the current policy and requirements. +To that end, the Chrome Root Program Policy defines the [minimum requirements](policy.md) that must be met by CA Owners for both initial and continued inclusion in the Chrome Root Store. The policy is periodically updated to further promote the Chrome Root Program's goals of [security, agility, and simplicity](moving-forward-together.md). Generally, all pending inclusion applications submitted to Google Chrome in the Common CA Database (CCADB) should adhere to the latest version of the Chrome Root Program Policy, including any specific criteria for Applicants. If an existing inclusion application submitted in the CCADB doesn't meet the requirements of a revised policy or updated Applicant-specific criteria, the CA Owner should request a reversion of their CCADB case status back to "CA Providing Data." This allows the CA Owner to modify their inclusion application and demonstrate sufficient alignment with the current policy and requirements. ### Inclusion Processing -The Chrome Root Program and corresponding Root Store processes inclusion applications and requests for changes through the CCADB. CA Owners who satisfy all of the requirements in the Chrome Root Program [Policy](../index) may apply. +The Chrome Root Program and corresponding Root Store processes inclusion applications and requests for changes through the CCADB. CA Owners who satisfy all of the requirements in the Chrome Root Program [Policy](policy.md) may apply. The application process includes: @@ -63,7 +63,7 @@ While not a comprehensive list, the following behaviors can serve as positive in * Utilizing partitioned CRLs for serving TLS server authentication certificate status information to make revocation checking faster, more cost-effective, and more reliable. * Operating a publicly accessible test infrastructure that mirrors the production environment to facilitate proactive testing of new features, policy changes, and client behaviors. * Randomizing the use of subordinate CAs for issuing TLS server authentication certificates to discourage harmful practices like [Key Pinning](https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning). -* Leveraging operational practices consistent with those described in [Moving Forward, Together](../moving-forward-together). +* Leveraging operational practices consistent with those described in [Moving Forward, Together](moving-forward-together.md). * Proactively implementing security controls and operational practices that exceed the minimum requirements established in the CA/Browser Forum TLS Baseline Requirements. **Indicators of a public-serving mission** @@ -79,7 +79,7 @@ Root CA certificates approved for distribution will be added to the Chrome Root ### Inclusion Rejection -The Chrome Root Program will reject inclusion applications where an Applicant does not meet the minimum requirements defined by the Chrome Root Program [Policy](../index) or the application is deemed incomplete or inaccurate. +The Chrome Root Program will reject inclusion applications where an Applicant does not meet the minimum requirements defined by the Chrome Root Program [Policy](policy.md) or the application is deemed incomplete or inaccurate. While the Chrome Root Program may communicate the basis for its decision, all inclusion determinations are made at its sole discretion and are final. @@ -92,7 +92,7 @@ Illustrative factors for application rejection may include: * A corresponding Public Key Infrastructure (PKI) certificate hierarchy where leaf certificates are not primarily intended to be used for server authentication facilitating a secure connection between a web browser and a corresponding website (e.g., client authentication certificates, Internet of Things (IoT) device certificates, smart cities, transportation, medical devices, etc.). * A corresponding PKI hierarchy that currently or previously allowed, facilitated, or enabled “Monster in the Middle” (MITM) attacks (either successful or attempted) where a certificate was issued for the purposes of impersonation, interception, or to alter communications. * Where the corresponding CA Owner has ever been determined to have acted in an untrustworthy manner or created unnecessary ecosystem risk. -* Where the corresponding CA Owner has an incident history that does not convey the [factors](../index#151-incident-reports) significant to Chrome. +* Where the corresponding CA Owner has an incident history that does not convey the [factors](policy.md#151-incident-reports) significant to Chrome. * Completion of a CCADB root inclusion public discussion that casts doubt over the CA Owners security, honesty or reliability. * Discovery of false or misleading information provided by the CA Owner. * Significant delays in response from the CA Owner when seeking additional or clarifying information. diff --git a/content/moving-forward-together.md b/content/crp/moving-forward-together.md similarity index 99% rename from content/moving-forward-together.md rename to content/crp/moving-forward-together.md index acb7c20..54d7b06 100644 --- a/content/moving-forward-together.md +++ b/content/crp/moving-forward-together.md @@ -1,5 +1,5 @@ --- -title: Moving Forward, Together +title: Chrome Root Program - Moving Forward, Together --- # Moving Forward, Together @@ -19,7 +19,7 @@ With those goals in mind, the Chrome Root Program continues to explore introduci ## Understanding "Moving Forward, Together" initiatives -The initiatives described on this page are distinct from the requirements detailed in the [Chrome Root Program Policy](index). These initiatives are proposals for exploration. They are not requirements. +The initiatives described on this page are distinct from the requirements detailed in the [Chrome Root Program Policy](policy.md). These initiatives are proposals for exploration. They are not requirements. Some proposals may change during our review process, after considering community feedback, or studying the ecosystem impacts and tradeoffs of adoption. Others may not be adopted at all. diff --git a/content/crp/policy.md b/content/crp/policy.md new file mode 100644 index 0000000..b7915e0 --- /dev/null +++ b/content/crp/policy.md @@ -0,0 +1,488 @@ +--- +title: Chrome Root Program Policy, Version 1.8 +--- + +# Chrome Root Program Policy, Version 1.8 + +## Last updated: 2026-02-05 + +Bookmark this page as [https://g.co/chrome/root-policy](https://g.co/chrome/root-policy) + +## Table of Contents + +- [Introduction](#introduction) + - [Apply for Inclusion](#apply-for-inclusion) + - [Chrome's Ongoing Commitment to Transport Security](#chromes-ongoing-commitment-to-transport-security) + - [Moving Forward, Together](#moving-forward-together) + - [Additional Information](#additional-information) +- [Change History](#change-history) +- [Definitions](#definitions) +- [1. Minimum Requirements for CAs Included in the Chrome Root Store](#1-minimum-requirements-for-cas-included-in-the-chrome-root-store) + - [1.1. PKI Policy Governance and Requirements](#11-pki-policy-governance-and-requirements) + - [1.1.1. Baseline Requirements](#111-baseline-requirements) + - [1.1.2. Common CA Database](#112-common-ca-database) + - [1.1.3. Chrome Root Program Participant Policies](#113-chrome-root-program-participant-policies) + - [1.2. Reducing Attack Surface of the Chrome Root Store](#12-reducing-attack-surface-of-the-chrome-root-store) + - [1.2.1. Maximum Number of CAs per CA Owner](#121-maximum-number-of-cas-per-ca-owner) + - [1.3. Modern Infrastructures](#13-modern-infrastructures) + - [1.3.1. Promote use of Modern PKI Hierarchies](#131-promote-use-of-modern-pki-hierarchies) + - [1.3.1.1. Root CA Succession Planning](#1311-root-ca-succession-planning) + - [1.3.1.2. Root CA Term-Limit](#1312-root-ca-term-limit) + - [1.3.1.3. Subordinate CA Certificate Lifecycle Management](#1313-subordinate-ca-certificate-lifecycle-management) + - [1.3.2. Promote use of Dedicated TLS Server Authentication PKI Hierarchies](#132-promote-use-of-dedicated-tls-server-authentication-pki-hierarchies) + - [1.3.3. Promote Cryptographic Agility and Resilience](#133-promote-cryptographic-agility-and-resilience) + - [1.3.3.1. Automation Support](#1331-automation-support) + - [1.3.3.1.1. ACME Solutions](#13311-acme-solutions) + - [1.3.3.1.2. Non-ACME Solutions](#13312-non-acme-solutions) + - [1.3.4. Promote Increased Transparency](#134-promote-increased-transparency) + - [1.3.4.1. Logging Precertificates ](#1341-logging-precertificates) + - [1.3.4.2. Logging Final Certificates ](#1342-logging-final-certificates) + - [1.3.4.3. Contributing to a Healthy CT Ecosystem](#1343-contributing-to-a-healthy-ct-ecosystem) + - [1.4. Audits](#14-audits) + - [1.4.1. Annual Audits](#141-annual-audits) + - [1.4.2. Ad-Hoc Audits](#142-ad-hoc-audits) + - [1.5. Reporting and Responding to Incidents](#15-reporting-and-responding-to-incidents) + - [1.5.1. Incident Reports](#151-incident-reports) + - [1.5.2. Communicating with Chrome During Incidents](#152-communicating-with-chrome-during-incidents) + - [1.6 Timely and Transparent Communications](#16-timely-and-transparent-communications) + - [1.6.1. Notification of CA Certificate Issuance](#161-notification-of-ca-certificate-issuance) + - [1.6.2. Notification of Procurement, Sale, or other Change Control Events](#162-notification-of-procurement-sale-or-other-change-control-events) + - [1.6.3. Industry and Community Forum Engagement](#163-industry-and-community-forum-engagement) +- [2. Minimum Requirements for Applicant CAs Requesting Inclusion into the Chrome Root Store](#2-minimum-requirements-for-applicant-cas-requesting-inclusion-into-the-chrome-root-store) + - [2.1. PKI Policy Governance and Requirements](#21-pki-policy-governance-and-requirements) + - [2.2. Root CA Key Material Freshness](#22-root-ca-key-material-freshness) + - [2.3. Dedicated TLS Server Authentication PKI Hierarchies](#23-dedicated-tls-server-authentication-pki-hierarchies) + - [2.4. Promote Cryptographic Agility and Resilience](#24-promote-cryptographic-agility-and-resilience) + - [2.5. Annual Audits](#25-annual-audits) + +## Introduction + +Google Chrome relies on Certification Authority systems (herein referred to as "CAs") to issue certificates to websites. Chrome uses these certificates to help ensure the connections it makes on behalf of its users are properly secured. Chrome accomplishes this by verifying that a website's certificate was issued by a recognized CA, while also performing additional evaluations of the HTTPS connection's security properties. Certificates not issued by a CA trusted by Chrome or a user's local settings can cause users to see warnings and error pages. + +When making HTTPS connections, Chrome refers to a list of self-signed root certificates from CAs that have demonstrated why continued trust in them is justified. This list is known as a "Root Store." CA certificates included in the [Chrome Root Store](https://g.co/chrome/root-store) are selected on the basis of publicly available and verified information, such as that within the Common CA Database ([CCADB](https://ccadb.org/)), and ongoing reviews by the Chrome Root Program. + +The Chrome Root Program Policy below establishes the minimum requirements for CA certificates to be included as trusted in a default installation of Chrome. + +The Chrome Root Program continuously evolves this policy to enhance the security and resilience of the Internet ecosystem, consistent with Google's ongoing [commitment](#chromes-ongoing-commitment-to-transport-security) to secure and reliable network connections in Chrome. This involves establishing and periodically strengthening minimum requirements for CAs. New requirements, sometimes only for Applicants, are introduced to progressively raise the baseline of trust and drive the adoption of modern, agile, and secure Public Key Infrastructure (PKI) practices. This phased approach allows the program to integrate advancements and best practices, ensuring that certificates included in the Chrome Root Store consistently provide value to Chrome end users that exceeds the risk of their continued inclusion, while accounting for the practicalities of protecting users at scale. Aspects of value are principally demonstrated through the real-world use of the corresponding root CA certificate. This includes active TLS server authentication certificate issuance, observability of time-valid and unrevoked TLS server authentication certificates across the Internet, and direct reliance on those certificates by the Chrome Certificate Verifier when securing Chrome user connections. + +Except in the case of CA Owners applying for inclusion, this policy makes no stipulation on the characteristics or PKI use cases served by CAs not included in the current version of the Chrome Root Store. + +Any questions regarding this policy can be directed to chrome-root-program [at] google [dot] com. + +### Apply for Inclusion + +CA Owners that satisfy the requirements defined in the policy below may apply for self-signed root CA certificate inclusion in the Chrome Root Store using [these](apply-for-inclusion.md) instructions. + +Applicants are expected to continuously adhere to the policies outlined herein, irrespective of their inclusion request submission date. All Applicants are expected to satisfy the requirements set forth in both the ["Minimum Requirements for CAs included in the Chrome Root Store"](#1-minimum-requirements-for-cas-included-in-the-chrome-root-store) and ["Minimum Requirements for Applicant CAs Requesting Inclusion into the Chrome Root Store"](#2-minimum-requirements-for-applicant-cas-requesting-inclusion-into-the-chrome-root-store) Sections. Where requirements in these sections differ, the Applicant-specific requirements take precedence. + +If an Applicant's Root Inclusion Request is currently in the CCADB with a status of 'Verification By Root Store' and has not yet received a final determination, and this policy is updated to a new version, the Chrome Root Program will change the request's status to 'CA Providing Data.' Applicants must review and ensure compliance with the updated policy expectations before resubmitting their Root Inclusion Request for review by the Chrome Root Program. + +### Chrome's Ongoing Commitment to Transport Security + +The Chrome Root Program and 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 certificates in the Chrome Root Store. The selection and ongoing inclusion of certificates is done to enhance the security of Chrome. Certificates included in the Chrome Root Store must provide value to Chrome end users that exceeds the risk of their continued inclusion. Certificates that do not provide a broad service to all browser users will not be added to, or may be removed from the Chrome Root Store. Initial and sustained inclusion in the Chrome Root Store is not guaranteed to any CA Owner. +- applies metadata-based [name constraints](https://source.chromium.org/chromium/chromium/src/+/main:net/cert/root_store.proto;drc=7c2b25f6a19cfeeea67f0f43ed33617840bab33d;l=39) to certificates in the Chrome Root Store. These constraints, which may go beyond those in the CA certificates themselves, restrict the use of corresponding TLS server authentication certificates to specific Top-Level Domains (TLDs) and/or Second-Level Domains (SLDs). + +Chrome maintains a variety of mechanisms to protect its users from certificates that put their safety and privacy at risk, and is prepared to use them as necessary. A Chrome Root Program Participant's failure to follow the minimum requirements defined in this policy may result in the corresponding certificate's removal from the Chrome Root Store, limitations on Chrome's acceptance of the certificates they issue, or other technical or policy restrictions. Before taking such action, the Chrome Root Program always evaluates the broader context of an individual incident and considers it against the [factors](#151-incident-reports) significant to the Chrome Root Program. + +### Moving Forward, Together + +The "Moving Forward, Together" initiative envisions a future Internet ecosystem that includes modern, reliable, highly agile, purpose-driven PKIs with an emphasis on automation, simplicity, and security. + +Learn more about priorities and initiatives that may influence future versions of this policy [here](moving-forward-together.md). Please note "Moving Forward, Together" is future looking and does not describe normative requirements. + +### Additional Information + +If you're a Chrome user experiencing a certificate error and need help, please see [this support article](https://support.google.com/chrome/answer/6098869?hl=en). + +If you're a website operator, you can learn more about [why HTTPS matters](https://web.dev/why-https-matters/) and how to [secure your site with HTTPS](https://support.google.com/webmasters/answer/6073543). If you've got a question about a certificate you've been issued, please contact the CA that issued it. + +If you're responsible for a CA that is not trusted by default in Chrome and only issues certificates to your enterprise organization, sometimes called an "enterprise", "private" or "locally trusted" CA, the Chrome Root Program Policy does not apply to or impact your CA's PKI use cases. Enterprise CAs are used for issuing certificates to internal resources like intranet sites or applications that do not directly interact with external users of the public Internet (e.g., a TLS server authentication certificate issued to a corporate intranet site). + +Though uncommon, websites can also use certificates to identify clients (e.g., users) connecting to them. Besides ensuring it is well-formed, Chrome passes this type of certificate to the server, which then evaluates and enforces its chosen policy. The policies on this page do not apply to client authentication certificates. + +Learn more about the Chrome Root Store and Chrome Certificate Verifier [here](https://chromium.googlesource.com/chromium/src/+/main/net/data/ssl/chrome_root_store/faq.md). + +This policy, along with archived versions, is available in Markdown [here](https://github.com/GoogleChrome/chromerootprogram). + +## Change History + +| Version | Date | Note | +|-------- |----- |----- | +| 1.8 | 2026-02-05 | Updates include, but are not limited to: *(1)* limiting the number of root certificates per CA Owner included in the Chrome Root Store, *(2)* extending automation support requirements from Applicants to all existing CAs trusted by Chrome, *(3)* requiring CA policy documents to state adherence to the Chrome Root Program Policy, *(4)* setting expectations for industry engagement, *(5)* recommending practices for Subordinate CA lifecycle management, *(6)* encouraging support for the Certificate Transparency ecosystem, and *(7)* consolidating all requirements applicable only to Applicants in a dedicated section | +| 1.7 | 2025-07-15 | Updates include, but are not limited to: *(1)* add the ARI RFC numerical identifier, *(2)* remove requirements redundant with CCADB Policy Version 2.0 | +| 1.6 | 2025-02-15 | Updates include, but are not limited to: *(1)* the future phase-out of non-TLS server authentication dedicated hierarchies from the Chrome Root Store, *(2)* requirements for future Applicants related to automation support, promoting simplicity of policy documents, and the definition of a dedicated TLS server authentication PKI hierarchy, *(3)* improved alignment with the TLS Baseline Requirements following Ballot SC-077, *(4)* addition of subsection numbers and major reorganization of normative and non-normative requirements | +| 1.5 | 2024-01-16 | Updates include, but are not limited to: *(1)* incorporated CA Owner feedback in response to policy Version 1.4 (clean-ups and clarifications throughout the policy), *(2)* added new subsections for Root CA Key Material Freshness, Automation Support, and the Root CA Term-Limit, *(3)* aligned incident reporting format and timelines with CCADB.org | +| 1.4 | 2023-03-03 | Updates include, but are not limited to: *(1)* alignment with CCADB Policy Version 1.2 and the Baseline Requirements, *(2)* clarify requirements related to the submission of annual self-assessments, *(3)* clarify requirements to better align with program intent (e.g., CA Owner policy document freshness), *(4)* updated audit and incident reporting requirements to promote increased transparency, *(5)* require subordinate CA disclosures in CCADB, *(6)* clarify CA certificate issuance notification requirements | +| 1.3 | 2023-01-06 | Updated to include the CCADB Self-Assessment | +| 1.2 | 2022-09-01 | Updated to reflect the launch of the Chrome Root Program. Updates include, but are not limited to: *(1)* removal of pre-launch discussion, *(2)* clarifications resulting from the June 2022 Chrome CCADB survey, *(3)* minor reorganization of normative and non-normative requirements | +| 1.1 | 2022-06-01 | Updated in anticipation of the future Chrome Root Program launch. Updates include, but are not limited to: *(1)* future-dated Applicant requirements for dedicated TLS-hierarchies and key-pair freshness, *(2)* clarification of audit expectations, *(3)* requirements for cross-certificate issuance notification, *(4)* description of and requirements related to an annual self-assessment process, *(5)* an outline of priority Chrome Root Program initiatives | +| 1.0 | 2020-12-20 | Initial release | + +## Definitions + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this policy are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119). + +This policy considers a "CA Owner" to be the organization or legal entity that is either: + +- represented in the subject DN of the CA certificate; or +- in possession or control of the corresponding private key capable of issuing new certificates, if not the same organization or legal entity directly represented in the subject DN of the certificate. + +This policy considers an "Applicant" to be an organization or legal entity that has an open "Root Inclusion Request" submitted to Google Chrome in the [CCADB](https://ccadb.org/). + +This policy uses the term "Chrome Root Program Participants" to describe: + +- Applicants; and +- CA Owners with either (a) a certificate included in the Chrome Root Store or (b) a CA certificate that validates to a certificate included in the Chrome Root Store. + +This policy uses the term "Externally-operated CA" to describe a subordinate CA certificate issued where the organization or legal entity in possession or control of the corresponding private key capable of issuing new certificates is not under the sole control of the CA Owner whose certificate is included in the Chrome Root Store. + +This policy considers a PKI hierarchy as "dedicated" if it is intended to serve one specific use case, for example, the issuance of TLS server authentication certificates. + +To continually raise the baseline of trust and drive the adoption of modern, agile, and secure PKIs, this policy sometimes "phases out" practices (sometimes referred to as a "phase-out"). Unless otherwise specified, phase-outs are accomplished using an [SCTNotAfter constraint](https://source.chromium.org/chromium/chromium/src/+/main:net/cert/root_store.proto;drc=a783c3bab474ff68e675e2753f91c92ca817e072;l=15?q=f:root_store.proto&ss=chromium) on a corresponding root CA’s certificate included in the Chrome Root Store. TLS server authentication certificates issued on or before a practice’s or PKI hierarchy’s specified phase-out date and time will be trusted in Chrome until expiry, whereas certificates issued after will not be trusted by default. The corresponding root CA’s certificate included in the Chrome Root Store will be removed upon the absence of unexpired and unrevoked TLS server authentication certificates issued prior to the phase-out date. + +## 1. Minimum Requirements for CAs Included in the Chrome Root Store + +The following requirements are effective immediately, unless explicitly stated as otherwise. + +### 1.1. PKI Policy Governance and Requirements + +Chrome Root Program Participants MUST satisfy the requirements defined in this policy, including taking responsibility for ensuring the continued compliance of all corresponding subordinate CAs and delegated third parties participating in the PKI. + +#### 1.1.1. Baseline Requirements + +Chrome Root Program Participants that issue TLS server authentication certificates trusted by Chrome MUST adhere to the latest version of the ["Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates"](https://cabforum.org/baseline-requirements-documents/) ("Baseline Requirements"). The Baseline Requirements are consensus-driven requirements owned by a community of participants represented in the [CA/Browser Forum](https://cabforum.org/) [Server Certificate Working Group](https://cabforum.org/working-groups/server/). No single organization, including Google, has the authority to grant exceptions to the Baseline Requirements. + +In some cases, this policy strengthens requirements described in the Baseline Requirements. + +#### 1.1.2. Common CA Database + +The Chrome Root Program relies on the [CCADB](https://ccadb.org/) to identify and maintain up-to-date information for Chrome Root Program Participants and the corresponding PKI hierarchies. + +Chrome Root Program Participants MUST adhere to the latest version of the [CCADB Policy](https://www.ccadb.org/policy). + +In some cases, this policy strengthens requirements described in the CCADB Policy. + +#### 1.1.3. Chrome Root Program Participant Policies + +**Effective June 15, 2026**, a Chrome Root Program Participant's CP or combined CP/CPS MUST explicitly state adherence to the latest published version of this policy and the CCADB Policy. This attestation SHOULD be made in Section 1.1 ("Overview"). + +### 1.2. Reducing Attack Surface of the Chrome Root Store + +#### 1.2.1. Maximum Number of CAs per CA Owner + +If a CA Owner already has two (2) or more self-signed root CA certificates included in the Chrome Root Store, the Chrome Root Program will only accept a new CCADB Root Inclusion Request to replace an existing certificate (i.e., 'one in, one out'). + +**Before June 15, 2026**, CA Owners with more than two (2) self-signed root CA certificates in the Chrome Root Store MUST submit a written consolidation plan to the Chrome Root Program. This plan MUST: + +1. Identify the two (2) root CA certificates that will remain in the Chrome Root Store, and +2. Provide a phase-out date for all of their other root CA certificates. The phase-out date MUST be **before September 15, 2027, (00:00 UTC)**. + +**Effective September 15, 2027**, the Chrome Root Store will only include a maximum of two (2) self-signed root CA certificates per CA Owner. PKI hierarchies being phased-out are not counted toward this limit. + +To further reduce negative impact to the ecosystem, the Chrome Root Store may temporarily continue to include more than two (2) self-signed root CA certificates past the specified consolidation timeline on a case-by-case basis. + +### 1.3. Modern Infrastructures + +#### 1.3.1. Promote use of Modern PKI Hierarchies + +##### 1.3.1.1. Root CA Succession Planning + +CA Owners SHOULD request for the replacement of a certificate included in the Chrome Root Store no later than five (5) years after the release date of the Chrome Root Store's initial inclusion of the certificate. + +Before a CA Owner submits a Root Inclusion Request to the CCADB, it MUST have issued a cross-certificate from the CA being replaced to the replacement CA. Due to the existence of the cross-certificate, TLS server authentication certificates issued by the replacement PKI hierarchy will be trusted by default in versions of Chrome relying on the Chrome Root Store, regardless of whether they are capable of receiving updates to the Chrome Root Store. + +Within no more than 90 calendar days after a replacement CA certificate being first distributed by the Chrome Root Store and as disclosed in the CCADB, the CA Owner MUST have transitioned all TLS server authentication certificate issuance intended to be trusted by default in Chrome from the cross-signing PKI hierarchy to the replacement PKI hierarchy. To technically enforce this transition, the CA being replaced will have a phase-out date set to 90 calendar days after the Applicant CA certificate being first distributed by the Chrome Root Store. While the CA Owner is not prohibited from continuing to issue certificates from the PKI hierarchy being replaced after this phase-out date, such certificates will not be trusted by default in Chrome. The CA certificate being replaced will be removed from the Chrome Root Store upon the absence of unexpired and unrevoked TLS server authentication certificates (excluding test certificates like those disclosed to the CCADB) disclosed to Certificate Transparency (CT) before this phase-out date. + +##### 1.3.1.2. Root CA Term-Limit + +Any root CA certificate with corresponding key material generated more than 15 years ago will be removed from the Chrome Root Store on an ongoing basis. + +The age of the key material will be determined by the earliest of either: + +- a key generation report issued by a Qualified Auditor that distinctly represents the corresponding key; or +- the validity date of the earliest appearing certificate that contains the corresponding public key. + +To phase-in these requirements in a manner that reduces negative impact to the ecosystem, affected root CA certificates included in the Chrome Root Store will be removed according to the schedule in the table below. + +| Key Material Created | Approximate Removal Date | +|--------------------- |------------------------- | +| Between January 1, 2006 and December 31, 2007 (inclusive) | April 15, 2026 | +| Between January 1, 2008 and December 31, 2009 (inclusive) | April 15, 2027 | +| Between January 1, 2010 and December 31, 2011 (inclusive) | April 15, 2028 | +| Between January 1, 2012 and April 14, 2014 (inclusive) | April 15, 2029 | +| After April 15, 2014 | 15 years from generation | + +To further reduce negative impact to the ecosystem, the Chrome Root Store may temporarily continue to include a root CA certificate past its defined term-limit on a case-by-case basis, if the corresponding CA Owner has submitted a Root Inclusion Request to the CCADB for a replacement root CA certificate at least one (1) year in advance of the approximate removal date. + +Other circumstances may lead to the removal of a root CA certificate included in the Chrome Root Store before the completion of its term. + +##### 1.3.1.3. Subordinate CA Certificate Lifecycle Management + +The lifecycle management of subordinate CA certificates plays a crucial role in promoting agility and resilience within the ecosystem. By setting clear expectations for their validity and renewal, the Chrome Root Program aims to align certificate profiles with modern best practices, reduce reliance on specific subordinate CA certificates that could be single points of failure, and discourage potentially harmful practices. This approach allows the ecosystem to benefit from continuous improvement efforts. + +To achieve these goals, it's encouraged that all subordinate CA certificates that validate to a certificate included in the Chrome Root Store align with the following practices: + +- Subordinate CA certificates SHOULD have a maximum validity period of three (3) years. +- CA Owners SHOULD create and deploy new subordinate CA certificates at least once every year. CA Owners SHOULD actively transition subscriber certificate issuance to these newly deployed CAs. + +#### 1.3.2. Promote use of Dedicated TLS Server Authentication PKI Hierarchies + +The Chrome Root Store is solely relied upon for TLS server authentication in Chrome; it is not used for any other PKI use case (e.g., TLS client authentication, secure email, code-signing, etc.). + +To align all PKI hierarchies included in the Chrome Root Store on the principle of serving only TLS server authentication use cases, the Chrome Root Program will phase-out multi-purpose roots from the Chrome Root Store. + +**Beginning June 15, 2026**, the Chrome Root Program will phase-out PKI hierarchies found in violation of the below requirements. In these cases, the phase-out date will be set to 90 calendar days following the violation’s detection. + +1. All corresponding unexpired and unrevoked subordinate CA certificates operated beneath an existing root included in the Chrome Root Store MUST: + - if disclosed to the CCADB **before June 15, 2026**: include the extendedKeyUsage extension and (a) only assert an extendedKeyUsage purpose of id-kp-serverAuth or (b) only assert extendedKeyUsage purposes of id-kp-serverAuth and id-kp-clientAuth. + - if disclosed to the CCADB **on or after June 15, 2026**: include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth. + - NOT contain a public key corresponding to any other unexpired or unrevoked certificate that asserts different extendedKeyUsage values. +2. All corresponding subscriber certificates issued **on or after March 15, 2027**, MUST include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth. + +To reduce negative impact to the ecosystem, the Chrome Root Store may temporarily continue to include a multi-purpose root CA certificate in the Chrome Root Store without an SCTNotAfter constraint on a case-by-case basis, but only if the corresponding CA Owner has submitted a Root Inclusion Request to the CCADB for a replacement root CA certificate before June 15, 2026. + +#### 1.3.3. Promote Cryptographic Agility and Resilience + +##### 1.3.3.1. Automation Support + +Certificate lifecycle management automation solutions ("automation solutions") increase agility and improve the [security](https://zanema.com/papers/imc23_stale_certs.pdf) and resilience of the Internet ecosystem. Automation solutions minimize "hands-on" input required from humans during certificate issuance and renewal. Routine certificate issuance and renewal SHOULD NOT involve human input except as needed for identity or business document verification related to IV, OV, or EV certificate issuance. + +**Effective March 15, 2027**, all unexpired and unrevoked subordinate CA certificates signed by a root CA certificate included in the Chrome Root Store MUST be integrated with an automation solution, minimally compliant with either [Section 1.3.3.1.1 ("ACME Solutions")](#13311-acme-solutions) or [Section 1.3.3.1.2 ("Non-ACME Solutions")](#13312-non-acme-solutions). Functionally, this means that every TLS server authentication certificate profile offered by a subordinate CA trusted in Chrome MUST be capable of being issued and renewed using an automation solution. CA Owners MUST attest that this requirement is met for each Baseline Requirements certificate policy OID the corresponding PKI hierarchy issues through a disclosure in the CCADB on the root certificate record of each CA included in the Chrome Root Store. + +Additionally, **effective March 15, 2027**, for each CCADB root certificate record corresponding to a root included in the Chrome Root Store, CA Owners MUST disclose at least one (1) automation solution for each Baseline Requirements certificate policy OID appearing in unexpired and unrevoked subscriber certificates. For each such OID, the CA Owner MUST use a disclosed automation solution to issue "Automation Test Certificates" to demonstrate its automation capabilities. Automation Test Certificates MUST be renewed at least once every 30 calendar days; however, at any point, the Chrome Root Program may request more frequent renewal. At least one (1) valid Automation Test Certificate corresponding to each Baseline Requirements certificate policy OID MUST be served by a publicly accessible website whose URL is disclosed to the CCADB on the corresponding intermediate certificate record. CA Owners are encouraged to issue "Short-lived Subscriber Certificates," as [introduced](https://cabforum.org/2023/07/14/ballot-sc-063-v4make-ocsp-optional-require-crls-and-incentivize-automation/) in Version 2.0.1 of the Baseline Requirements, for the Automation Test Certificates. + +The above requirements do not: + +- Prohibit PKI hierarchies from also supporting other "non-automated" methods of certificate issuance and renewal. +- Require website operators to rely on the automation solution(s) for certificate issuance and renewal. + +**Beginning March 15, 2027**, the Chrome Root Program will phase-out PKI hierarchies found issuing new certificates containing a Baseline Requirements certificate policy OID lacking an automation solution attestation disclosure in the CCADB. In these cases, the phase-out date will be set to 90 calendar days following the violation’s detection. + +###### 1.3.3.1.1. ACME Solutions + +PKI hierarchies SHOULD support the Automatic Certificate Management Environment (ACME) protocol. If ACME is supported: + +- The CA Owner MUST disclose to the CCADB at least one (1) ACME endpoint (i.e., directory URL) accessible to the Chrome Root Program for each Baseline Requirements certificate policy OID the corresponding PKI hierarchy issues (i.e., IV, DV, OV, EV). +- Each endpoint MUST support the following capabilities, as specified in [RFC 8555](https://www.rfc-editor.org/rfc/rfc8555): + - keyChange, + - newAccount, + - newNonce, + - newOrder, and + - revokeCert. +- Each endpoint's corresponding issuing CA(s) MUST support Certification Authority Authorization (CAA) Record Extensions for Account URI and ACME Method Binding, as specified in [RFC 8657](https://www.rfc-editor.org/rfc/rfc8657). +- PKI hierarchies supporting the ACME protocol MUST support ACME Renewal Information (ARI, [RFC 9773](https://datatracker.ietf.org/doc/rfc9773/)). +- ACME endpoints SHOULD support the Profiles extension ([RFC TBD](https://datatracker.ietf.org/doc/draft-ietf-acme-profiles/)). +- ACME endpoints SHOULD be publicly accessible. +- Each endpoint SHOULD be hosted using an appropriate and readily accessible online means that is available on a 24x7 basis. + +###### 1.3.3.1.2. Non-ACME Solutions + +While ACME support is encouraged, PKI hierarchies MAY support other automation solutions so long as the following characteristics are verifiably demonstrated to the Chrome Root Program. If the requirements in [Section 1.3.3.1.1 ("ACME Solutions")](#13311-acme-solutions) are not met, the CA Owner MUST disclose to the CCADB publicly available information that describes the other automation solution capability for each Baseline Requirements certificate policy OID that the corresponding PKI hierarchy issues and how a subscriber can leverage its benefits. For the purposes of this section, an "automation solution" is defined as the combination of the CA’s issuance interface (e.g., API) and compatible client software provided and maintained directly by the CA Owner that is ultimately operated by the TLS server authentication certificate requestor. This client software SHOULD be comparable in function and operation to an ACME client, and MAY be incorporated into Certificate Lifecycle Management tooling. + +- The automation solution MUST: + - generate a new key pair for each certificate request by default. + - generate and submit a Certificate Signing Request (CSR). + - support automated domain control validation (i.e., the automated solution automatically places the Request Token or Random Value in the appropriate location without "hands-on" input from humans, comparable to how ACME clients function), using at least one (1) of the following methods from the Baseline Requirements: + - DNS Change (Section 3.2.2.4.7) + - Agreed‑Upon Change to Website v2 (Section 3.2.2.4.18) + - support automated retrieval of the issued certificate (i.e., the automated solution downloads a copy of the certificate to a well-known location without "hands-on" input from humans, comparable to how ACME clients function). + - be sufficiently detailed in a completed "Automation Solution Assessment" form by requesting a copy from chrome-root-program [at] google [dot] com. + - support comparable features as described in [RFC 8657](https://www.rfc-editor.org/rfc/rfc8657) to restrict issuance capabilities to a specific CA account(s) using the "accounturi" CAA parameter and to restrict permitted domain validation methods using the "validationmethods" CAA parameter. + - support and/or request certificate revocation. + - support comparable features as described by ACME Renewal Information (ARI, [RFC 9773](https://datatracker.ietf.org/doc/rfc9773/)). + +- The automation solution SHOULD: + - support automated deployment (i.e., installation and configuration) of the issued certificate without "hands-on" input from humans (comparable to how ACME clients function). + - support comparable features as described by the ACME Profiles extension ([RFC TBD](https://datatracker.ietf.org/doc/draft-ietf-acme-profiles/)). + +#### 1.3.4. Promote Increased Transparency + +##### 1.3.4.1. Logging Precertificates + +CA Owners with CA certificates that validate to a certificate included in the Chrome Root Store SHOULD ensure that all TLS server authentication precertificates issued by such CAs are logged to at least one (1) CT log recognized by Chrome as [Usable or Qualified](https://www.gstatic.com/ct/log_list/v3/log_list.json) within 24 hours of issuance. + +**Effective June 15, 2026**, CA Owners with CA certificates that validate to a certificate included in the Chrome Root Store MUST ensure that all TLS server authentication precertificates issued by such CAs are logged to at least one (1) CT log recognized by Chrome as [Usable or Qualified](https://www.gstatic.com/ct/log_list/v3/log_list.json) before issuing the corresponding certificate. + +##### 1.3.4.2. Logging Final Certificates + +CA Owners with CA certificates that validate to a certificate included in the Chrome Root Store SHOULD ensure that all TLS server authentication certificates (i.e., "final certificates") issued by such CAs are logged to at least one (1) CT log recognized by Chrome as [Usable or Qualified](https://www.gstatic.com/ct/log_list/v3/log_list.json) within 24 hours of issuance. + +##### 1.3.4.3. Contributing to a Healthy CT Ecosystem + +Chrome Root Program Participants SHOULD contribute to the health and diversity of the CT ecosystem. Such contributions may include, but are not limited to: + +- reliably operating CT logs [Usable](https://googlechrome.github.io/CertificateTransparency/log_states.html#usable) in Chrome. +- providing engineering resources or expertise to assist CT log operators or related projects. +- developing and open-sourcing CT-related tools (e.g., for log operations, monitoring, auditing, or client-side integration). +- sponsoring research and development focused on improving CT scalability, security, privacy, or new log designs. +- hosting or mirroring CT logs for redundancy and geographical diversity. +- actively participating in CT standardization and policy development efforts. + +### 1.4. Audits + +Chrome Root Program Participant CAs MUST be audited in accordance with the table below. + +Audits MUST NOT rely on a version of the accepted audit criteria below if it has been superseded by more than 30 calendar days before the start of the corresponding audit period. + +| CA Type | EKU Characteristics** | Audit Criteria | +|-------- |---------------------- |--------------- | +| Root CA | N/A | **If WebTrust scheme**…

(1) "WebTrust Principles and Criteria for Certification Authorities"; and either…

- (A) "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security" or
- (B) "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline" and "WebTrust Principles and Criteria for Certification Authorities – Network Security"

and

(2) "WebTrust for CA - Extended Validation - SSL" (if issuing EV)

**If ETSI scheme*****...

(1) ETSI EN 319 411-1 LCP and [DVCP or OVCP];

or

(2) ETSI EN 319 411-1 [NCP or NCP+] and EVCP (if issuing EV)
+| Cross-Certified Subordinate CA | Either: (1) Certificate does not include an EKU; or (2) EKU is present and includes id-kp-serverAuth or anyExtendedKeyUsage | Same as above. | +| TLS Subordinate CA or Technically Constrained TLS Subordinate CA | Same as above. | Same as above. | +| Technically Constrained Non-TLS Subordinate CA | EKU is present and does not include id-kp-serverAuth or anyExtendedKeyUsage. | Minimally expected to be audited as defined in Section 8.7 of the BRs (self-audit). | +| All others | N/A | Minimally expected to be audited as defined in Section 8.7 of the BRs (self-audit). | + +\*\* CA certificates within PKI hierarchies included in the Chrome Root Store prior to September 1, 2022, MAY have EKU values as described in this table. However, PKI hierarchies added to the Chrome Root Store after September 1, 2022, MUST remain [dedicated to only TLS server authentication use cases](#132-promote-use-of-dedicated-tls-server-authentication-pki-hierarchies) + +\*\*\* accepted on a discretionary basis + +#### 1.4.1. Annual Audits +All Chrome Root Program Participant CAs MUST retain an unbroken, contiguous audit coverage. + +Recurring "complete" (i.e., "full", "full system", or "full re-assessment") audits MUST occur at least once every 365 calendar days (or 366 calendar days in a leap year). These audits MUST begin once a CA's key material has been generated and MUST continue until the corresponding root CA's key material has been destroyed or is no longer included in the Chrome Root Store. + +#### 1.4.2. Ad-Hoc Audits + +The Chrome Root Program may require Chrome Root Program Participants undergo additional ad-hoc audits, including, but not limited to, instances of CA private key destruction or verification of incident remediation. + +### 1.5. Reporting and Responding to Incidents + +The failure of a Chrome Root Program Participant to meet the commitments of this policy is considered an incident, as is any other situation that may impact the CA's integrity, trustworthiness, or compatibility. + +#### 1.5.1. Incident Reports + +Chrome Root Program Participants MUST publicly disclose and/or respond to incident reports in [Bugzilla](https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance), regardless of perceived impact. Reports MUST be submitted in accordance with the current version of [this](https://www.ccadb.org/cas/incident-report) CCADB incident report format and timelines. + +While all Chrome Root Program Participants MAY participate in the incident reporting process, the CA Owner whose corresponding certificate is included in the Chrome Root Store is encouraged to disclose and/or respond to incidents on behalf of the Chrome Root Program Participants included in its PKI hierarchy. + +If the Chrome Root Program Participant has not yet publicly disclosed an incident, they MUST notify chrome-root-program [at] google [dot] com and include an initial timeline for public disclosure. Chrome uses the information in the public disclosure as the basis for evaluating incidents. + +The Chrome Root Program will evaluate every incident on a case-by-case basis, and will work with the CA Owner to identify ecosystem-wide risks or potential improvements to be made that can help prevent future incidents. + +Chrome Root Program Participants MUST be detailed, candid, timely, and transparent in describing their architecture, implementation, operations, and external dependencies as necessary for the Chrome Root Program and the public to evaluate the nature of the incident and the CA Owner's response. When evaluating an incident response, the Chrome Root Program's primary concern is ensuring that browsers, other CA Owners, users, and website developers have the necessary information to identify improvements, and that the Chrome Root Program Participant is responsive to addressing identified issues. + +Factors that are significant to the Chrome Root Program when evaluating incidents include (but are not limited to): + +- a demonstration of understanding of the [root causes](https://sre.google/sre-book/postmortem-culture/) of an incident, +- a substantive commitment and timeline to changes that clearly and persuasively address the root cause, +- past history by the Chrome Root Program Participant in its incident handling and its follow through on commitments, and, +- the severity of the security impact of the incident. + +Due to the incorporation of the Baseline Requirements into CA policy documents, incidents may include a prescribed follow-up action, such as revoking impacted certificates within a certain timeframe. If the Chrome Root Program Participant does not perform the required follow-up actions, or does not perform them in the expected timeframe, the Chrome Root Program Participant MUST file a secondary incident report describing any certificates involved, the expected timeline to complete any follow-up actions, and what changes they are making to ensure they can meet these requirements consistently in the future. + +#### 1.5.2. Communicating with Chrome During Incidents + +The Chrome Root Program prioritizes and remains committed to promoting public disclosure and discussion of incidents, as they can affect the whole Internet ecosystem, not just Chrome and its users. The Chrome Root Program's sole responsibility when responding to incidents is upholding the safety and security of Chrome's users. + +As standard practice, the Chrome Root Program does not: + +- discuss ongoing public incident reports privately. We believe using information disclosed to the public as the basis for our response is the most transparent and effective way of upholding the security expectations of Chrome's users, while also ensuring the [factors](#151-incident-reports) that are significant to Chrome are adequately addressed; +- advise on or approve a CA Owner'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 CA Owner. + +### 1.6. Timely and Transparent Communications + +At any time, the Chrome Root Program may request additional information from a Chrome Root Program Participant using email or CCADB communications to verify the commitments and obligations outlined in this policy are being met, or as updates to policy requirements are being considered. Chrome Root Program Participants MUST provide the requested information within 14 calendar days unless specified otherwise. + +#### 1.6.1. Notification of CA Certificate Issuance + +CA Owners included in the Chrome Root Store MUST complete the "Chrome Root Program Notification of CA Certificate Issuance" form, made available by emailing chrome-root-program [at] google [dot] com, at least three (3) weeks before a CA in the corresponding hierarchy issues a CA certificate that: + +- extends the Chrome Root Store's trust boundary (i.e., the third-party subject CA Owner is either (a) not explicitly included in the Chrome Root Store at the time of issuance, or (b) is constrained (i.e., SCTNotAfter) and planned for removal), or +- replaces an unrevoked and unexpired CA certificate whose subject certificate CA Owner is not explicitly included in the Chrome Root Store. + +Examples of the above use cases include cross-certificates issued to CA Owners not represented in the Chrome Root Store and Externally-operated CA certificates. + +Such CA certificates MUST NOT be issued without the expressed approval of the Chrome Root Program. + +No other notification or approval is required. + +#### 1.6.2. Notification of Procurement, Sale, or other Change Control Events + +Chrome Root Program Participants MUST NOT assume trust is transferable. + +Where permissible by law, Chrome Root Program Participants MUST notify chrome-root-program [at] google [dot] com at least 30 calendar days before any impending: + +- procurements, +- sales, +- changes of ownership or operating control, +- cessations of operations, or +- other change control events involving PKI components that would materially affect the ongoing operations or perceived trustworthiness of a CA certificate included in the Chrome Root Store (e.g., changes to operational location(s), changes to delegated third parties involved in the PKI, etc.) or any Externally-operated CA. + +Not limited to the circumstances above, the Chrome Root Program reserves the right to require re-application to the Chrome Root Store. + +#### 1.6.3. Industry and Community Forum Engagement + +Chrome Root Program Participants are expected to maintain awareness of, and where relevant, actively engage in public discussions concerning CA practices, policy developments, and incidents, within minimally the following public forums: + +- [CCADB Public](https://groups.google.com/a/ccadb.org/g/public), +- the CA/Browser Forum [Server Certificate Working Group](https://groups.google.com/a/groups.cabforum.org/g/servercert-wg), [Validation Subcommittee](https://groups.google.com/a/groups.cabforum.org/g/validation), and [Network Security Working Group](https://lists.cabforum.org/mailman/listinfo/netsec) mailing lists, +- the Bugzilla [CA Certificate Compliance](https://bugzilla.mozilla.org/buglist.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance&bug_status=__open__&list_id=17629668) component, and +- the [Certificate Transparency Policy](https://groups.google.com/a/chromium.org/g/ct-policy) mailing list. + +Awareness of, and participation in, other key industry and community forums is encouraged. + +## 2. Minimum Requirements for Applicant CAs Requesting Inclusion into the Chrome Root Store + +The following requirements are effective immediately, unless explicitly stated as otherwise. + +### 2.1. PKI Policy Governance and Requirements + +Applicants MUST accurately describe the policies and practices of their CA(s) within a single CA policy document that is: + +- in the form of a combined CP/CPS. +- freely publicly available for examination. +- available in an authoritative English language version. +- available in either Markdown or AsciiDoc at a location disclosed to the CCADB ([GitHub-Flavored Markdown](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/about-writing-and-formatting-on-github) is preferred). +- except for Externally-operated CAs, authoritative for all CAs included in the corresponding PKI hierarchy. +- focused only on the specific PKI use case of issuing TLS server authentication certificates to websites. +- sufficiently detailed to assess the operations of the CA(s) and the compliance with these expectations and those of the Baseline Requirements, and MUST NOT conflict with either of these requirements. + +The immediately above requirements do not prohibit Applicants from maintaining additional policy documents, which may also be considered authoritative by other stakeholders. However, the consolidated policy document made available to the Chrome Root Program MUST NOT conflict with any additional policy documents that might exist for the corresponding PKI hierarchy. + +### 2.2. Root CA Key Material Freshness + +The Chrome Root Program only accepts CCADB Root Inclusion Requests from Applicant PKI hierarchies with corresponding root CA key material generated within five (5) years of application to the Chrome Root Store. + +Applicants MUST submit written evidence to the CCADB identifying the date(s) of the key generation ceremony and an attestation to the Applicant's adherence to the requirements defined in Sections 6.1.1.1 ("CA Key Pair Generation") and 6.2 ("Private Key Protection and Cryptographic Module Engineering Controls") of the Baseline Requirements from a Qualified Auditor using an approved format, in accordance with the table below. + +| Audit Scheme | Qualified Auditor Criteria | Report Format Criteria | +|------------- |--------------------------- |----------------------- | +| WebTrust | an [enrolled](https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/licensed-webtrust-practitioners-international) WebTrust practitioner | WebTrust "Reporting on Root Key Generation" report | +| ETSI | a [member](https://www.acab-c.com/members/) of the Accredited Conformity Assessment Bodies' Council (ACAB'c) | ACAB'c Key and Certificate Ceremony Audit Attestation Letter | + +If key material is not used to issue a self-signed root CA certificate on the same date it was generated, Applicants MUST present written evidence from a Qualified Auditor, attesting that keys were minimally protected in a manner consistent with the requirements defined in Section 6.2 ("Private Key Protection and Cryptographic Module Engineering Controls") of the Baseline Requirements from the time of generation to the time the self-signed certificate was issued. Publicly-accessible links for these documents MUST be disclosed to the CCADB. + +### 2.3. Dedicated TLS Server Authentication PKI Hierarchies + +The Chrome Root Program will only accept CCADB Root Inclusion Requests from Applicant PKI hierarchies that are dedicated to TLS server authentication certificate issuance. + +To qualify as a dedicated TLS server authentication PKI hierarchy under this policy: + +1. All corresponding unexpired and unrevoked subordinate CA certificates operated beneath an Applicant root CA certificate MUST: + - if disclosed to the CCADB **before June 15, 2025**: include the extendedKeyUsage extension and (a) only assert an extendedKeyUsage purpose of id-kp-serverAuth or (b) only assert extendedKeyUsage purposes of id-kp-serverAuth and id-kp-clientAuth. + - if disclosed to the CCADB **on or after June 15, 2025**: include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth. + - NOT contain a public key corresponding to any other unexpired or unrevoked certificate that asserts different extendedKeyUsage values. +2. All corresponding unexpired and unrevoked subscriber (i.e., TLS server authentication) certificates MUST include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth. + +### 2.4. Promote Cryptographic Agility and Resilience + +All unexpired and unrevoked subordinate CA certificates included in an Applicant PKI hierarchy MUST be integrated with an automation solution, minimally compliant with either [Section 1.3.3.1.1 ("ACME Solutions")](#13311-acme-solutions) or [Section 1.3.3.1.2 ("Non-ACME Solutions")](#13312-non-acme-solutions). Functionally, this means that every TLS server authentication certificate profile offered by the PKI hierarchy MUST be capable of being issued and renewed using an automation solution. CA Owners MUST attest that this requirement is met for each Baseline Requirements certificate policy OID the corresponding Applicant PKI hierarchy issues through a disclosure in the CCADB on the root certificate record of each CA certificate intending to be included in the Chrome Root Store. + +For each Baseline Requirements certificate policy OID an Applicant intends to issue, the Applicant MUST disclose at least one (1) automation solution to the CCADB. For each such OID, the Applicant MUST use a disclosed automation solution to issue "Automation Test Certificates" to demonstrate its automation capabilities. Automation Test Certificates MUST be renewed at least once every 30 calendar days; however, at any point, the Chrome Root Program may request more frequent renewal. At least one (1) valid Automation Test Certificate corresponding to each Baseline Requirements certificate policy OID MUST be served by a publicly accessible website whose URL is disclosed to the CCADB on the corresponding intermediate certificate record. Applicants are encouraged to issue "Short-lived Subscriber Certificates," as [introduced](https://cabforum.org/2023/07/14/ballot-sc-063-v4make-ocsp-optional-require-crls-and-incentivize-automation/) in Version 2.0.1 of the Baseline Requirements, for the Automation Test Certificates. + +### 2.5. Annual Audits + +Applicant PKI hierarchies MUST provide evidence of at least one (1) complete audit by disclosing the applicable ETSI Audit Attestation Letter(s) or WebTrust Assurance Report(s) to the CCADB before submitting a CCADB Root Inclusion Request to Google Chrome. The initial complete audit SHOULD cover a period of at least 180 calendar days. + +For Applicant PKI hierarchies subject of a CCADB Root Inclusion Request submitted to Google Chrome: + +- Except for Externally-operated CAs, when CAs in the hierarchy are assessed against: + - **only a single audit scheme** (e.g., all CAs in the hierarchy are only assessed against the WebTrust scheme), they MUST fall under a single audit scope (i.e., represented in a single WebTrust Assurance Report) for the assessed criteria (e.g., (a) WebTrust Principles and Criteria for Certification Authorities, (b) WebTrust Principles and Criteria for Certification Authorities - Network Security, (c) WebTrust Principles and Criteria for Certification Authorities - SSL Baseline, or (d) WebTrust for CA - Extended Validation - SSL). + - **multiple audit schemes** (e.g., some CAs are assessed against the WebTrust scheme and others are assessed against the ETSI scheme), all CAs assessed against each respective scheme MUST fall under a single audit scope for that scheme (i.e., all ETSI-assessed CAs are represented in a single ETSI Audit Attestation Letter, and all WebTrust CAs are represented in a single WebTrust Assurance Report) for the assessed criteria. + +If accepted into the Chrome Root Store, Applicant PKI hierarchies MUST continue this practice for the duration of its inclusion. diff --git a/content/index.md b/content/index.md index b7915e0..9f2750f 100644 --- a/content/index.md +++ b/content/index.md @@ -1,488 +1,12 @@ --- -title: Chrome Root Program Policy, Version 1.8 +title: Google Chrome Root Programs --- +# Google Chrome Root Programs -# Chrome Root Program Policy, Version 1.8 +Google Chrome uses certificates issued by Certification Authorities (CAs) to secure connections across the web. When Chrome connects to a website, it verifies the site's certificate against a list of trusted CAs, known as a Root Store, to ensure the connection is private and safe. -## Last updated: 2026-02-05 +To secure the web today and prepare for the post-quantum future, Chrome operates two distinct root programs: -Bookmark this page as [https://g.co/chrome/root-policy](https://g.co/chrome/root-policy) +* **[The Chrome Root Program](crp/policy.md)**: [Launched in 2022](https://blog.chromium.org/2022/09/announcing-launch-of-chrome-root-program.html), this program determines which website certificates Chrome trusts by default, providing consistent and reliable security for HTTPS connections. -## Table of Contents - -- [Introduction](#introduction) - - [Apply for Inclusion](#apply-for-inclusion) - - [Chrome's Ongoing Commitment to Transport Security](#chromes-ongoing-commitment-to-transport-security) - - [Moving Forward, Together](#moving-forward-together) - - [Additional Information](#additional-information) -- [Change History](#change-history) -- [Definitions](#definitions) -- [1. Minimum Requirements for CAs Included in the Chrome Root Store](#1-minimum-requirements-for-cas-included-in-the-chrome-root-store) - - [1.1. PKI Policy Governance and Requirements](#11-pki-policy-governance-and-requirements) - - [1.1.1. Baseline Requirements](#111-baseline-requirements) - - [1.1.2. Common CA Database](#112-common-ca-database) - - [1.1.3. Chrome Root Program Participant Policies](#113-chrome-root-program-participant-policies) - - [1.2. Reducing Attack Surface of the Chrome Root Store](#12-reducing-attack-surface-of-the-chrome-root-store) - - [1.2.1. Maximum Number of CAs per CA Owner](#121-maximum-number-of-cas-per-ca-owner) - - [1.3. Modern Infrastructures](#13-modern-infrastructures) - - [1.3.1. Promote use of Modern PKI Hierarchies](#131-promote-use-of-modern-pki-hierarchies) - - [1.3.1.1. Root CA Succession Planning](#1311-root-ca-succession-planning) - - [1.3.1.2. Root CA Term-Limit](#1312-root-ca-term-limit) - - [1.3.1.3. Subordinate CA Certificate Lifecycle Management](#1313-subordinate-ca-certificate-lifecycle-management) - - [1.3.2. Promote use of Dedicated TLS Server Authentication PKI Hierarchies](#132-promote-use-of-dedicated-tls-server-authentication-pki-hierarchies) - - [1.3.3. Promote Cryptographic Agility and Resilience](#133-promote-cryptographic-agility-and-resilience) - - [1.3.3.1. Automation Support](#1331-automation-support) - - [1.3.3.1.1. ACME Solutions](#13311-acme-solutions) - - [1.3.3.1.2. Non-ACME Solutions](#13312-non-acme-solutions) - - [1.3.4. Promote Increased Transparency](#134-promote-increased-transparency) - - [1.3.4.1. Logging Precertificates ](#1341-logging-precertificates) - - [1.3.4.2. Logging Final Certificates ](#1342-logging-final-certificates) - - [1.3.4.3. Contributing to a Healthy CT Ecosystem](#1343-contributing-to-a-healthy-ct-ecosystem) - - [1.4. Audits](#14-audits) - - [1.4.1. Annual Audits](#141-annual-audits) - - [1.4.2. Ad-Hoc Audits](#142-ad-hoc-audits) - - [1.5. Reporting and Responding to Incidents](#15-reporting-and-responding-to-incidents) - - [1.5.1. Incident Reports](#151-incident-reports) - - [1.5.2. Communicating with Chrome During Incidents](#152-communicating-with-chrome-during-incidents) - - [1.6 Timely and Transparent Communications](#16-timely-and-transparent-communications) - - [1.6.1. Notification of CA Certificate Issuance](#161-notification-of-ca-certificate-issuance) - - [1.6.2. Notification of Procurement, Sale, or other Change Control Events](#162-notification-of-procurement-sale-or-other-change-control-events) - - [1.6.3. Industry and Community Forum Engagement](#163-industry-and-community-forum-engagement) -- [2. Minimum Requirements for Applicant CAs Requesting Inclusion into the Chrome Root Store](#2-minimum-requirements-for-applicant-cas-requesting-inclusion-into-the-chrome-root-store) - - [2.1. PKI Policy Governance and Requirements](#21-pki-policy-governance-and-requirements) - - [2.2. Root CA Key Material Freshness](#22-root-ca-key-material-freshness) - - [2.3. Dedicated TLS Server Authentication PKI Hierarchies](#23-dedicated-tls-server-authentication-pki-hierarchies) - - [2.4. Promote Cryptographic Agility and Resilience](#24-promote-cryptographic-agility-and-resilience) - - [2.5. Annual Audits](#25-annual-audits) - -## Introduction - -Google Chrome relies on Certification Authority systems (herein referred to as "CAs") to issue certificates to websites. Chrome uses these certificates to help ensure the connections it makes on behalf of its users are properly secured. Chrome accomplishes this by verifying that a website's certificate was issued by a recognized CA, while also performing additional evaluations of the HTTPS connection's security properties. Certificates not issued by a CA trusted by Chrome or a user's local settings can cause users to see warnings and error pages. - -When making HTTPS connections, Chrome refers to a list of self-signed root certificates from CAs that have demonstrated why continued trust in them is justified. This list is known as a "Root Store." CA certificates included in the [Chrome Root Store](https://g.co/chrome/root-store) are selected on the basis of publicly available and verified information, such as that within the Common CA Database ([CCADB](https://ccadb.org/)), and ongoing reviews by the Chrome Root Program. - -The Chrome Root Program Policy below establishes the minimum requirements for CA certificates to be included as trusted in a default installation of Chrome. - -The Chrome Root Program continuously evolves this policy to enhance the security and resilience of the Internet ecosystem, consistent with Google's ongoing [commitment](#chromes-ongoing-commitment-to-transport-security) to secure and reliable network connections in Chrome. This involves establishing and periodically strengthening minimum requirements for CAs. New requirements, sometimes only for Applicants, are introduced to progressively raise the baseline of trust and drive the adoption of modern, agile, and secure Public Key Infrastructure (PKI) practices. This phased approach allows the program to integrate advancements and best practices, ensuring that certificates included in the Chrome Root Store consistently provide value to Chrome end users that exceeds the risk of their continued inclusion, while accounting for the practicalities of protecting users at scale. Aspects of value are principally demonstrated through the real-world use of the corresponding root CA certificate. This includes active TLS server authentication certificate issuance, observability of time-valid and unrevoked TLS server authentication certificates across the Internet, and direct reliance on those certificates by the Chrome Certificate Verifier when securing Chrome user connections. - -Except in the case of CA Owners applying for inclusion, this policy makes no stipulation on the characteristics or PKI use cases served by CAs not included in the current version of the Chrome Root Store. - -Any questions regarding this policy can be directed to chrome-root-program [at] google [dot] com. - -### Apply for Inclusion - -CA Owners that satisfy the requirements defined in the policy below may apply for self-signed root CA certificate inclusion in the Chrome Root Store using [these](apply-for-inclusion.md) instructions. - -Applicants are expected to continuously adhere to the policies outlined herein, irrespective of their inclusion request submission date. All Applicants are expected to satisfy the requirements set forth in both the ["Minimum Requirements for CAs included in the Chrome Root Store"](#1-minimum-requirements-for-cas-included-in-the-chrome-root-store) and ["Minimum Requirements for Applicant CAs Requesting Inclusion into the Chrome Root Store"](#2-minimum-requirements-for-applicant-cas-requesting-inclusion-into-the-chrome-root-store) Sections. Where requirements in these sections differ, the Applicant-specific requirements take precedence. - -If an Applicant's Root Inclusion Request is currently in the CCADB with a status of 'Verification By Root Store' and has not yet received a final determination, and this policy is updated to a new version, the Chrome Root Program will change the request's status to 'CA Providing Data.' Applicants must review and ensure compliance with the updated policy expectations before resubmitting their Root Inclusion Request for review by the Chrome Root Program. - -### Chrome's Ongoing Commitment to Transport Security - -The Chrome Root Program and 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 certificates in the Chrome Root Store. The selection and ongoing inclusion of certificates is done to enhance the security of Chrome. Certificates included in the Chrome Root Store must provide value to Chrome end users that exceeds the risk of their continued inclusion. Certificates that do not provide a broad service to all browser users will not be added to, or may be removed from the Chrome Root Store. Initial and sustained inclusion in the Chrome Root Store is not guaranteed to any CA Owner. -- applies metadata-based [name constraints](https://source.chromium.org/chromium/chromium/src/+/main:net/cert/root_store.proto;drc=7c2b25f6a19cfeeea67f0f43ed33617840bab33d;l=39) to certificates in the Chrome Root Store. These constraints, which may go beyond those in the CA certificates themselves, restrict the use of corresponding TLS server authentication certificates to specific Top-Level Domains (TLDs) and/or Second-Level Domains (SLDs). - -Chrome maintains a variety of mechanisms to protect its users from certificates that put their safety and privacy at risk, and is prepared to use them as necessary. A Chrome Root Program Participant's failure to follow the minimum requirements defined in this policy may result in the corresponding certificate's removal from the Chrome Root Store, limitations on Chrome's acceptance of the certificates they issue, or other technical or policy restrictions. Before taking such action, the Chrome Root Program always evaluates the broader context of an individual incident and considers it against the [factors](#151-incident-reports) significant to the Chrome Root Program. - -### Moving Forward, Together - -The "Moving Forward, Together" initiative envisions a future Internet ecosystem that includes modern, reliable, highly agile, purpose-driven PKIs with an emphasis on automation, simplicity, and security. - -Learn more about priorities and initiatives that may influence future versions of this policy [here](moving-forward-together.md). Please note "Moving Forward, Together" is future looking and does not describe normative requirements. - -### Additional Information - -If you're a Chrome user experiencing a certificate error and need help, please see [this support article](https://support.google.com/chrome/answer/6098869?hl=en). - -If you're a website operator, you can learn more about [why HTTPS matters](https://web.dev/why-https-matters/) and how to [secure your site with HTTPS](https://support.google.com/webmasters/answer/6073543). If you've got a question about a certificate you've been issued, please contact the CA that issued it. - -If you're responsible for a CA that is not trusted by default in Chrome and only issues certificates to your enterprise organization, sometimes called an "enterprise", "private" or "locally trusted" CA, the Chrome Root Program Policy does not apply to or impact your CA's PKI use cases. Enterprise CAs are used for issuing certificates to internal resources like intranet sites or applications that do not directly interact with external users of the public Internet (e.g., a TLS server authentication certificate issued to a corporate intranet site). - -Though uncommon, websites can also use certificates to identify clients (e.g., users) connecting to them. Besides ensuring it is well-formed, Chrome passes this type of certificate to the server, which then evaluates and enforces its chosen policy. The policies on this page do not apply to client authentication certificates. - -Learn more about the Chrome Root Store and Chrome Certificate Verifier [here](https://chromium.googlesource.com/chromium/src/+/main/net/data/ssl/chrome_root_store/faq.md). - -This policy, along with archived versions, is available in Markdown [here](https://github.com/GoogleChrome/chromerootprogram). - -## Change History - -| Version | Date | Note | -|-------- |----- |----- | -| 1.8 | 2026-02-05 | Updates include, but are not limited to: *(1)* limiting the number of root certificates per CA Owner included in the Chrome Root Store, *(2)* extending automation support requirements from Applicants to all existing CAs trusted by Chrome, *(3)* requiring CA policy documents to state adherence to the Chrome Root Program Policy, *(4)* setting expectations for industry engagement, *(5)* recommending practices for Subordinate CA lifecycle management, *(6)* encouraging support for the Certificate Transparency ecosystem, and *(7)* consolidating all requirements applicable only to Applicants in a dedicated section | -| 1.7 | 2025-07-15 | Updates include, but are not limited to: *(1)* add the ARI RFC numerical identifier, *(2)* remove requirements redundant with CCADB Policy Version 2.0 | -| 1.6 | 2025-02-15 | Updates include, but are not limited to: *(1)* the future phase-out of non-TLS server authentication dedicated hierarchies from the Chrome Root Store, *(2)* requirements for future Applicants related to automation support, promoting simplicity of policy documents, and the definition of a dedicated TLS server authentication PKI hierarchy, *(3)* improved alignment with the TLS Baseline Requirements following Ballot SC-077, *(4)* addition of subsection numbers and major reorganization of normative and non-normative requirements | -| 1.5 | 2024-01-16 | Updates include, but are not limited to: *(1)* incorporated CA Owner feedback in response to policy Version 1.4 (clean-ups and clarifications throughout the policy), *(2)* added new subsections for Root CA Key Material Freshness, Automation Support, and the Root CA Term-Limit, *(3)* aligned incident reporting format and timelines with CCADB.org | -| 1.4 | 2023-03-03 | Updates include, but are not limited to: *(1)* alignment with CCADB Policy Version 1.2 and the Baseline Requirements, *(2)* clarify requirements related to the submission of annual self-assessments, *(3)* clarify requirements to better align with program intent (e.g., CA Owner policy document freshness), *(4)* updated audit and incident reporting requirements to promote increased transparency, *(5)* require subordinate CA disclosures in CCADB, *(6)* clarify CA certificate issuance notification requirements | -| 1.3 | 2023-01-06 | Updated to include the CCADB Self-Assessment | -| 1.2 | 2022-09-01 | Updated to reflect the launch of the Chrome Root Program. Updates include, but are not limited to: *(1)* removal of pre-launch discussion, *(2)* clarifications resulting from the June 2022 Chrome CCADB survey, *(3)* minor reorganization of normative and non-normative requirements | -| 1.1 | 2022-06-01 | Updated in anticipation of the future Chrome Root Program launch. Updates include, but are not limited to: *(1)* future-dated Applicant requirements for dedicated TLS-hierarchies and key-pair freshness, *(2)* clarification of audit expectations, *(3)* requirements for cross-certificate issuance notification, *(4)* description of and requirements related to an annual self-assessment process, *(5)* an outline of priority Chrome Root Program initiatives | -| 1.0 | 2020-12-20 | Initial release | - -## Definitions - -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this policy are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119). - -This policy considers a "CA Owner" to be the organization or legal entity that is either: - -- represented in the subject DN of the CA certificate; or -- in possession or control of the corresponding private key capable of issuing new certificates, if not the same organization or legal entity directly represented in the subject DN of the certificate. - -This policy considers an "Applicant" to be an organization or legal entity that has an open "Root Inclusion Request" submitted to Google Chrome in the [CCADB](https://ccadb.org/). - -This policy uses the term "Chrome Root Program Participants" to describe: - -- Applicants; and -- CA Owners with either (a) a certificate included in the Chrome Root Store or (b) a CA certificate that validates to a certificate included in the Chrome Root Store. - -This policy uses the term "Externally-operated CA" to describe a subordinate CA certificate issued where the organization or legal entity in possession or control of the corresponding private key capable of issuing new certificates is not under the sole control of the CA Owner whose certificate is included in the Chrome Root Store. - -This policy considers a PKI hierarchy as "dedicated" if it is intended to serve one specific use case, for example, the issuance of TLS server authentication certificates. - -To continually raise the baseline of trust and drive the adoption of modern, agile, and secure PKIs, this policy sometimes "phases out" practices (sometimes referred to as a "phase-out"). Unless otherwise specified, phase-outs are accomplished using an [SCTNotAfter constraint](https://source.chromium.org/chromium/chromium/src/+/main:net/cert/root_store.proto;drc=a783c3bab474ff68e675e2753f91c92ca817e072;l=15?q=f:root_store.proto&ss=chromium) on a corresponding root CA’s certificate included in the Chrome Root Store. TLS server authentication certificates issued on or before a practice’s or PKI hierarchy’s specified phase-out date and time will be trusted in Chrome until expiry, whereas certificates issued after will not be trusted by default. The corresponding root CA’s certificate included in the Chrome Root Store will be removed upon the absence of unexpired and unrevoked TLS server authentication certificates issued prior to the phase-out date. - -## 1. Minimum Requirements for CAs Included in the Chrome Root Store - -The following requirements are effective immediately, unless explicitly stated as otherwise. - -### 1.1. PKI Policy Governance and Requirements - -Chrome Root Program Participants MUST satisfy the requirements defined in this policy, including taking responsibility for ensuring the continued compliance of all corresponding subordinate CAs and delegated third parties participating in the PKI. - -#### 1.1.1. Baseline Requirements - -Chrome Root Program Participants that issue TLS server authentication certificates trusted by Chrome MUST adhere to the latest version of the ["Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates"](https://cabforum.org/baseline-requirements-documents/) ("Baseline Requirements"). The Baseline Requirements are consensus-driven requirements owned by a community of participants represented in the [CA/Browser Forum](https://cabforum.org/) [Server Certificate Working Group](https://cabforum.org/working-groups/server/). No single organization, including Google, has the authority to grant exceptions to the Baseline Requirements. - -In some cases, this policy strengthens requirements described in the Baseline Requirements. - -#### 1.1.2. Common CA Database - -The Chrome Root Program relies on the [CCADB](https://ccadb.org/) to identify and maintain up-to-date information for Chrome Root Program Participants and the corresponding PKI hierarchies. - -Chrome Root Program Participants MUST adhere to the latest version of the [CCADB Policy](https://www.ccadb.org/policy). - -In some cases, this policy strengthens requirements described in the CCADB Policy. - -#### 1.1.3. Chrome Root Program Participant Policies - -**Effective June 15, 2026**, a Chrome Root Program Participant's CP or combined CP/CPS MUST explicitly state adherence to the latest published version of this policy and the CCADB Policy. This attestation SHOULD be made in Section 1.1 ("Overview"). - -### 1.2. Reducing Attack Surface of the Chrome Root Store - -#### 1.2.1. Maximum Number of CAs per CA Owner - -If a CA Owner already has two (2) or more self-signed root CA certificates included in the Chrome Root Store, the Chrome Root Program will only accept a new CCADB Root Inclusion Request to replace an existing certificate (i.e., 'one in, one out'). - -**Before June 15, 2026**, CA Owners with more than two (2) self-signed root CA certificates in the Chrome Root Store MUST submit a written consolidation plan to the Chrome Root Program. This plan MUST: - -1. Identify the two (2) root CA certificates that will remain in the Chrome Root Store, and -2. Provide a phase-out date for all of their other root CA certificates. The phase-out date MUST be **before September 15, 2027, (00:00 UTC)**. - -**Effective September 15, 2027**, the Chrome Root Store will only include a maximum of two (2) self-signed root CA certificates per CA Owner. PKI hierarchies being phased-out are not counted toward this limit. - -To further reduce negative impact to the ecosystem, the Chrome Root Store may temporarily continue to include more than two (2) self-signed root CA certificates past the specified consolidation timeline on a case-by-case basis. - -### 1.3. Modern Infrastructures - -#### 1.3.1. Promote use of Modern PKI Hierarchies - -##### 1.3.1.1. Root CA Succession Planning - -CA Owners SHOULD request for the replacement of a certificate included in the Chrome Root Store no later than five (5) years after the release date of the Chrome Root Store's initial inclusion of the certificate. - -Before a CA Owner submits a Root Inclusion Request to the CCADB, it MUST have issued a cross-certificate from the CA being replaced to the replacement CA. Due to the existence of the cross-certificate, TLS server authentication certificates issued by the replacement PKI hierarchy will be trusted by default in versions of Chrome relying on the Chrome Root Store, regardless of whether they are capable of receiving updates to the Chrome Root Store. - -Within no more than 90 calendar days after a replacement CA certificate being first distributed by the Chrome Root Store and as disclosed in the CCADB, the CA Owner MUST have transitioned all TLS server authentication certificate issuance intended to be trusted by default in Chrome from the cross-signing PKI hierarchy to the replacement PKI hierarchy. To technically enforce this transition, the CA being replaced will have a phase-out date set to 90 calendar days after the Applicant CA certificate being first distributed by the Chrome Root Store. While the CA Owner is not prohibited from continuing to issue certificates from the PKI hierarchy being replaced after this phase-out date, such certificates will not be trusted by default in Chrome. The CA certificate being replaced will be removed from the Chrome Root Store upon the absence of unexpired and unrevoked TLS server authentication certificates (excluding test certificates like those disclosed to the CCADB) disclosed to Certificate Transparency (CT) before this phase-out date. - -##### 1.3.1.2. Root CA Term-Limit - -Any root CA certificate with corresponding key material generated more than 15 years ago will be removed from the Chrome Root Store on an ongoing basis. - -The age of the key material will be determined by the earliest of either: - -- a key generation report issued by a Qualified Auditor that distinctly represents the corresponding key; or -- the validity date of the earliest appearing certificate that contains the corresponding public key. - -To phase-in these requirements in a manner that reduces negative impact to the ecosystem, affected root CA certificates included in the Chrome Root Store will be removed according to the schedule in the table below. - -| Key Material Created | Approximate Removal Date | -|--------------------- |------------------------- | -| Between January 1, 2006 and December 31, 2007 (inclusive) | April 15, 2026 | -| Between January 1, 2008 and December 31, 2009 (inclusive) | April 15, 2027 | -| Between January 1, 2010 and December 31, 2011 (inclusive) | April 15, 2028 | -| Between January 1, 2012 and April 14, 2014 (inclusive) | April 15, 2029 | -| After April 15, 2014 | 15 years from generation | - -To further reduce negative impact to the ecosystem, the Chrome Root Store may temporarily continue to include a root CA certificate past its defined term-limit on a case-by-case basis, if the corresponding CA Owner has submitted a Root Inclusion Request to the CCADB for a replacement root CA certificate at least one (1) year in advance of the approximate removal date. - -Other circumstances may lead to the removal of a root CA certificate included in the Chrome Root Store before the completion of its term. - -##### 1.3.1.3. Subordinate CA Certificate Lifecycle Management - -The lifecycle management of subordinate CA certificates plays a crucial role in promoting agility and resilience within the ecosystem. By setting clear expectations for their validity and renewal, the Chrome Root Program aims to align certificate profiles with modern best practices, reduce reliance on specific subordinate CA certificates that could be single points of failure, and discourage potentially harmful practices. This approach allows the ecosystem to benefit from continuous improvement efforts. - -To achieve these goals, it's encouraged that all subordinate CA certificates that validate to a certificate included in the Chrome Root Store align with the following practices: - -- Subordinate CA certificates SHOULD have a maximum validity period of three (3) years. -- CA Owners SHOULD create and deploy new subordinate CA certificates at least once every year. CA Owners SHOULD actively transition subscriber certificate issuance to these newly deployed CAs. - -#### 1.3.2. Promote use of Dedicated TLS Server Authentication PKI Hierarchies - -The Chrome Root Store is solely relied upon for TLS server authentication in Chrome; it is not used for any other PKI use case (e.g., TLS client authentication, secure email, code-signing, etc.). - -To align all PKI hierarchies included in the Chrome Root Store on the principle of serving only TLS server authentication use cases, the Chrome Root Program will phase-out multi-purpose roots from the Chrome Root Store. - -**Beginning June 15, 2026**, the Chrome Root Program will phase-out PKI hierarchies found in violation of the below requirements. In these cases, the phase-out date will be set to 90 calendar days following the violation’s detection. - -1. All corresponding unexpired and unrevoked subordinate CA certificates operated beneath an existing root included in the Chrome Root Store MUST: - - if disclosed to the CCADB **before June 15, 2026**: include the extendedKeyUsage extension and (a) only assert an extendedKeyUsage purpose of id-kp-serverAuth or (b) only assert extendedKeyUsage purposes of id-kp-serverAuth and id-kp-clientAuth. - - if disclosed to the CCADB **on or after June 15, 2026**: include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth. - - NOT contain a public key corresponding to any other unexpired or unrevoked certificate that asserts different extendedKeyUsage values. -2. All corresponding subscriber certificates issued **on or after March 15, 2027**, MUST include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth. - -To reduce negative impact to the ecosystem, the Chrome Root Store may temporarily continue to include a multi-purpose root CA certificate in the Chrome Root Store without an SCTNotAfter constraint on a case-by-case basis, but only if the corresponding CA Owner has submitted a Root Inclusion Request to the CCADB for a replacement root CA certificate before June 15, 2026. - -#### 1.3.3. Promote Cryptographic Agility and Resilience - -##### 1.3.3.1. Automation Support - -Certificate lifecycle management automation solutions ("automation solutions") increase agility and improve the [security](https://zanema.com/papers/imc23_stale_certs.pdf) and resilience of the Internet ecosystem. Automation solutions minimize "hands-on" input required from humans during certificate issuance and renewal. Routine certificate issuance and renewal SHOULD NOT involve human input except as needed for identity or business document verification related to IV, OV, or EV certificate issuance. - -**Effective March 15, 2027**, all unexpired and unrevoked subordinate CA certificates signed by a root CA certificate included in the Chrome Root Store MUST be integrated with an automation solution, minimally compliant with either [Section 1.3.3.1.1 ("ACME Solutions")](#13311-acme-solutions) or [Section 1.3.3.1.2 ("Non-ACME Solutions")](#13312-non-acme-solutions). Functionally, this means that every TLS server authentication certificate profile offered by a subordinate CA trusted in Chrome MUST be capable of being issued and renewed using an automation solution. CA Owners MUST attest that this requirement is met for each Baseline Requirements certificate policy OID the corresponding PKI hierarchy issues through a disclosure in the CCADB on the root certificate record of each CA included in the Chrome Root Store. - -Additionally, **effective March 15, 2027**, for each CCADB root certificate record corresponding to a root included in the Chrome Root Store, CA Owners MUST disclose at least one (1) automation solution for each Baseline Requirements certificate policy OID appearing in unexpired and unrevoked subscriber certificates. For each such OID, the CA Owner MUST use a disclosed automation solution to issue "Automation Test Certificates" to demonstrate its automation capabilities. Automation Test Certificates MUST be renewed at least once every 30 calendar days; however, at any point, the Chrome Root Program may request more frequent renewal. At least one (1) valid Automation Test Certificate corresponding to each Baseline Requirements certificate policy OID MUST be served by a publicly accessible website whose URL is disclosed to the CCADB on the corresponding intermediate certificate record. CA Owners are encouraged to issue "Short-lived Subscriber Certificates," as [introduced](https://cabforum.org/2023/07/14/ballot-sc-063-v4make-ocsp-optional-require-crls-and-incentivize-automation/) in Version 2.0.1 of the Baseline Requirements, for the Automation Test Certificates. - -The above requirements do not: - -- Prohibit PKI hierarchies from also supporting other "non-automated" methods of certificate issuance and renewal. -- Require website operators to rely on the automation solution(s) for certificate issuance and renewal. - -**Beginning March 15, 2027**, the Chrome Root Program will phase-out PKI hierarchies found issuing new certificates containing a Baseline Requirements certificate policy OID lacking an automation solution attestation disclosure in the CCADB. In these cases, the phase-out date will be set to 90 calendar days following the violation’s detection. - -###### 1.3.3.1.1. ACME Solutions - -PKI hierarchies SHOULD support the Automatic Certificate Management Environment (ACME) protocol. If ACME is supported: - -- The CA Owner MUST disclose to the CCADB at least one (1) ACME endpoint (i.e., directory URL) accessible to the Chrome Root Program for each Baseline Requirements certificate policy OID the corresponding PKI hierarchy issues (i.e., IV, DV, OV, EV). -- Each endpoint MUST support the following capabilities, as specified in [RFC 8555](https://www.rfc-editor.org/rfc/rfc8555): - - keyChange, - - newAccount, - - newNonce, - - newOrder, and - - revokeCert. -- Each endpoint's corresponding issuing CA(s) MUST support Certification Authority Authorization (CAA) Record Extensions for Account URI and ACME Method Binding, as specified in [RFC 8657](https://www.rfc-editor.org/rfc/rfc8657). -- PKI hierarchies supporting the ACME protocol MUST support ACME Renewal Information (ARI, [RFC 9773](https://datatracker.ietf.org/doc/rfc9773/)). -- ACME endpoints SHOULD support the Profiles extension ([RFC TBD](https://datatracker.ietf.org/doc/draft-ietf-acme-profiles/)). -- ACME endpoints SHOULD be publicly accessible. -- Each endpoint SHOULD be hosted using an appropriate and readily accessible online means that is available on a 24x7 basis. - -###### 1.3.3.1.2. Non-ACME Solutions - -While ACME support is encouraged, PKI hierarchies MAY support other automation solutions so long as the following characteristics are verifiably demonstrated to the Chrome Root Program. If the requirements in [Section 1.3.3.1.1 ("ACME Solutions")](#13311-acme-solutions) are not met, the CA Owner MUST disclose to the CCADB publicly available information that describes the other automation solution capability for each Baseline Requirements certificate policy OID that the corresponding PKI hierarchy issues and how a subscriber can leverage its benefits. For the purposes of this section, an "automation solution" is defined as the combination of the CA’s issuance interface (e.g., API) and compatible client software provided and maintained directly by the CA Owner that is ultimately operated by the TLS server authentication certificate requestor. This client software SHOULD be comparable in function and operation to an ACME client, and MAY be incorporated into Certificate Lifecycle Management tooling. - -- The automation solution MUST: - - generate a new key pair for each certificate request by default. - - generate and submit a Certificate Signing Request (CSR). - - support automated domain control validation (i.e., the automated solution automatically places the Request Token or Random Value in the appropriate location without "hands-on" input from humans, comparable to how ACME clients function), using at least one (1) of the following methods from the Baseline Requirements: - - DNS Change (Section 3.2.2.4.7) - - Agreed‑Upon Change to Website v2 (Section 3.2.2.4.18) - - support automated retrieval of the issued certificate (i.e., the automated solution downloads a copy of the certificate to a well-known location without "hands-on" input from humans, comparable to how ACME clients function). - - be sufficiently detailed in a completed "Automation Solution Assessment" form by requesting a copy from chrome-root-program [at] google [dot] com. - - support comparable features as described in [RFC 8657](https://www.rfc-editor.org/rfc/rfc8657) to restrict issuance capabilities to a specific CA account(s) using the "accounturi" CAA parameter and to restrict permitted domain validation methods using the "validationmethods" CAA parameter. - - support and/or request certificate revocation. - - support comparable features as described by ACME Renewal Information (ARI, [RFC 9773](https://datatracker.ietf.org/doc/rfc9773/)). - -- The automation solution SHOULD: - - support automated deployment (i.e., installation and configuration) of the issued certificate without "hands-on" input from humans (comparable to how ACME clients function). - - support comparable features as described by the ACME Profiles extension ([RFC TBD](https://datatracker.ietf.org/doc/draft-ietf-acme-profiles/)). - -#### 1.3.4. Promote Increased Transparency - -##### 1.3.4.1. Logging Precertificates - -CA Owners with CA certificates that validate to a certificate included in the Chrome Root Store SHOULD ensure that all TLS server authentication precertificates issued by such CAs are logged to at least one (1) CT log recognized by Chrome as [Usable or Qualified](https://www.gstatic.com/ct/log_list/v3/log_list.json) within 24 hours of issuance. - -**Effective June 15, 2026**, CA Owners with CA certificates that validate to a certificate included in the Chrome Root Store MUST ensure that all TLS server authentication precertificates issued by such CAs are logged to at least one (1) CT log recognized by Chrome as [Usable or Qualified](https://www.gstatic.com/ct/log_list/v3/log_list.json) before issuing the corresponding certificate. - -##### 1.3.4.2. Logging Final Certificates - -CA Owners with CA certificates that validate to a certificate included in the Chrome Root Store SHOULD ensure that all TLS server authentication certificates (i.e., "final certificates") issued by such CAs are logged to at least one (1) CT log recognized by Chrome as [Usable or Qualified](https://www.gstatic.com/ct/log_list/v3/log_list.json) within 24 hours of issuance. - -##### 1.3.4.3. Contributing to a Healthy CT Ecosystem - -Chrome Root Program Participants SHOULD contribute to the health and diversity of the CT ecosystem. Such contributions may include, but are not limited to: - -- reliably operating CT logs [Usable](https://googlechrome.github.io/CertificateTransparency/log_states.html#usable) in Chrome. -- providing engineering resources or expertise to assist CT log operators or related projects. -- developing and open-sourcing CT-related tools (e.g., for log operations, monitoring, auditing, or client-side integration). -- sponsoring research and development focused on improving CT scalability, security, privacy, or new log designs. -- hosting or mirroring CT logs for redundancy and geographical diversity. -- actively participating in CT standardization and policy development efforts. - -### 1.4. Audits - -Chrome Root Program Participant CAs MUST be audited in accordance with the table below. - -Audits MUST NOT rely on a version of the accepted audit criteria below if it has been superseded by more than 30 calendar days before the start of the corresponding audit period. - -| CA Type | EKU Characteristics** | Audit Criteria | -|-------- |---------------------- |--------------- | -| Root CA | N/A | **If WebTrust scheme**…

(1) "WebTrust Principles and Criteria for Certification Authorities"; and either…

- (A) "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security" or
- (B) "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline" and "WebTrust Principles and Criteria for Certification Authorities – Network Security"

and

(2) "WebTrust for CA - Extended Validation - SSL" (if issuing EV)

**If ETSI scheme*****...

(1) ETSI EN 319 411-1 LCP and [DVCP or OVCP];

or

(2) ETSI EN 319 411-1 [NCP or NCP+] and EVCP (if issuing EV)
-| Cross-Certified Subordinate CA | Either: (1) Certificate does not include an EKU; or (2) EKU is present and includes id-kp-serverAuth or anyExtendedKeyUsage | Same as above. | -| TLS Subordinate CA or Technically Constrained TLS Subordinate CA | Same as above. | Same as above. | -| Technically Constrained Non-TLS Subordinate CA | EKU is present and does not include id-kp-serverAuth or anyExtendedKeyUsage. | Minimally expected to be audited as defined in Section 8.7 of the BRs (self-audit). | -| All others | N/A | Minimally expected to be audited as defined in Section 8.7 of the BRs (self-audit). | - -\*\* CA certificates within PKI hierarchies included in the Chrome Root Store prior to September 1, 2022, MAY have EKU values as described in this table. However, PKI hierarchies added to the Chrome Root Store after September 1, 2022, MUST remain [dedicated to only TLS server authentication use cases](#132-promote-use-of-dedicated-tls-server-authentication-pki-hierarchies) - -\*\*\* accepted on a discretionary basis - -#### 1.4.1. Annual Audits -All Chrome Root Program Participant CAs MUST retain an unbroken, contiguous audit coverage. - -Recurring "complete" (i.e., "full", "full system", or "full re-assessment") audits MUST occur at least once every 365 calendar days (or 366 calendar days in a leap year). These audits MUST begin once a CA's key material has been generated and MUST continue until the corresponding root CA's key material has been destroyed or is no longer included in the Chrome Root Store. - -#### 1.4.2. Ad-Hoc Audits - -The Chrome Root Program may require Chrome Root Program Participants undergo additional ad-hoc audits, including, but not limited to, instances of CA private key destruction or verification of incident remediation. - -### 1.5. Reporting and Responding to Incidents - -The failure of a Chrome Root Program Participant to meet the commitments of this policy is considered an incident, as is any other situation that may impact the CA's integrity, trustworthiness, or compatibility. - -#### 1.5.1. Incident Reports - -Chrome Root Program Participants MUST publicly disclose and/or respond to incident reports in [Bugzilla](https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance), regardless of perceived impact. Reports MUST be submitted in accordance with the current version of [this](https://www.ccadb.org/cas/incident-report) CCADB incident report format and timelines. - -While all Chrome Root Program Participants MAY participate in the incident reporting process, the CA Owner whose corresponding certificate is included in the Chrome Root Store is encouraged to disclose and/or respond to incidents on behalf of the Chrome Root Program Participants included in its PKI hierarchy. - -If the Chrome Root Program Participant has not yet publicly disclosed an incident, they MUST notify chrome-root-program [at] google [dot] com and include an initial timeline for public disclosure. Chrome uses the information in the public disclosure as the basis for evaluating incidents. - -The Chrome Root Program will evaluate every incident on a case-by-case basis, and will work with the CA Owner to identify ecosystem-wide risks or potential improvements to be made that can help prevent future incidents. - -Chrome Root Program Participants MUST be detailed, candid, timely, and transparent in describing their architecture, implementation, operations, and external dependencies as necessary for the Chrome Root Program and the public to evaluate the nature of the incident and the CA Owner's response. When evaluating an incident response, the Chrome Root Program's primary concern is ensuring that browsers, other CA Owners, users, and website developers have the necessary information to identify improvements, and that the Chrome Root Program Participant is responsive to addressing identified issues. - -Factors that are significant to the Chrome Root Program when evaluating incidents include (but are not limited to): - -- a demonstration of understanding of the [root causes](https://sre.google/sre-book/postmortem-culture/) of an incident, -- a substantive commitment and timeline to changes that clearly and persuasively address the root cause, -- past history by the Chrome Root Program Participant in its incident handling and its follow through on commitments, and, -- the severity of the security impact of the incident. - -Due to the incorporation of the Baseline Requirements into CA policy documents, incidents may include a prescribed follow-up action, such as revoking impacted certificates within a certain timeframe. If the Chrome Root Program Participant does not perform the required follow-up actions, or does not perform them in the expected timeframe, the Chrome Root Program Participant MUST file a secondary incident report describing any certificates involved, the expected timeline to complete any follow-up actions, and what changes they are making to ensure they can meet these requirements consistently in the future. - -#### 1.5.2. Communicating with Chrome During Incidents - -The Chrome Root Program prioritizes and remains committed to promoting public disclosure and discussion of incidents, as they can affect the whole Internet ecosystem, not just Chrome and its users. The Chrome Root Program's sole responsibility when responding to incidents is upholding the safety and security of Chrome's users. - -As standard practice, the Chrome Root Program does not: - -- discuss ongoing public incident reports privately. We believe using information disclosed to the public as the basis for our response is the most transparent and effective way of upholding the security expectations of Chrome's users, while also ensuring the [factors](#151-incident-reports) that are significant to Chrome are adequately addressed; -- advise on or approve a CA Owner'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 CA Owner. - -### 1.6. Timely and Transparent Communications - -At any time, the Chrome Root Program may request additional information from a Chrome Root Program Participant using email or CCADB communications to verify the commitments and obligations outlined in this policy are being met, or as updates to policy requirements are being considered. Chrome Root Program Participants MUST provide the requested information within 14 calendar days unless specified otherwise. - -#### 1.6.1. Notification of CA Certificate Issuance - -CA Owners included in the Chrome Root Store MUST complete the "Chrome Root Program Notification of CA Certificate Issuance" form, made available by emailing chrome-root-program [at] google [dot] com, at least three (3) weeks before a CA in the corresponding hierarchy issues a CA certificate that: - -- extends the Chrome Root Store's trust boundary (i.e., the third-party subject CA Owner is either (a) not explicitly included in the Chrome Root Store at the time of issuance, or (b) is constrained (i.e., SCTNotAfter) and planned for removal), or -- replaces an unrevoked and unexpired CA certificate whose subject certificate CA Owner is not explicitly included in the Chrome Root Store. - -Examples of the above use cases include cross-certificates issued to CA Owners not represented in the Chrome Root Store and Externally-operated CA certificates. - -Such CA certificates MUST NOT be issued without the expressed approval of the Chrome Root Program. - -No other notification or approval is required. - -#### 1.6.2. Notification of Procurement, Sale, or other Change Control Events - -Chrome Root Program Participants MUST NOT assume trust is transferable. - -Where permissible by law, Chrome Root Program Participants MUST notify chrome-root-program [at] google [dot] com at least 30 calendar days before any impending: - -- procurements, -- sales, -- changes of ownership or operating control, -- cessations of operations, or -- other change control events involving PKI components that would materially affect the ongoing operations or perceived trustworthiness of a CA certificate included in the Chrome Root Store (e.g., changes to operational location(s), changes to delegated third parties involved in the PKI, etc.) or any Externally-operated CA. - -Not limited to the circumstances above, the Chrome Root Program reserves the right to require re-application to the Chrome Root Store. - -#### 1.6.3. Industry and Community Forum Engagement - -Chrome Root Program Participants are expected to maintain awareness of, and where relevant, actively engage in public discussions concerning CA practices, policy developments, and incidents, within minimally the following public forums: - -- [CCADB Public](https://groups.google.com/a/ccadb.org/g/public), -- the CA/Browser Forum [Server Certificate Working Group](https://groups.google.com/a/groups.cabforum.org/g/servercert-wg), [Validation Subcommittee](https://groups.google.com/a/groups.cabforum.org/g/validation), and [Network Security Working Group](https://lists.cabforum.org/mailman/listinfo/netsec) mailing lists, -- the Bugzilla [CA Certificate Compliance](https://bugzilla.mozilla.org/buglist.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance&bug_status=__open__&list_id=17629668) component, and -- the [Certificate Transparency Policy](https://groups.google.com/a/chromium.org/g/ct-policy) mailing list. - -Awareness of, and participation in, other key industry and community forums is encouraged. - -## 2. Minimum Requirements for Applicant CAs Requesting Inclusion into the Chrome Root Store - -The following requirements are effective immediately, unless explicitly stated as otherwise. - -### 2.1. PKI Policy Governance and Requirements - -Applicants MUST accurately describe the policies and practices of their CA(s) within a single CA policy document that is: - -- in the form of a combined CP/CPS. -- freely publicly available for examination. -- available in an authoritative English language version. -- available in either Markdown or AsciiDoc at a location disclosed to the CCADB ([GitHub-Flavored Markdown](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/about-writing-and-formatting-on-github) is preferred). -- except for Externally-operated CAs, authoritative for all CAs included in the corresponding PKI hierarchy. -- focused only on the specific PKI use case of issuing TLS server authentication certificates to websites. -- sufficiently detailed to assess the operations of the CA(s) and the compliance with these expectations and those of the Baseline Requirements, and MUST NOT conflict with either of these requirements. - -The immediately above requirements do not prohibit Applicants from maintaining additional policy documents, which may also be considered authoritative by other stakeholders. However, the consolidated policy document made available to the Chrome Root Program MUST NOT conflict with any additional policy documents that might exist for the corresponding PKI hierarchy. - -### 2.2. Root CA Key Material Freshness - -The Chrome Root Program only accepts CCADB Root Inclusion Requests from Applicant PKI hierarchies with corresponding root CA key material generated within five (5) years of application to the Chrome Root Store. - -Applicants MUST submit written evidence to the CCADB identifying the date(s) of the key generation ceremony and an attestation to the Applicant's adherence to the requirements defined in Sections 6.1.1.1 ("CA Key Pair Generation") and 6.2 ("Private Key Protection and Cryptographic Module Engineering Controls") of the Baseline Requirements from a Qualified Auditor using an approved format, in accordance with the table below. - -| Audit Scheme | Qualified Auditor Criteria | Report Format Criteria | -|------------- |--------------------------- |----------------------- | -| WebTrust | an [enrolled](https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/licensed-webtrust-practitioners-international) WebTrust practitioner | WebTrust "Reporting on Root Key Generation" report | -| ETSI | a [member](https://www.acab-c.com/members/) of the Accredited Conformity Assessment Bodies' Council (ACAB'c) | ACAB'c Key and Certificate Ceremony Audit Attestation Letter | - -If key material is not used to issue a self-signed root CA certificate on the same date it was generated, Applicants MUST present written evidence from a Qualified Auditor, attesting that keys were minimally protected in a manner consistent with the requirements defined in Section 6.2 ("Private Key Protection and Cryptographic Module Engineering Controls") of the Baseline Requirements from the time of generation to the time the self-signed certificate was issued. Publicly-accessible links for these documents MUST be disclosed to the CCADB. - -### 2.3. Dedicated TLS Server Authentication PKI Hierarchies - -The Chrome Root Program will only accept CCADB Root Inclusion Requests from Applicant PKI hierarchies that are dedicated to TLS server authentication certificate issuance. - -To qualify as a dedicated TLS server authentication PKI hierarchy under this policy: - -1. All corresponding unexpired and unrevoked subordinate CA certificates operated beneath an Applicant root CA certificate MUST: - - if disclosed to the CCADB **before June 15, 2025**: include the extendedKeyUsage extension and (a) only assert an extendedKeyUsage purpose of id-kp-serverAuth or (b) only assert extendedKeyUsage purposes of id-kp-serverAuth and id-kp-clientAuth. - - if disclosed to the CCADB **on or after June 15, 2025**: include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth. - - NOT contain a public key corresponding to any other unexpired or unrevoked certificate that asserts different extendedKeyUsage values. -2. All corresponding unexpired and unrevoked subscriber (i.e., TLS server authentication) certificates MUST include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth. - -### 2.4. Promote Cryptographic Agility and Resilience - -All unexpired and unrevoked subordinate CA certificates included in an Applicant PKI hierarchy MUST be integrated with an automation solution, minimally compliant with either [Section 1.3.3.1.1 ("ACME Solutions")](#13311-acme-solutions) or [Section 1.3.3.1.2 ("Non-ACME Solutions")](#13312-non-acme-solutions). Functionally, this means that every TLS server authentication certificate profile offered by the PKI hierarchy MUST be capable of being issued and renewed using an automation solution. CA Owners MUST attest that this requirement is met for each Baseline Requirements certificate policy OID the corresponding Applicant PKI hierarchy issues through a disclosure in the CCADB on the root certificate record of each CA certificate intending to be included in the Chrome Root Store. - -For each Baseline Requirements certificate policy OID an Applicant intends to issue, the Applicant MUST disclose at least one (1) automation solution to the CCADB. For each such OID, the Applicant MUST use a disclosed automation solution to issue "Automation Test Certificates" to demonstrate its automation capabilities. Automation Test Certificates MUST be renewed at least once every 30 calendar days; however, at any point, the Chrome Root Program may request more frequent renewal. At least one (1) valid Automation Test Certificate corresponding to each Baseline Requirements certificate policy OID MUST be served by a publicly accessible website whose URL is disclosed to the CCADB on the corresponding intermediate certificate record. Applicants are encouraged to issue "Short-lived Subscriber Certificates," as [introduced](https://cabforum.org/2023/07/14/ballot-sc-063-v4make-ocsp-optional-require-crls-and-incentivize-automation/) in Version 2.0.1 of the Baseline Requirements, for the Automation Test Certificates. - -### 2.5. Annual Audits - -Applicant PKI hierarchies MUST provide evidence of at least one (1) complete audit by disclosing the applicable ETSI Audit Attestation Letter(s) or WebTrust Assurance Report(s) to the CCADB before submitting a CCADB Root Inclusion Request to Google Chrome. The initial complete audit SHOULD cover a period of at least 180 calendar days. - -For Applicant PKI hierarchies subject of a CCADB Root Inclusion Request submitted to Google Chrome: - -- Except for Externally-operated CAs, when CAs in the hierarchy are assessed against: - - **only a single audit scheme** (e.g., all CAs in the hierarchy are only assessed against the WebTrust scheme), they MUST fall under a single audit scope (i.e., represented in a single WebTrust Assurance Report) for the assessed criteria (e.g., (a) WebTrust Principles and Criteria for Certification Authorities, (b) WebTrust Principles and Criteria for Certification Authorities - Network Security, (c) WebTrust Principles and Criteria for Certification Authorities - SSL Baseline, or (d) WebTrust for CA - Extended Validation - SSL). - - **multiple audit schemes** (e.g., some CAs are assessed against the WebTrust scheme and others are assessed against the ETSI scheme), all CAs assessed against each respective scheme MUST fall under a single audit scope for that scheme (i.e., all ETSI-assessed CAs are represented in a single ETSI Audit Attestation Letter, and all WebTrust CAs are represented in a single WebTrust Assurance Report) for the assessed criteria. - -If accepted into the Chrome Root Store, Applicant PKI hierarchies MUST continue this practice for the duration of its inclusion. +* **[The Chrome Quantum-resistant Root Program](cqrp/draft-policy.md)**: Designed for the post-quantum era, this program uses Merkle Tree Certificates (MTCs) to deliver quantum-safe security without slowing down page connections. Learn more about Google's planned adoption of MTCs on the [Google Security Blog](https://blog.google/security/cultivating-a-robust-and-efficient-quantum-safe-https/). diff --git a/content/policy-archive/index.md b/content/policy-archive/index.md new file mode 100644 index 0000000..491b967 --- /dev/null +++ b/content/policy-archive/index.md @@ -0,0 +1,18 @@ +--- +title: Chrome Root Program - Policy Archive +--- +# Policy Archive + +The following table contains historical versions of the Chrome Root Program Policy. These versions have been superseded by the current policy and are maintained here for historical reference. + +| Policy Version | Effective Date | Date Superseded | +| :--- | :--- | :--- | +| [Version 1.8](../crp/policy.md) *(Current)* | 2026-02-05 | N/A | +| [Version 1.7](policy-version-1-7/) | 2025-07-15 | 2026-02-05 | +| [Version 1.6](policy-version-1-6/) | 2025-02-15 | 2025-07-15 | +| [Version 1.5](policy-version-1-5/) | 2024-01-16 | 2025-02-15 | +| [Version 1.4](policy-version-1-4/) | 2023-03-03 | 2024-01-16 | +| [Version 1.3](policy-version-1-3/) | 2023-01-06 | 2023-03-03 | +| [Version 1.2](policy-version-1-2/) | 2022-09-01 | 2023-01-06 | +| [Version 1.1](policy-version-1-1/) | 2022-06-01 | 2022-09-01 | +| [Version 1.0](policy-version-1-0/) | 2020-12-20 | 2022-06-01 | diff --git a/content/policy-archive/policy-version-1-6.md b/content/policy-archive/policy-version-1-6.md index 7bb5e59..256dfda 100644 --- a/content/policy-archive/policy-version-1-6.md +++ b/content/policy-archive/policy-version-1-6.md @@ -58,7 +58,7 @@ The Chrome Root Program Policy below establishes the minimum requirements for CA ### Apply for Inclusion -CA Owners that satisfy the requirements defined in the policy below may apply for self-signed root CA certificate inclusion in the Chrome Root Store using [these](apply-for-inclusion.md) instructions. +CA Owners that satisfy the requirements defined in the policy below may apply for self-signed root CA certificate inclusion in the Chrome Root Store using [these](../apply-for-inclusion.md) instructions. ### Chrome's Ongoing Commitment to Transport Security @@ -75,7 +75,7 @@ Chrome maintains a variety of mechanisms to protect its users from certificates The "Moving Forward, Together" initiative envisions a future Web PKI that includes modern, reliable, highly agile, purpose-driven PKIs with an emphasis on automation, simplicity, and security. -Learn more about priorities and initiatives that may influence future versions of this policy [here](moving-forward-together.md). Please note "Moving Forward, Together" is future looking and does not describe normative requirements. +Learn more about priorities and initiatives that may influence future versions of this policy [here](../moving-forward-together.md). Please note "Moving Forward, Together" is future looking and does not describe normative requirements. ### Additional Information diff --git a/content/policy-archive/policy-version-1-7.md b/content/policy-archive/policy-version-1-7.md index 1fb6209..94595b2 100644 --- a/content/policy-archive/policy-version-1-7.md +++ b/content/policy-archive/policy-version-1-7.md @@ -54,7 +54,7 @@ The Chrome Root Program Policy below establishes the minimum requirements for CA ### Apply for Inclusion -CA Owners that satisfy the requirements defined in the policy below may apply for self-signed root CA certificate inclusion in the Chrome Root Store using [these](apply-for-inclusion.md) instructions. +CA Owners that satisfy the requirements defined in the policy below may apply for self-signed root CA certificate inclusion in the Chrome Root Store using [these](../apply-for-inclusion.md) instructions. ### Chrome's Ongoing Commitment to Transport Security @@ -71,7 +71,7 @@ Chrome maintains a variety of mechanisms to protect its users from certificates The "Moving Forward, Together" initiative envisions a future Internet ecosystem that includes modern, reliable, highly agile, purpose-driven PKIs with an emphasis on automation, simplicity, and security. -Learn more about priorities and initiatives that may influence future versions of this policy [here](moving-forward-together.md). Please note "Moving Forward, Together" is future looking and does not describe normative requirements. +Learn more about priorities and initiatives that may influence future versions of this policy [here](../moving-forward-together.md). Please note "Moving Forward, Together" is future looking and does not describe normative requirements. ### Additional Information diff --git a/content/static/crp.css b/content/static/crp.css index d20119f..875f730 100644 --- a/content/static/crp.css +++ b/content/static/crp.css @@ -129,3 +129,79 @@ td { border-width: 1px; word-break: keep-all; } + +/* GitHub-Style Markdown Alerts (> [!NOTE], > [!WARNING], > [!TIP], > [!IMPORTANT], > [!CAUTION]) */ +blockquote.markdown-alert { + padding: 0.75rem 1rem; + margin: 1rem 0; + color: #24292f; + border-left: 0.25em solid #0969da; + background-color: #f6f8fa; + border-radius: 0 6px 6px 0; +} + +blockquote.markdown-alert.markdown-alert-note { + border-left-color: #0969da; +} + +blockquote.markdown-alert.markdown-alert-tip { + border-left-color: #1a7f37; +} + +blockquote.markdown-alert.markdown-alert-important { + border-left-color: #8250df; +} + +blockquote.markdown-alert.markdown-alert-warning { + border-left-color: #9a6700; +} + +blockquote.markdown-alert.markdown-alert-caution { + border-left-color: #cf222e; +} + +.markdown-alert-title { + display: flex; + align-items: center; + font-weight: 600; + margin-top: 0; + margin-bottom: 0.5rem; + font-size: 14px; + line-height: 1; +} + +.markdown-alert-note .markdown-alert-title { + color: #0969da; +} + +.markdown-alert-tip .markdown-alert-title { + color: #1a7f37; +} + +.markdown-alert-important .markdown-alert-title { + color: #8250df; +} + +.markdown-alert-warning .markdown-alert-title { + color: #9a6700; +} + +.markdown-alert-caution .markdown-alert-title { + color: #cf222e; +} + +.markdown-alert-title svg { + margin-right: 8px; + fill: currentColor; + flex-shrink: 0; +} + +blockquote.markdown-alert p { + margin-top: 0.25rem; + margin-bottom: 0.25rem; +} + +blockquote.markdown-alert p:last-child { + margin-bottom: 0; +} + diff --git a/src/generate.py b/src/generate.py index 5410c82..3cea005 100644 --- a/src/generate.py +++ b/src/generate.py @@ -9,6 +9,7 @@ from collections import namedtuple import urllib.parse +import urllib.request from jinja2 import Environment, FileSystemLoader @@ -77,6 +78,41 @@ def run(self, root): element.set("href", target) +ALERT_TYPES = { + "NOTE": ("Note", ""), + "TIP": ("Tip", ""), + "IMPORTANT": ("Important", ""), + "WARNING": ("Warning", ""), + "CAUTION": ("Caution", "") +} + +import xml.etree.ElementTree as ET + +class GitHubAlertsTreeprocessor(Treeprocessor): + def run(self, root): + for bq in root.iter("blockquote"): + first_p = bq.find("p") + if first_p is not None and first_p.text: + text = first_p.text.strip() + for alert_key, (title, svg) in ALERT_TYPES.items(): + tag = f"[!{alert_key}]" + if text.startswith(tag): + bq.attrib["class"] = f"markdown-alert markdown-alert-{alert_key.lower()}" + remainder = text[len(tag):].lstrip() + first_p.text = remainder + + title_p = ET.Element("p", {"class": "markdown-alert-title"}) + svg_elem = ET.fromstring(svg) + title_p.append(svg_elem) + svg_elem.tail = f" {title}" + bq.insert(0, title_p) + break + +class GitHubAlertsExtension(Extension): + def extendMarkdown(self, md): + md.treeprocessors.register(GitHubAlertsTreeprocessor(md), "github_alerts", priority=20) + + class RemoveMdExtension(Extension): def __init__(self, base_url, dir_path): @@ -134,10 +170,16 @@ def render_file(input_path, output_path, env, page_context={}): "tables", "toc", "attr_list", + GitHubAlertsExtension(), RemoveMdExtension( page_context.get("base_url"), page_context.get("dir_path") ), ], + extension_configs={ + "toc": { + "toc_depth": "3-3", + } + }, ) # Wrap with a template @@ -293,6 +335,19 @@ def main(): # Ensure output directory exists os.makedirs(config.get("output_dir"), exist_ok=True) + # Fetch latest cosigners.json at build time for fallback + try: + req = urllib.request.Request("https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json", headers={"User-Agent": "Mozilla/5.0"}) + with urllib.request.urlopen(req) as resp: + fallback_bytes = resp.read() + static_dir = os.path.join(config.get("output_dir"), "static") + os.makedirs(static_dir, exist_ok=True) + with open(os.path.join(static_dir, "cosigners_fallback.json"), "wb") as f: + f.write(fallback_bytes) + print("Successfully saved static/cosigners_fallback.json for build fallback") + except Exception as e: + print(f"Warning: Could not fetch cosigners.json at build time ({e})") + # Render the markdow and copy assets res = render_markdown( config.get("input_dir"), diff --git a/templates/base.html b/templates/base.html index 5e0ef3a..7c42c49 100644 --- a/templates/base.html +++ b/templates/base.html @@ -11,28 +11,31 @@
-

Policy

- -

Resources

- -

Policy Archive

- -
+
{{ content | safe }}