├── .gitignore ├── CODE_OF_CONDUCT.md ├── README.md ├── ccadb └── policy.md └── rootstore └── policy.md /.gitignore: -------------------------------------------------------------------------------- 1 | Darkmod.log 2 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Community Participation Guidelines 2 | 3 | This repository is governed by Mozilla's code of conduct and etiquette guidelines. 4 | For more details, please read the 5 | [Mozilla Community Participation Guidelines](https://www.mozilla.org/about/governance/policies/participation/). 6 | 7 | ## How to Report 8 | For more information on how to report violations of the Community Participation Guidelines, please read our '[How to Report](https://www.mozilla.org/about/governance/policies/participation/reporting/)' page. 9 | 10 | 16 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Mozilla PKI Policy 2 | 3 | This repository contains documents relating to Mozilla's PKI policies, such as 4 | its [certificate root program](https://wiki.mozilla.org/CA). The 5 | owner of these documents is the Module Owner of the "[Mozilla CA Certificate 6 | Policy](https://wiki.mozilla.org/Modules/Activities#Mozilla_CA_Certificate_Policy)" 7 | module. Mozilla's PKI policies can be discussed in https://groups.google.com/a/mozilla.org/g/dev-security-policy. 8 | Archives of previous discussions are in https://groups.google.com/g/mozilla.dev.security.policy. 9 | 10 | ## Root Program ## 11 | 12 | You can find out [how to apply to be included in Mozilla's root 13 | program](https://wiki.mozilla.org/CA/Application_Process). There is also a 14 | [list of included roots](https://wiki.mozilla.org/CA/Included_Certificates). 15 | 16 | ### Using Mozilla's Root Store ### 17 | 18 | The decisions Mozilla makes with regards to the inclusion or exclusion of CA 19 | certificates in its root store are directly tied to the capabilities and 20 | behaviours of the software Mozilla distributes. Sometimes, a security change 21 | is made wholly or partly in the software instead of the root store. Further, 22 | Mozilla does not promise to take into account the needs of other users of its 23 | root store when making such decisions. 24 | 25 | Therefore, anyone considering bundling [Mozilla's root store](https://wiki.mozilla.org/CA/Included_Certificates) with other 26 | software needs to be aware of the issues surrounding providing a root store, 27 | and committed to making sure that they maintain security for their users by 28 | carefully observing Mozilla's actions and taking appropriate steps of their 29 | own. On a best-efforts basis, Mozilla maintains a 30 | [list of additional things](https://wiki.mozilla.org/CA/Additional_Trust_Changes) 31 | users of our store might need to consider. 32 | 33 | [Data Usage Terms](https://www.ccadb.org/rootstores/usage#ccadb-data-usage-terms) 34 | -------------------------------------------------------------------------------- /ccadb/policy.md: -------------------------------------------------------------------------------- 1 | # Common CCADB Policy # 2 | 3 | *Version 1.0.4* 4 | 5 | Several Web PKI root store operators (“Stores”) have collaborated to create 6 | the Common Certificate Authority Database (CCADB), a data repository of 7 | certificate and Certificate Authority (CA) information. CAs who wish to be 8 | included in participating stores will need to maintain certain information in 9 | the CCADB. This document explains what is required of CAs who are required by 10 | Store policy to use the CCADB. 11 | 12 | Stores may have their own additional CCADB-related requirements. For each root 13 | certificate, CAs must comply with the additional requirements pertaining to the 14 | Stores which contain that certificate. 15 | 16 | This document does not cover how to obtain write access to the CCADB or how to 17 | use the CCADB’s web interface. Those topics are outside its scope. CAs should 18 | contact an appropriate Store for assistance. 19 | 20 | ## 1. General Provisions ## 21 | 22 | Regardless of more specific provisions in these requirements, CAs have an 23 | overarching responsibility to keep the information in the CCADB about 24 | themselves, their operations and their certificates accurate, and make updates 25 | in a timely fashion. 26 | 27 | All data in the CCADB may be made public or semi-public in a variety of forms; 28 | CAs should not place any information in the CCADB which they wish to keep 29 | confidential. However, Stores are not obliged to publish any CCADB information. 30 | 31 | All client devices that are used to download Personally Identifiable Information 32 | from the CCADB must employ disk based encryption. 33 | 34 | ## 2. Contact Information ## 35 | 36 | CAs are required to provide the following information for a Primary Point of 37 | Contact (POC), and at least one other POC, who may or may not be Primary: 38 | 39 | * Name 40 | * Office email address 41 | * Office hours phone number 42 | 43 | CAs may optionally designate further POCs, supplying at least one contact 44 | method for each. CAs must also supply one or two non-personal contact email 45 | aliases which are more likely to continue working as personnel change; these 46 | are maintained as part of the CA’s organizational entry. 47 | 48 | All Primary POCs should be authorized to speak for and to bind the CA that they 49 | represent. At least one of the Primary POCs will hold a CA Community license; 50 | other POCs may also apply to a Store to be issued one. Those Primary POCs with 51 | a CA Community license are ultimately responsible for keeping CCADB data 52 | up-to-date for their CA. 53 | 54 | Notification of security and audit-related issues will be emailed to all 55 | Primary POCs and the first email alias. CAs are advised to make sure those 56 | addresses reach sufficient people such that they can respond to an issue 57 | in an appropriate timeframe. 58 | 59 | If POC or email alias information needs to be updated, the CA should notify one 60 | of the Stores containing their root certificates, because this information may 61 | only be edited by Stores. See the Store policy documents for Store contact 62 | information. 63 | 64 | ## 3. Root Certificates ## 65 | 66 | A root certificate is a certificate which is capable of issuing new 67 | certificates, which a CA designates as a trust anchor. It will usually be 68 | self-signed. CAs are required to maintain correct and current information about 69 | their root certificates. 70 | 71 | If root certificate information needs to be updated, the CA should notify one of 72 | the Stores containing the certificate, because this information may only be edited 73 | by Stores. See the Store policy documents for Store contact information. 74 | 75 | To update audit information for a root certificate, create an [Audit Case][CCADB-Audit-Case]. 76 | 77 | ## 4. Intermediate Certificates ## 78 | 79 | An intermediate certificate is a certificate capable of issuing new 80 | certificates that is not a root certificate. To determine which intermediate 81 | certificates must be entered into the CCADB, refer to the individual Store policy 82 | documents. This includes certificates that are revoked. For 83 | newly-created intermediate certificates, this must happen before the 84 | certificate begins issuing publicly-trusted certificates. 85 | 86 | Each instance (i.e. PEM data) of an intermediate certificate only needs to be 87 | included in the CCADB once, even if it chains up to two root certificates. 88 | 89 | If an intermediate certificate is revoked, the CCADB must be updated to mark it 90 | as revoked, giving the reason why, within 24 hours for a security incident, and 91 | within 7 days for any other reason. 92 | 93 | ## 5. Policies, Practices and Audit Information ## 94 | 95 | In the records for both root certificates and intermediate certificates, CAs 96 | are required to provide details of the Certificate Policy (CP) and/or 97 | Certificate Practice Statement (CPS) documents relating to that certificate, 98 | and also statements of attestation of their conformance to various requirements 99 | and other operational criteria (“audits”), those statements being made by a 100 | competent independent party or parties. These documents are hosted elsewhere 101 | and the URLs are stored in the CCADB. The URLs to such CPs, CPSes and audits, 102 | and any metadata about them such as the name of the auditor or the date of the 103 | audit, need to be updated as new information become available. For technical 104 | reasons, URLs to audit statements need to point to a PDF file. 105 | 106 | The entry for each intermediate certificate has "Audits Same as Parent" and 107 | "CP/CPS Same as Parent" checkboxes. When those are checked, the details do not 108 | need to be duplicated from the parent cert. However, the intermediate 109 | certificate must be specifically listed in the audit statements of the parent 110 | certificate. 111 | 112 | URLs for the following documents are required for each certificate: 113 | 114 | * Certificate Policy (CP) 115 | * Certificate Practice Statement (CPS) 116 | * Standard audit (WebTrust or ETSI) 117 | * Baseline Requirements (BR) audit (if the certificate is capable of issuing 118 | TLS/SSL server certificates) 119 | * Extended Validation (EV) SSL and/or Code Signing audit (if applicable) 120 | 121 | CAs must provide English versions of any Certificate Policy, Certification 122 | Practice Statement and Audit documents which are not originally in English, 123 | with version numbers matching the document they are a translation of. The 124 | English version is not required to be authoritative in all cases of dispute, 125 | but the CA must attest that the translation is not materially different to the 126 | original. 127 | 128 | ## 6. Mailshots ## 129 | 130 | From time to time, a Store may use the CCADB to send information to CAs. 131 | Mailshots will be sent to at least the Primary POC and the email aliases, and 132 | may also go to one or more of the other POCs; the exact recipient list is 133 | defined by the Store sending the information. 134 | 135 | ----- 136 | 137 | Any copyright in this document is 138 | [dedicated to the Public 139 | Domain](http://creativecommons.org/publicdomain/zero/1.0/). 140 | 141 | [CCADB-Audit-Case]: https://ccadb.org/cas/updates 142 | -------------------------------------------------------------------------------- /rootstore/policy.md: -------------------------------------------------------------------------------- 1 | # Mozilla Root Store Policy 2 | 3 | *Version 3.0* 4 | 5 | *[Effective March 15, 2025][Policy-Archive]* 6 | 7 | ## 1. Introduction 8 | 9 | When distributing binary and source code versions of Firefox, Thunderbird, and 10 | other Mozilla-related software products, Mozilla includes with such software 11 | a set of X.509v3 root certificates from various Certification 12 | Authority (CA) operators. As used herein, a CA operator is an organization or legal entity that is in possession or control of a CA certificate and its associated keys, which are capable of being used to issue new certificates. The included CA certificates have their "trust bits" 13 | set for various purposes, so that the software in question can use the CA 14 | certificates to anchor a chain of trust for certificates used by TLS servers 15 | and S/MIME email users without having to ask users for further permission or 16 | information. 17 | 18 | This policy covers how the default set of certificates and associated trust 19 | bits is maintained for software products distributed by Mozilla. Other entities 20 | distributing software based on ours are free to adopt their own policies. In 21 | particular, under the terms of the relevant Mozilla license(s), distributors of 22 | such software are permitted to add or delete CA certificates and modify the 23 | values of the trust bits in the versions that they distribute. However, 24 | as with other software modifications, by making such changes a distributor may 25 | well affect its ability to use Mozilla trademarks in connection with its 26 | versions of the software. See the [Mozilla trademark policy][Trademark-Policy] for more 27 | information. 28 | 29 | ### 1.1 Scope 30 | 31 | This policy applies to CA operators and the certificates they issue or control that match any of the following: 32 | 33 | 1. CA certificates included in, or under consideration for inclusion in, the 34 | Mozilla root store; 35 | 36 | 2. intermediate certificates that have at least one valid, unrevoked chain up 37 | to such a CA certificate and that are technically capable of issuing 38 | working server or email certificates. Intermediate certificates that are not considered to be technically capable will contain either: 39 | 40 | * an Extended Key Usage (EKU) extension that does not contain any of 41 | these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, 42 | id-kp-emailProtection; or 43 | * name constraints that do not allow Subject Alternative Names (SANs) of 44 | any of the following types: dNSName, iPAddress, SRVName, or rfc822Name; *and* 45 | 46 | 3. end entity certificates that have at least one valid, unrevoked chain up 47 | to such a CA certificate through intermediate certificates that are all in 48 | scope and 49 | 50 | * an EKU extension that contains the anyExtendedKeyUsage KeyPurposeId, or no EKU extension; 51 | * an EKU extension that contains the id-kp-serverAuth KeyPurposeId; or 52 | * an EKU extension that contains the id-kp-emailProtection KeyPurposeId and an rfc822Name or an otherName of type id-on-SmtpUTF8Mailbox in the subjectAltName. 53 | 54 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 55 | "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 56 | interpreted as described in RFC 2119. 57 | 58 | ### 1.2 Policy Ownership 59 | 60 | Mozilla has appointed a [CA Certificate module owner][CA-Cert-Module] 61 | and peers to evaluate new CA requests on our behalf and to make decisions 62 | regarding all matters relating to CA certificates included in our root store. 63 | 64 | Further, Mozilla has appointed a [Mozilla CA Certificate Policy module 65 | owner][CA-Policy-Module] and peers to maintain this policy. The policy will 66 | only be changed after public consultation with the Mozilla community, in order 67 | to ensure that all views are taken into account. This policy MAY be updated periodically in accordance with the [Process for Updating the Root Store Policy][Policy-Update-Process]. CA operators MUST adhere to the current version of this policy. You can contact the Mozilla CA 68 | Certificate Policy module team at [certificates@mozilla.org][Email-Us] if you 69 | have questions about this policy. 70 | 71 | CA operators or others objecting to a particular decision by either team MAY appeal to 72 | the [Firefox Technical Leadership Module Committee][Gov-Module] who will make a final 73 | decision. 74 | 75 | ## 2. Certificate Authorities 76 | 77 | ### 2.1 CA Operations 78 | 79 | CA operators whose certificates are included in Mozilla's root store MUST: 80 | 81 | 1. provide some service relevant to users of our software 82 | products; 83 | 2. follow industry best practice for securing their networks, for example 84 | by conforming to the [CA/Browser Forum's Network and Certificate System Security Requirements][NSRs] or a 85 | successor document; 86 | 3. enforce multi-factor authentication for all accounts capable of causing 87 | certificate issuance or performing Registration Authority or Delegated 88 | Third Party functions, or implement technical controls operated by the CA 89 | to restrict certificate issuance through the account to a limited set of 90 | pre-approved domains or email addresses; 91 | 4. prior to issuing certificates, verify certificate 92 | requests in a manner that we deem acceptable for the stated 93 | purpose(s) of the certificates; 94 | 5. verify each dNSName or IPAddress in a SAN or commonName in server certificates in accordance with sections 3.2.2.4 and 3.2.2.5 of the CA/Browser Forum's [TLS Baseline Requirements][TLS-BRs] ("TLS BRs") at intervals of 398 days or less, and verify that all other information that is included in server certificates remains current and correct at intervals of 825 days or less; 95 | 6. otherwise operate in accordance with published criteria that we 96 | deem acceptable; *and* 97 | 7. ensure that all certificates within the scope of this policy, 98 | as described in Section 1.1, adhere to this policy. 99 | 100 | CA operators MUST follow and be aware of discussions in both the 101 | [Mozilla dev-security-policy][MDSP] forum and the [CCADB Public List][CCADB-List], where root store policies and program updates are announced and public discussions of root inclusion requests occur. They are encouraged, but not required, to contribute to those 102 | discussions. 103 | 104 | ### 2.2 Validation Practices 105 | 106 | We consider verification of certificate signing requests to be acceptable if it 107 | meets or exceeds the following requirements: 108 | 109 | 1. all information that is supplied by the certificate subscriber 110 | MUST be verified by using an independent source of information 111 | or an alternative communication channel before it is included in 112 | the certificate; 113 | 2. for a certificate capable of being used for digitally signing or encrypting 114 | email messages, the CA operator MUST take reasonable measures to verify that 115 | the entity submitting the request controls the email account 116 | associated with the email address referenced in the certificate 117 | *or* has been authorized by the email account holder to act on 118 | the account holder’s behalf. This MUST be done using one or more of the methods documented in section 3.2.2 of the [CA/Browser Forum's S/MIME Baseline Requirements][SMIME-BRs] ("S/MIME BRs"). The CA operator's CPS (or, if applicable, the CP or CP/CPS) MUST clearly specify the procedure(s) 119 | that the CA employs to perform this verification; 120 | 3. for a certificate capable of being used for TLS-enabled servers, the CA 121 | MUST ensure that the applicant has registered all domain(s) referenced 122 | in the certificate or has been authorized by the domain registrant to 123 | act on their behalf. This MUST be done using one or more of the 124 | methods documented in section 3.2.2.4 of the [TLS BRs][TLS-BRs]. The CA operator's 125 | CPS (or, if applicable, the CP or CP/CPS) MUST clearly specify the procedure(s) that the CA employs, and 126 | each documented procedure MUST state which subsection of 3.2.2.4 it is 127 | complying with; 128 | 4. for a certificate capable of being used for TLS-enabled servers, the CA 129 | MUST ensure that the applicant has control over all IP Address(es) referenced 130 | in the certificate. This MUST be done using one or more of the 131 | methods documented in section 3.2.2.5 of the [TLS BRs][TLS-BRs]. The CA operator's 132 | CPS (or, if applicable, the CP or CP/CPS) MUST clearly specify the procedure(s) that the CA employs, and 133 | each documented procedure SHOULD state which subsection of 3.2.2.5 it is 134 | complying with; *and* 135 | 5. for certificates marked as Extended Validation, CA operators MUST comply with the 136 | latest version of the [Guidelines for the Issuance and Management of 137 | Extended Validation Certificates][EVGLs]. 138 | 139 | Validation methods are occasionally found to contain security flaws. When this happens, 140 | Mozilla expects CA operators to evaluate their practices and respond appropriately to mitigate the risk. 141 | Mozilla MAY require CAs to make disclosures or modifications, up to and including 142 | immediately discontinuing use of a method. 143 | 144 | ### 2.3 Baseline Requirements Conformance 145 | 146 | CA operations relating to issuance of certificates capable of being used for 147 | TLS-enabled servers MUST conform to the latest version of the [CA/Browser 148 | Forum's TLS BRs][TLS-BRs]. Certificates issued on or after September 1, 2023, that are capable of being used to digitally sign or encrypt email messages, and CA operations relating to the issuance of such certificates, MUST conform to the latest version of the [S/MIME BRs][SMIME-BRs]. In the event of inconsistency 149 | between this policy's requirements and either the S/MIME BRs or TLS BRs, 150 | this policy's requirements take precedence. The following is a list of known 151 | places where this policy takes precedence over the S/MIME BRs and TLS BRs. If 152 | you find an inconsistency that is not listed here, notify Mozilla so the item 153 | can be considered for addition or clarification. 154 | 155 | * Insofar as the S/MIME BRs or TLS BRs attempt to define their own scope, the 156 | scope of this policy (section 1.1) overrides that. CA 157 | operations relating to issuance of **all** S/MIME or TLS server certificates in the scope of 158 | this policy SHALL conform to the S/MIME BRs or TLS BRs, as applicable. 159 | 160 | * Mozilla MAY accept audits by auditors who do not meet the 161 | qualifications given in section 8.2 of the S/MIME BRs or TLS BRs, or refuse 162 | audits from auditors who do. 163 | 164 | * Mozilla MAY restrict permitted algorithms to a subset of those allowed by the S/MIME BRs or TLS 165 | BRs. 166 | 167 | ### 2.4 Incidents 168 | 169 | When a CA operator fails to comply with any requirement of this policy - whether it be a misissuance, a procedural or operational issue, or any other variety of 170 | non-compliance - the event is classified as an [incident][Incident]. CA operators MUST adhere to the [CCADB's Incident Reporting Guidelines](https://www.ccadb.org/cas/incident-report) (IRGs). CA operators MUST update Incident Reports and respond to questions or comments in accordance with the IRGs until the corresponding [Bugzilla][Bugzilla] bug is closed. 171 | 172 | Mozilla expects the timely remediation of the problems that caused or gave rise to an incident. In response to incidents, Mozilla MAY further require that the CA operator submit a plan of action with milestones or submit one or more additional audits to provide sufficient assurance that the incident has been remediated. Such audits MAY be expected sooner than the CA operator’s next scheduled audit, and thus MAY be expected to be for a period less than a year. 173 | 174 | #### 2.4.1 Vulnerability and Security Incident Reporting 175 | 176 | Additionally, and not in lieu of the requirement to publicly report incidents as outlined above, a CA Operator MUST disclose a serious vulnerability or security incident in [Bugzilla][Bugzilla] as a [secure bug][Sec-Bugs] in accordance with guidance found on the [Vulnerability Disclosure wiki page][Vulnerability-Disclosure]. 177 | 178 | ## 3. Documentation 179 | 180 | ### 3.1 Audits 181 | 182 | Before being included and at least annually thereafter, CA operators MUST obtain certain 183 | audits for their root certificates and all intermediate certificates 184 | that are technically capable of issuing working server or email certificates. 185 | This section describes the requirements for those audits. 186 | 187 | #### 3.1.1 Audit Criteria 188 | 189 | We consider the criteria for CA operations published in the 190 | following documents to be acceptable: 191 | 192 | **WebTrust Program for Certification Authorities** ([WebTrust][WebTrust-For-CAs]) 193 | * WebTrust "[Principles and Criteria for Certification Authorities - Version 194 | 2.2.2][WebTrust-2.2.2]", or later; 195 | * WebTrust "[Principles and Criteria for Certification Authorities – Network Security - Version 1.7][WebTrust-NetSec]", or later; 196 | * WebTrust "[Principles and Criteria for Certification Authorities – SSL 197 | Baseline - Version 2.8][WebTrust-BRs]", or later; 198 | * WebTrust "[Principles and Criteria for Certification Authorities - 199 | Extended Validation SSL - Version 1.8][WebTrust-EV]", or later; 200 | * WebTrust "[Principles and Criteria for Certification Authorities - S/MIME Certificates - Version 1.0.3][WebTrust-SMIME], or later; 201 | 202 | **European Telecommunications Standards Institute** (ETSI) 203 | * "Trust Service Providers practice" in ETSI EN 319 411-1 v1.4.1 or 204 | later version [Policy and security requirements for Trust Service Providers 205 | issuing certificates; Part 1: General requirements][ETSI-319-411-1], 206 | specifying a policy or policies appropriate to the trust bit(s) being 207 | applied for; 208 | * "Trust Service Providers practice" in ETSI EN 319 411-2 v2.5.1 or 209 | later version [Policy and security requirements for Trust Service Providers 210 | issuing certificates; Part 2: Requirements for trust service providers 211 | issuing EU qualified certificates][ETSI-319-411-2], specifying a 212 | policy or policies appropriate to the trust bit(s) being applied for; *and* 213 | * ETSI "[Requirements for Trust Service Providers issuing publicly trusted S/MIME certificates][ETSI-119-411-6]", ETSI TS 119 411-6 v1.1.1 or later version. 214 | 215 | #### 3.1.2 Required Audits 216 | 217 | ##### 3.1.2.1 WebTrust 218 | 219 | If being audited to the WebTrust criteria, the following audit requirements 220 | apply (see section 3.1.1 for specific version numbers): 221 | 222 | * For the websites trust bit, a CA and all intermediate CAs technically capable 223 | of issuing server certificates MUST have all of the following audits: 224 | 225 | * [WebTrust for CAs][WebTrust-2.2.2]; 226 | * [WebTrust for CAs - Network Security][WebTrust-NetSec] 227 | * [WebTrust for CAs - SSL Baseline][WebTrust-BRs]; *and* 228 | * [WebTrust for CAs - EV SSL][WebTrust-EV] if [capable of issuing EV certificates][Capable-of-EV]. 229 | 230 | * For the email trust bit, a CA and all intermediate CAs technically capable 231 | of issuing email certificates MUST have all of the following audits: 232 | 233 | * [WebTrust for CAs][WebTrust-2.2.2]; 234 | and, 235 | * for audit periods ending after October 30, 2023, a period-of-time audit performed in accordance with [WebTrust for CAs - S/MIME][WebTrust-SMIME]. 236 | 237 | 238 | ##### 3.1.2.2 ETSI 239 | 240 | If being audited to the ETSI criteria, the following audit requirements apply 241 | (see section 3.1.1 for version numbers): 242 | 243 | * For the websites trust bit, a CA and all intermediate CAs technically 244 | capable of issuing server certificates MUST have one of the 245 | following audits, with at least one of the noted policies or sets of 246 | policies: 247 | 248 | * [ETSI EN 319 411-1][ETSI-319-411-1] (LCP and (DVCP or OVCP)) and/or (NCP 249 | and EVCP); *or* 250 | * [ETSI EN 319 411-2][ETSI-319-411-2] (QCP-w). 251 | 252 | An audit showing conformance with the EVCP policy is REQUIRED if a CA is [capable of issuing EV certificates][Capable-of-EV]. 253 | 254 | * For the email trust bit, a CA and all intermediate CAs technically 255 | capable of issuing email certificates MUST have the 256 | following audits, with at least one of the noted policies: 257 | 258 | * [ETSI EN 319 411-1][ETSI-319-411-1] (LCP, NCP, or NCP+); *or* 259 | * [ETSI EN 319 411-2][ETSI-319-411-2] (QCP-l, QCP-l-qscd, QCP-n, or 260 | QCP-n-qscd); 261 | and, 262 | * for audit periods ending after October 30, 2023, a period-of-time audit performed in accordance with [ETSI TS 119 411-6][ETSI-119-411-6]. 263 | 264 | #### 3.1.3 Audit Parameters 265 | Full-surveillance period-of-time audits MUST be conducted and updated audit 266 | information provided no less frequently than **annually** from the time of CA key pair generation until the CA public key is no longer trusted by Mozilla's root store. For annual audit periods beginning on or after March 15, 2025, CA private keys that have been generated but not yet associated with a CA certificate ("parked keys") MUST be identified by the SHA-256 hashes of the CA Public Keys. Specifically, the SHA-256 hash MUST be calculated over the DER encoding of the SubjectPublicKeyInfo containing the CA Public Key and included in auditor-provided annual key lifecycle management reports (or a corresponding section or appendix of the CA operator's annual audit reports). These reports must account for the controls and measures applied to ensure the integrity, confidentiality, and protection of these keys throughout their lifecycle, consistent with the audit criteria cited above. These cradle-to-grave audit requirements apply equally to intermediate CAs as they do to root CAs. Successive period-of-time audits and auditor-provided annual key lifecycle management reports MUST be contiguous (no gaps). 267 | 268 | Point-in-time audit statements MAY be used to confirm that all problems 269 | that an auditor previously identified in a qualified audit statement have been 270 | corrected. However, a point-in-time audit does not replace the 271 | period-of-time audit. 272 | 273 | Audit reports that are being supplied to maintain a certificate within the 274 | Mozilla root store MUST be provided to Mozilla via the CCADB within three 275 | months of the point-in-time date or the end date of the period of time. 276 | 277 | #### 3.1.4 Public Audit Information 278 | 279 | The publicly-available documentation relating to each audit MUST contain the information required by section 5.1 of the [CCADB Policy](https://www.ccadb.org/policy) (v.1.3.1) and the [CA locations that were or were not audited][Audited-Location]. Audit reports MUST also contain or be accompanied by the name of the lead auditor and [qualifications of the team][Auditor-Qualifications] performing the audit, as required by section 3.2. 280 | 281 | If Mozilla determines that an audit provided does not meet the requirements of this policy, then Mozilla MAY require that the CA operator obtain a new audit, at the CA operator's expense, for the period of time in question. Additionally, depending on the nature of concerns with the audit, Mozilla MAY require that the CA operator obtain such an audit from a new auditor. 282 | 283 | ### 3.2 Auditors 284 | 285 | In normal circumstances, Mozilla requires that audits MUST be performed 286 | by a Qualified Auditor, as defined in section 8.2 of the S/MIME BRs or TLS BRs. 287 | 288 | A Qualified Auditor MUST have relevant IT Security experience, or have audited a number of CAs, and be independent. ETSI Audit Attestation Letters MUST follow the Audit Attestation Letter template on the [ACAB'c website](https://www.acab-c.com/downloads), and ETSI auditors MUST be members of the [Accredited Conformity Assessment Bodies' Council][ACAB'c] and follow the ACAB'c Charter and Code of Conduct. WebTrust audit statements MUST follow the practitioner guidance, principles, and illustrative assurance reports on the [CPA Canada website](https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/principles-and-criteria), and WebTrust auditors MUST be listed as [enrolled WebTrust practitioners][WebTrust Practitioners] on the CPA Canada website. Mozilla MAY, at its sole discretion, decide to temporarily waive membership or enrollment requirements. 289 | 290 | Each Audit Report MUST be accompanied by documentation provided to Mozilla of the [audit team qualifications][Auditor-Qualifications] sufficient for Mozilla to determine the competence, experience, and independence of the auditor. 291 | 292 | If a CA operator wishes to use auditors who do not fit the definition of Qualified Auditor, then it MUST 293 | receive written permission from Mozilla to do so in advance of the start 294 | of the audit engagement. Mozilla will make its own determination as to 295 | the suitability of the suggested party or parties, at its sole discretion. 296 | 297 | 298 | ### 3.3 CPs and CPSes 299 | 300 | We rely on publicly disclosed documentation (e.g., in a Certificate Policy and 301 | Certification Practice Statement) to ascertain that our requirements are met. 302 | Therefore: 303 | 304 | 1. the publicly disclosed documentation MUST provide sufficient 305 | information for Mozilla to determine whether and how the CA operator 306 | complies with this policy, including a description of the steps 307 | taken by the CA to verify certificate requests; 308 | 309 | 2. the publicly disclosed documentation MUST be available from the CA operator’s official website; 310 | 311 | 3. the documentation MUST be made available to Mozilla under one 312 | of the following Creative Commons licenses (or later versions): 313 | 314 | * Attribution ([CC-BY]) 4.0; 315 | * Attribution-ShareAlike ([CC-BY-SA]) 4.0; 316 | * Attribution-NoDerivs ([CC-BY-ND]) 4.0; *or* 317 | * Public Domain Dedication ([CC-0]) 1.0; 318 | 319 | or a set of equally permissive licensing terms accepted by Mozilla in 320 | writing. If no such license is indicated, the fact of application is 321 | considered as permission from the CA operator to allow Mozilla and the public to 322 | deal with these documents, and any later versions for root certificates 323 | that are included in Mozilla's root store, under CC-BY-ND 4.0; 324 | 325 | 4. all CPs, CPSes, and combined CP/CPSes MUST be reviewed and updated as necessary at least once every 365 days, as required by the S/MIME BRs or TLS BRs. CA operators MUST indicate that this has 326 | happened by incrementing the version number and adding a dated changelog entry, 327 | even if no other changes are made to the document; 328 | 329 | 5. all CPs, CPSes, and combined CP/CPSes MUST be structured according to the common outline set forth in [section 6 of RFC 3647][3647-6], as may be amended by the CA/Browser Forum's TLS BRs or its S/MIME BRs, and MUST: 330 | 331 | * include at least every section and subsection defined in [section 6 of RFC 3647][3647-6]; 332 | * only use the words "No Stipulation" to mean that the particular document 333 | imposes no requirements related to that section; and 334 | * contain no sections that are entirely blank, having no text or subsections; 335 | 336 | 6. CA operators MUST provide a way to clearly determine which CP, CPS, or combined CP/CPS 337 | applies to each of its root and intermediate certificates; *and* 338 | 339 | 7. CA operators SHALL maintain links to all historic versions of each CP and CPS (or CP/CPS) from the creation of included CA certificates, regardless of changes in ownership or control of such CA certificates, until the entire CA certificate hierarchies (i.e. end entity certificates, intermediate CA certificates, and cross-certificates) operated in accordance with such documents are no longer trusted by the Mozilla root store. For CA certificates that were included in Mozilla's root store before December 31, 2022, the CA Operator shall maintain links in their online repositories to all reasonably available historic versions of CPs and CPSes (or CP/CPSes) from creation of the included CA certificates. 340 | 341 | ### 3.4 Compliance Self-Assessments 342 | 343 | CA operators with CA certificates capable of issuing working TLS server certificates MUST perform a [Compliance Self-Assessment](https://www.ccadb.org/cas/self-assessment) annually. The annual self-assessment MUST be completed and submitted to the CCADB within 92 calendar days from the CA operator's earliest appearing root record “BR Audit Period End Date” that is after December 31, 2023. CA operators SHOULD submit the self-assessment at the same time as uploading audit reports in a [CCADB Case](https://www.ccadb.org/cas/updates). CA operators SHOULD use the latest available version of the [Compliance Self-Assessment](https://www.ccadb.org/cas/self-assessment) template, and MUST NOT use a version of the self-assessment template that has been superseded by more than 90 calendar days before submission. 344 | 345 | ## 4. Common CA Database 346 | 347 | Mozilla manages its root store using the Common CA Database (CCADB). CA operators with 348 | certificates in Mozilla’s root store MUST use the CCADB, and are bound by the 349 | latest published version of the [CCADB Policy][CCADB-Policy]. 350 | 351 | Mozilla has requirements for the use of the CCADB above and beyond those in the 352 | CCADB Policy, as indicated below in this section 4. 353 | 354 | ### 4.1 Additional Requirements 355 | 356 | * CA operators with intermediate CA certificates that are capable of issuing TLS certificates chaining up to root certificates in Mozilla's root store SHALL populate the "Pertaining to Certificates Issued by This CA" section of the CCADB records corresponding to those intermediate CA certificates with either the CRL Distribution Point for the "Full CRL Issued By This CA" or a "JSON Array of Partitioned CRLs" within 7 days of such intermediate CA issuing its first certificate; 357 | * Each CRL referenced by the JSON Array of Partitioned CRLs MUST contain a critical Issuing Distribution Point extension as described in section 6.1.2; *and* 358 | * if the revocation of an intermediate certificate chaining up to a root in 359 | Mozilla’s root store is due to a security concern, as well as performing the 360 | actions defined in the CCADB Policy, a [Vulnerability Disclosure][Vulnerability-Disclosure] MUST be filed as [a secure bug in Bugzilla][Sec-Bugs]. 361 | 362 | ### 4.2 Surveys 363 | 364 | Mozilla MAY conduct a survey of CA operators from time to time. CA operators are 365 | REQUIRED to respond to the surveys with accurate information, within the 366 | timescale defined in the survey. 367 | 368 | ## 5. Certificates 369 | 370 | ### 5.1 Algorithms 371 | 372 | Root certificates in our root store, and any certificate that 373 | chains up to them, MUST use only algorithms and key sizes from the following 374 | set: 375 | 376 | * RSA keys whose modulus size in bits is divisible by 8, and is at 377 | least 2048 bits; *or* 378 | * ECDSA keys using one of the following curves: 379 | * P-256; 380 | * P-384; *or* 381 | * P-521. 382 | 383 | The following curves are not prohibited, but are not currently supported: Curve25519 and Curve448. 384 | 385 | EdDSA keys MAY be included in certificates that chain to a root certificate in our root store if the certificate contains ‘id-kp-emailProtection` in the EKU extension. Otherwise, EdDSA keys MUST NOT be included. 386 | 387 | The following sections detail encoding and signature algorithm requirements for 388 | each of these keys. The encoding requirements on signature algorithms apply to 389 | any contexts where the algorithm is encoded as an AlgorithmIdentifier, 390 | including: 391 | 392 | * The signatureAlgorithm field of a Certificate; 393 | * The signature field of a TBSCertificate; 394 | * The signatureAlgorithm field of a CertificateList; 395 | * The signature field of a TBSCertList; *and* 396 | * The signatureAlgorithm field of a BasicOCSPResponse. 397 | 398 | 399 | #### 5.1.1 RSA 400 | 401 | When RSA keys are encoded in a SubjectPublicKeyInfo structure, the algorithm 402 | field MUST consist of an rsaEncryption OID (1.2.840.113549.1.1.1) with a NULL 403 | parameter, as specified by [RFC 8017, Appendix A.1](https://datatracker.ietf.org/doc/html/rfc8017#appendix-A.1) 404 | and [RFC 3279, Section 2.3.1](https://datatracker.ietf.org/doc/html/rfc3279#section-2.3.1). 405 | The encoded AlgorithmIdentifier for an RSA key MUST match the 406 | following hex-encoded bytes: 407 | `300d06092a864886f70d0101010500`. 408 | 409 | CAs MUST NOT use the id-RSASSA-PSS OID (1.2.840.113549.1.1.10) within a 410 | SubjectPublicKeyInfo to represent an RSA key. 411 | 412 | When a root or intermediate certificate's RSA key is used to produce a 413 | signature, only the following algorithms MAY be used, and with the following 414 | encoding requirements: 415 | 416 | * RSASSA-PKCS1-v1_5 with SHA-1. 417 | 418 | The encoded AlgorithmIdentifier MUST match the following hex-encoded bytes: 419 | `300d06092a864886f70d0101050500`. 420 | 421 | *See section 5.1.3 for further restrictions on the use of SHA-1.* 422 | 423 | * RSASSA-PKCS1-v1_5 with SHA-256. 424 | 425 | The encoded AlgorithmIdentifier MUST match the following hex-encoded bytes: 426 | `300d06092a864886f70d01010b0500`. 427 | 428 | * RSASSA-PKCS1-v1_5 with SHA-384. 429 | 430 | The encoded AlgorithmIdentifier MUST match the following hex-encoded bytes: 431 | `300d06092a864886f70d01010c0500`. 432 | 433 | * RSASSA-PKCS1-v1_5 with SHA-512. 434 | 435 | The encoded AlgorithmIdentifier MUST match the following hex-encoded bytes: 436 | `300d06092a864886f70d01010d0500`. 437 | 438 | * RSASSA-PSS with SHA-256, MGF-1 with SHA-256, and a salt length of 32 bytes. 439 | 440 | The encoded AlgorithmIdentifier MUST match the following hex-encoded bytes: 441 | 442 | ``` 443 | 304106092a864886f70d01010a3034a00f300d0609608648016503040201 444 | 0500a11c301a06092a864886f70d010108300d0609608648016503040201 445 | 0500a203020120 446 | ``` 447 | 448 | * RSASSA-PSS with SHA-384, MGF-1 with SHA-384, and a salt length of 48 bytes. 449 | 450 | The encoded AlgorithmIdentifier MUST match the following hex-encoded bytes: 451 | 452 | ``` 453 | 304106092a864886f70d01010a3034a00f300d0609608648016503040202 454 | 0500a11c301a06092a864886f70d010108300d0609608648016503040202 455 | 0500a203020130 456 | ``` 457 | 458 | * RSASSA-PSS with SHA-512, MGF-1 with SHA-512, and a salt length of 64 bytes. 459 | 460 | The encoded AlgorithmIdentifier MUST match the following hex-encoded bytes: 461 | 462 | ``` 463 | 304106092a864886f70d01010a3034a00f300d0609608648016503040203 464 | 0500a11c301a06092a864886f70d010108300d0609608648016503040203 465 | 0500a203020140 466 | ``` 467 | 468 | The above RSASSA-PKCS1-v1_5 encodings consist of the corresponding OID, 469 | e.g. sha256WithRSAEncryption (1.2.840.113549.1.1.11), with an explicit NULL 470 | parameter, as specified in [RFC 3279, Section 2.2.1](https://datatracker.ietf.org/doc/html/rfc3279#section-2.2.1). 471 | Certificates MUST NOT omit this NULL parameter. Note this differs 472 | from ECDSA, which omits the parameter. 473 | 474 | The above RSASSA-PSS encodings consist of the RSASSA-PSS OID 475 | (1.2.840.11.3549.1.1.10) with a corresponding RSASSA-PSS-params structure as 476 | parameter. The trailerField MUST be omitted, as it is unchanged from the default 477 | value. The AlgorithmIdentifier structures describing the hash functions in the 478 | hashAlgorithm field and in the maskGenAlgorithm's parameter MUST themselves 479 | include an explicit NULL in the parameter field, as specified by [RFC 4055, Section 6](https://datatracker.ietf.org/doc/html/rfc4055#section-6). 480 | 481 | Note: as of Firefox version 100, [RSASSA-PSS encodings are supported](https://bugzilla.mozilla.org/show_bug.cgi?id=1088140). 482 | 483 | #### 5.1.2 ECDSA 484 | 485 | When ECDSA keys are encoded in a SubjectPublicKeyInfo structure, the algorithm 486 | field MUST be one of the following, as specified by [RFC 5480, Section 2.1.1](https://datatracker.ietf.org/doc/html/rfc5480#section-2.1.1): 487 | 488 | * the encoded AlgorithmIdentifier for a P-256 key MUST match the following 489 | hex-encoded bytes: `301306072a8648ce3d020106082a8648ce3d030107`; 490 | * the encoded AlgorithmIdentifier for a P-384 key MUST match the following 491 | hex-encoded bytes: `301006072a8648ce3d020106052b81040022`; *or* 492 | * the encoded AlgorithmIdentifier for a P-521 key MUST match the following 493 | hex-encoded bytes: `301006072a8648ce3d020106052b81040023`. 494 | 495 | The above encodings consist of an ecPublicKey OID (1.2.840.10045.2.1) with a 496 | named curve parameter of the corresponding curve OID. Certificates MUST NOT use 497 | the implicit or specified curve forms. 498 | 499 | When a root or intermediate certificate's ECDSA key is used to produce a 500 | signature, only the following algorithms MAY be used, and with the following 501 | encoding requirements: 502 | 503 | * If the signing key is P-256, the signature MUST use ECDSA with SHA-256. The 504 | encoded AlgorithmIdentifier MUST match the following hex-encoded bytes: 505 | `300a06082a8648ce3d040302`. 506 | 507 | * If the signing key is P-384, the signature MUST use ECDSA with SHA-384. The 508 | encoded AlgorithmIdentifier MUST match the following hex-encoded bytes: 509 | `300a06082a8648ce3d040303`. 510 | 511 | * If the signing key is P-521, the signature MUST use ECDSA with SHA-512. When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the following hex-encoded bytes: 512 | `300a06082a8648ce3d040304`. 513 | 514 | The above encodings consist of the corresponding OID with the parameters field 515 | omitted, as specified by [RFC 5758, Section 3.2](https://datatracker.ietf.org/doc/html/rfc5758#section-3.2). 516 | Certificates MUST NOT include a NULL parameter. Note this differs from 517 | RSASSA-PKCS1-v1_5, which includes an explicit NULL. 518 | 519 | #### 5.1.3 SHA-1 520 | 521 | Effective July 1, 2022, CAs SHALL NOT sign SHA-1 hashes over end entity certificates with an EKU extension containing the id-kp-emailProtection key purpose. 522 | 523 | Effective July 1, 2023, CAs SHALL NOT sign SHA-1 hashes over: 524 | * certificates with an EKU extension containing the id-kp-ocspSigning key purpose; 525 | * intermediate certificates that chain up to roots in Mozilla's program; 526 | * OCSP responses; *or* 527 | * CRLs. 528 | 529 | CAs MAY sign SHA-1 hashes over end entity certificates that chain 530 | up to roots in Mozilla's program only if all the following are true: 531 | 532 | 1. the end entity certificate: 533 | 534 | * is not within the scope of the S/MIME BRs or TLS BRs; 535 | * contains an EKU extension that does not contain the 536 | id-kp-serverAuth, id-kp-emailProtection, or anyExtendedKeyUsage key purposes; *and* 537 | * has at least 64 bits of entropy from a CSPRNG in the serial number; *and* 538 | 539 | 2. the issuing certificate: 540 | 541 | * contains an EKU extension that does not contain the 542 | id-kp-serverAuth, id-kp-emailProtection, or anyExtendedKeyUsage key purposes; *and* 543 | * has a pathlen:0 constraint. 544 | 545 | CAs MAY sign SHA-1 hashes over intermediate certificates that 546 | chain up to roots in Mozilla's root store only if the certificate to be signed 547 | is a duplicate of an existing SHA-1 intermediate certificate with the 548 | only changes being all of: 549 | 550 | * a new key (of the same size); 551 | * a new serial number (of the same length); *and/or* 552 | * the addition of an EKU and/or a pathlen constraint to meet the 553 | requirements outlined above. 554 | 555 | CAs MUST NOT sign SHA-1 hashes over other data, including CT pre-certificates. 556 | 557 | ### 5.2 Forbidden and Required Practices 558 | 559 | CA operations MUST at all times be in accordance with the applicable CP 560 | and CPS (or combined CP/CPS). 561 | 562 | CA operators MUST maintain a certificate hierarchy such that an included 563 | root certificate does not directly issue end entity certificates to 564 | customers (i.e. a root certificate signs intermediate 565 | issuing certificates), as described in section 6.1.7 of the [TLS 566 | BRs][TLS-BRs] and the [S/MIME BRs][SMIME-BRs]. 567 | 568 | CA operators MUST maintain current best practices to prevent 569 | algorithm attacks against certificates. As such, all new certificates 570 | MUST have a serial number greater than zero, containing at least 64 bits of 571 | output from a CSPRNG. 572 | 573 | CA operators MUST NOT issue certificates, CRLs, or OCSP responses, that have: 574 | 575 | * ASN.1 DER encoding errors; 576 | * invalid public keys (e.g., RSA certificates with public exponent 577 | equal to 1); *or* 578 | * missing or incorrect extensions (e.g., TLS certificates with no subjectAltName extension, delegated OCSP responders without the id-pkix-ocsp-nocheck extension, partial/scoped CRLs that lack a distributionPoint in a critical issuingDistributionPoint extension). 579 | 580 | CA operators MUST NOT issue certificates that have: 581 | 582 | * duplicate issuer names and serial numbers (except that a Certificate 583 | Transparency pre-certificate is allowed to match the corresponding 584 | certificate); *or* 585 | * cRLDistributionPoints or OCSP authorityInfoAccess extensions for 586 | which no operational CRL or OCSP service exists. 587 | 588 | CA operators MUST NOT generate the key pairs for end entity certificates that have an 589 | EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage, unless the certificate is being issued to the CA itself. 590 | 591 | All end entity certificates MUST include an EKU extension containing KeyPurposeId(s) 592 | describing the intended usage(s) of the certificate, and the EKU extension MUST NOT 593 | contain the KeyPurposeId anyExtendedKeyUsage. 594 | 595 | ### 5.3 Intermediate Certificates 596 | 597 | All certificates that are capable of being used to issue new certificates and that directly or transitively chain to a CA certificate included in Mozilla’s root store MUST be operated in accordance with this policy. 598 | 599 | A certificate is deemed capable of being used to issue new 600 | certificates if it contains an [X.509v3 basicConstraints extension][5280-6.1.4] 601 | with the cA boolean set to true. 602 | 603 | A certificate is deemed to directly or transitively chain to a CA certificate included in Mozilla's root store if: 604 | (1) the certificate's Issuer Distinguished Name matches (according to the name-matching algorithm specified in RFC 5280, section 7.1) the Subject Distinguished Name in a CA certificate or intermediate certificate that is in scope according to section 1.1 of this Policy, *and* 605 | (2) the certificate is signed with a Private Key whose corresponding Public Key is encoded in the SubjectPublicKeyInfo of that CA certificate or intermediate certificate. 606 | 607 | Intermediate certificates created after January 1, 2019, with the exception of cross-certificates that share a private key with a corresponding root certificate: 608 | 609 | * MUST contain an EKU extension; 610 | * MUST NOT include the anyExtendedKeyUsage KeyPurposeId; *and* 611 | * MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same certificate. 612 | 613 | #### 5.3.1 Technically Constrained 614 | 615 | We encourage CA operators to technically constrain all intermediate 616 | certificates. For an intermediate certificate to be considered technically 617 | constrained, the certificate MUST include an [Extended Key Usage 618 | (EKU)][5280-4.2.1.12] extension specifying the extended key usage(s) allowed for the type of end entity certificates that the 619 | intermediate CA is authorized to issue. We also encourage CA operators to include only a single KeyPurposeID in the EKU extension of intermediate certificates. The anyExtendedKeyUsage 620 | KeyPurposeId MUST NOT appear within this extension. 621 | 622 | The conformance requirements defined in section 2.3 of this policy also apply to 623 | technically constrained intermediate certificates. 624 | 625 | If the intermediate CA certificate includes the id-kp-serverAuth extended key usage, 626 | then to be considered technically constrained, the certificate MUST be name-constrained as described in section 627 | 7.1.2.5 of the [TLS BRs][TLS-BRs], each entry in permittedSubtrees having been validated according to section 628 | 3.2.2 of the TLS BRs. The id-kp-clientAuth EKU MAY also be present. 629 | 630 | If the intermediate CA certificate includes the id-kp-emailProtection extended key 631 | usage, then to be considered technically 632 | constrained, it MUST comply with section 7.1.5 of the [S/MIME BRs][SMIME-BRs] and include the Name Constraints X.509v3 extension with 633 | constraints on rfc822Name, with at least one name in permittedSubtrees, 634 | each name having been validated according to section 635 | 3.2.2 of the [S/MIME BRs][SMIME-BRs]. The values id-kp-serverAuth and anyExtendedKeyUsage MUST NOT be present. The id-kp-clientAuth EKU MAY be present. Other values that the CA is allowed to use and are documented in the CA’s CP, CPS, or combined CP/CPS MAY be present. 636 | 637 | #### 5.3.2 Publicly Disclosed and Audited 638 | 639 | The operator of a CA certificate included in Mozilla’s root store MUST publicly disclose in the CCADB all CA certificates it issues that chain up to that CA certificate trusted in Mozilla’s root store that are technically capable of issuing working server or email certificates, including such CA certificates that are revoked but not yet expired and those CA certificates that share the same key pair whether they are self-signed, doppelgänger, reissued, cross-signed, or other roots. The CA operator with a certificate included in Mozilla’s root store MUST disclose such CA certificate in the CCADB within one week of certificate creation, and before any such CA is allowed to issue certificates. Name-constrained CA certificates that are technically capable of issuing working server or email certificates that were exempt from disclosure in previous versions of this policy MUST also be disclosed in the CCADB, but the submission of an audit report under section 3.1 of this policy is not required. 640 | 641 | All disclosure MUST be made freely available and without additional requirements, including, but not limited to, registration, legal agreements, or restrictions on redistribution of the certificates in whole or in part. 642 | 643 | We recognize that technically constraining intermediate 644 | certificates as described above may not be practical in some cases. 645 | All certificates that are capable of being used to issue new 646 | certificates, that are not technically constrained, and that 647 | directly or transitively chain to a certificate included in 648 | Mozilla’s root store MUST be audited in accordance with this policy, and the corresponding audit statements MUST be disclosed in the CCADB according to [section 5 of the CCADB Policy](https://www.ccadb.org/policy#5-policies-audits-and-practices). 649 | If the CA operator has a currently valid audit report at the time of creation 650 | of the intermediate certificate, then the new intermediate certificate MUST appear on the 651 | CA operator's next periodic audit reports. 652 | 653 | ### 5.4 Precertificates 654 | The logging of a precertificate in a Certificate Transparency log is considered by Mozilla to be a binding intent to issue a final certificate, as described in [section 3.1 of RFC 6962][6962-3.1]. "Final certificate" means a certificate that is not a precertificate. Precertificates are in-scope for enforcing compliance with these requirements. A final certificate is "based on" a precertificate if they have the same serial and issuer, or they have the same serial and the final certificate's issuer matches the precertificate's issuer's issuer. Thus, 655 | * it is mississuance to issue a final certificate based on a precertificate if they do not exactly match each other according to RFC 6962, section 3.1; 656 | * if a precertificate implies the existence of a final certificate that does not comply with this policy, it is considered misissuance of the final certificate, even if the certificate does not actually exist; 657 | * a CA MUST be able to revoke a certificate presumed to exist, if revocation of the certificate is required under this policy, even if the final certificate does not actually exist; *and* 658 | * a CA MUST provide CRL and OCSP services and responses in accordance with this policy for all certificates presumed to exist based on the presence of a precertificate, even if the certificate does not actually exist. 659 | 660 | ## 6. Revocation 661 | 662 | CA operators MUST maintain an online 24x7 repository mechanism whereby 663 | application software can automatically check online the current 664 | status of all unexpired certificates issued by the CA. 665 | 666 | For end entity certificates, CRLs MUST be updated and reissued at least 667 | every seven days, and the value of the nextUpdate field MUST NOT be 668 | more than ten days beyond the value of the thisUpdate field. 669 | 670 | For end entity certificates, if the CA provides revocation information 671 | via an Online Certificate Status Protocol (OCSP) service: 672 | 673 | * it MUST update that service at least every four days; 674 | * responses MUST have a defined value in the nextUpdate field, and it 675 | MUST be no more than ten days after the thisUpdate field; *and* 676 | * the value in the nextUpdate field MUST be before or equal to the 677 | notAfter date of all certificates included within the 678 | BasicOCSPResponse.certs field or, if the certs field is omitted, 679 | before or equal to the notAfter date of the CA certificate which 680 | issued the certificate that the BasicOCSPResponse is for. 681 | 682 | Section 4.9.12 of a CA operator's CPS (or, if applicable, the CP or CP/CPS) MUST clearly specify the methods that parties may use to demonstrate private key compromise. 683 | 684 | ### 6.1 TLS 685 | 686 | For any certificate in a hierarchy capable of being used for 687 | TLS-enabled servers, CAs MUST revoke certificates that they have 688 | issued upon the occurrence of any event listed in the appropriate 689 | subsection of section 4.9.1 of the [TLS BRs][TLS-BRs], 690 | according to the timeline defined therein. CAs MUST also revoke 691 | any certificates issued in violation of the then-current version 692 | of this policy according to the timeline defined in 693 | section 4.9.1 of the TLS BRs. 694 | 695 | #### 6.1.1 End Entity TLS Certificate CRLRevocation Reasons #### 696 | 697 | When an end entity TLS certificate (i.e. a certificate capable of being used for TLS-enabled servers) is revoked for one of the reasons below, the specified CRLReason MUST be included in the reasonCode extension of the CRL entry corresponding to the end entity TLS certificate, as described in sections 4.9.1 and 7.2.2 of the [TLS BRs][TLS-BRs]. 698 | 699 | * keyCompromise (RFC 5280 CRLReason #1); 700 | * privilegeWithdrawn (RFC 5280 CRLReason #9); 701 | * cessationOfOperation (RFC 5280 CRLReason #5); 702 | * affiliationChanged (RFC 5280 CRLReason #3); *or* 703 | * superseded (RFC 5280 CRLReason #4). 704 | 705 | The keyCompromise, superseded, and privilegeWithdrawn CRLReasons MUST only be used for the situations listed in the TLS BRs as corresponding to these revocation reasons. Otherwise, the keyCompromise, superseded, and privilegeWithdrawn CRLReasons MUST NOT be used. 706 | 707 | Mozilla’s wiki page, ["Revocation Reasons"](https://wiki.mozilla.org/CA/Revocation_Reasons), provides further details about when the CRLReasons listed above must and must not be used. 708 | 709 | #### 6.1.2 TLS Certificate CRL Issuing Distribution Points 710 | 711 | A CRL whose scope does not include all unexpired certificates that are issued by the CA SHALL contain a critical Issuing Distribution Point extension (OID 2.5.29.28). The distributionPoint field of the extension SHALL include a UniformResourceIdentifier whose value is derived from one of the two following sources: 712 | 713 | 1. The UniformResourceIdentifier as encoded in the distributionPoint field of an issued certificate's CRL Distribution Points extension (see RFC 5280 section 5.2.5); or 714 | 2. The URL as included in the "JSON Array of Partitioned CRLs" field in the CCADB entry corresponding to the certificate for the issuing CA. 715 | 716 | #### 6.1.3 Delayed Revocation 717 | 718 | Mozilla’s goal is to ensure that revocation occurs as swiftly as possible while maintaining the overall security and stability of the web. 719 | Mozilla does not grant exceptions to the revocation requirements of the TLS BRs. 720 | 721 | **Beginning September 1, 2025, each CA operator MUST:** 722 | * engage in proactive communication and advise subscribers well in advance about the revocation timelines and explicitly warn them against using publicly-trusted TLS server certificates on systems that cannot tolerate timely revocation; 723 | * include appropriate language in customer agreements requiring subscribers’ timely cooperation in meeting revocation timelines and acknowledging the CA’s obligations to adhere to applicable policies and standards; and 724 | * prepare and maintain comprehensive and actionable plans to address mass revocation events, including detailed procedures for handling mass revocations effectively, including rapid communication with affected parties and conducting annual plan testing through tabletop exercises, simulations, parallel testing, or use of test environments, which do not involve the revocation of active certificates. 725 | 726 | **Assessment Requirement** 727 | 728 | Beginning with the CA operator’s next annual audit cycle starting on or after June 1, 2025, each CA operator MUST engage a third-party assessor to evaluate whether the CA operator has: 729 | * well-documented and actionable plans to handle mass revocation events; 730 | * demonstrated the implementation and feasibility of the plans through testing exercises, including documentation of testing processes, timelines, results, and remediation steps; and 731 | * incorporated feedback from such testing exercises and other evaluations to enhance readiness and improve future performance. 732 | 733 | The above-referenced June 1, 2025, date is to ensure that compliance with the September 1, 2025, requirements will be evaluated within a reasonable timeframe while allowing CA operators to incorporate mass revocation testing into their CA processes and annual audit cycles. However, the assessment does not have to be conducted as part of the CA operator’s ETSI or WebTrust audit unless the CA operator finds it more convenient to include it within that scope. The assessment may be conducted separately by a qualified third-party assessor, provided it meets the stated evaluation criteria. 734 | 735 | The [CCADB's Incident Reporting Guidelines](https://www.ccadb.org/cas/incident-report) have reporting requirements that MUST be followed by CA operators who determine they might delay revocation of certificates beyond the time period required by the TLS BRs. For instance, the Analysis field in the Impact section of such incident reports MUST explain "the factors and rationales behind the decision to delay revocation (including detailed and substantiated explanations of how extensive harm would result to third parties–such as essential public services or widely relied-upon systems–and why the situation is exceptionally rare and unavoidable)." All delayed revocation incidents MUST be listed as findings in the CA operator’s next TLS BR audit statement. Repeated incidents of delayed revocation without sufficient justification will result in heightened scrutiny and sanctions, which may include removal of the CA from the Mozilla Root Store. 736 | 737 | ### 6.2 S/MIME 738 | 739 | For any certificate in a hierarchy capable of being used for S/MIME, CAs MUST revoke certificates that they have issued upon the occurrence of any event listed in the appropriate subsection of section 4.9.1 of the [S/MIME BRs][SMIME-BRs], according to the timeline defined therein. CAs MUST also revoke any certificates issued in violation of the then-current version of this policy according to the timeline defined in section 4.9.1 of the S/MIME BRs. 740 | 741 | ## 7. Root Store Changes 742 | 743 | Changes that are motivated by a security concern, such as a root or intermediate CA compromise, MUST be treated as 744 | security-sensitive, and a [Vulnerability Disclosure][Vulnerability-Disclosure] MUST be filed as a secure bug in [Bugzilla][Sec-Bugs]. 745 | 746 | ### 7.1 Inclusions 747 | 748 | We will determine which CA certificates are included in Mozilla's root store 749 | based on the [risks of such inclusion to typical users of our products](https://wiki.mozilla.org/CA/Root_Inclusion_Considerations). We will consider adding 750 | additional CA certificates to the default certificate set upon request only by 751 | an authorized representative of the subject CA. We will make such decisions 752 | through a [public process](https://wiki.mozilla.org/CA/Application_Process). 753 | 754 | We will not charge any fees to have a CA operator’s certificate(s) 755 | included in Mozilla's root store. 756 | 757 | We reserve the right to not include certificates from a particular CA operator in 758 | our root store. This includes (but is not limited to) cases 759 | where we believe that a CA operator has caused undue risks to users’ 760 | security, e.g. by knowingly issuing certificates without the knowledge of the 761 | entities whose information is referenced in those certificates ('MITM certificates'). 762 | Mozilla is under no obligation to explain the reasoning behind any inclusion decision. 763 | 764 | Before being included, CA operators MUST provide evidence that their CA key pairs and CA certificates fully comply with the current Mozilla Root Store Requirements and the S/MIME BRs or TLS BRs, and have continually, from the time of CA private key creation (see section 3.1.3), complied with the then-current Mozilla Root Store Policy and the S/MIME BRs or TLS BRs, as applicable. 765 | 766 | Additionally, CA operators applying for inclusion of new root certificates with the websites trust bit enabled MUST demonstrate support for at least one automated method of certificate issuance for each type of TLS certificate (EV, OV, DV, IV) intended to be issued under the root certificate being requested for inclusion. This means (1) automated domain control validation, as defined in the TLS BRs; and (2) automated certificate issuance and retrieval processes. Such automated methods MUST minimize hands-on human input during routine certificate issuance and renewal processes and comply with the TLS BRs, and EV Guidelines, if applicable. Acceptable "hands-on" input includes initial software setup, configuration, updates, and identity verification where required. CA operators MUST renew test certificates using such capability at least every 30 days to demonstrate compliance with these automation requirements. The test certificates MUST be served by publicly accessible websites, and the URL for each test site MUST be disclosed in the CCADB. 767 | 768 | To request that its certificate(s) be added to Mozilla's root store, a CA operator 769 | SHOULD submit a formal request by submitting a [bug report][CA-Cert-Bug] 770 | into [Bugzilla][Bugzilla], filed against the "CA 771 | Certificate Root Program" component of the "CA Program" product. Mozilla’s wiki 772 | page, "[Applying for root inclusion in Mozilla products][How-To-Apply]", provides 773 | further details about how to submit a formal request. The request 774 | MUST be made by an authorized representative of the subject CA operator, and 775 | MUST include the following: 776 | 777 | 1. the certificate data (or links to the data) for the CA 778 | certificate(s) requested for inclusion; 779 | 2. for each CA certificate requested for inclusion, whether or not 780 | the CA issues certificates for each of the following purposes 781 | within the certificate hierarchy associated with the CA 782 | certificate: 783 | * TLS-enabled servers 784 | * digitally-signed and/or encrypted email; 785 | 3. for each CA certificate requested for inclusion, whether the CA 786 | issues Extended Validation certificates within the certificate hierarchy 787 | associated with the CA certificate and, if so, the CA/Browser Forum EV policy 788 | OID of 2.23.140.1.1 associated with the CA certificate; 789 | 4. links to the CP and CPS (or combined CP/CPS) for the CA or CAs in question; 790 | 5. an auditor-witnessed root key generation ceremony report and contiguous 791 | period-of-time audit reports performed thereafter no less frequently than 792 | annually; 793 | 6. evidence of automated certificate issuance support, as specified above (if seeking enablement of the websites trust bit); 794 | *and* 795 | 7. information as to how the CA operator has fulfilled the requirements 796 | stated above regarding its verification of certificate signing 797 | requests and its conformance to a set of acceptable operational 798 | criteria. 799 | 800 | We will reject requests where the CA operator does not provide such 801 | information within a reasonable period of time after submitting its 802 | request. 803 | 804 | ### 7.2 Updates 805 | 806 | Changes MAY be made to CA certificates that are included in 807 | Mozilla's root store as follows: 808 | 809 | 1. enabling a trust bit in a CA certificate that is currently 810 | included, MAY only be done after careful consideration of the 811 | CA operator’s current policies, practices, and audits, 812 | and MAY be requested by a representative of the CA or a 813 | representative of Mozilla by submitting a bug report into [Bugzilla][Bugzilla], as described in Mozilla’s wiki 814 | page, "[Applying for root inclusion in Mozilla products][How-To-Apply]"; 815 | 2. enabling EV in a CA certificate that is currently included, 816 | MAY only be done after careful consideration of the CA operator’s current 817 | policies, practices, and audits, 818 | and MAY be requested by a representative of the CA operator or a 819 | representative of Mozilla by submitting a bug report into [Bugzilla][Bugzilla], as described in Mozilla’s wiki 820 | page, "[Applying for root inclusion in Mozilla products][How-To-Apply]"; 821 | 3. disabling a CA certificate is the act of turning off one or more of the 822 | trust bits (websites or email), and MAY be 823 | requested by a representative of the CA operator or a representative of 824 | Mozilla by submitting a bug report into [Bugzilla][Bugzilla], as described in the [Root Change Process][Root-Changes]; *and* 825 | 4. a representative of the CA operator or a representative of Mozilla MAY 826 | request that a CA certificate be removed by submitting a bug 827 | report into [Bugzilla][Bugzilla], as described in the 828 | [Root Change Process][Root-Changes]. 829 | 830 | ### 7.3 Removals 831 | 832 | Mozilla MAY, at its sole discretion, decide to disable (partially or fully), or 833 | remove a certificate, at any time and for any reason. This MAY happen 834 | immediately or on a planned future date. Mozilla will 835 | disable or remove a certificate if the CA operator demonstrates ongoing or 836 | egregious practices that do not maintain the expected level of service 837 | or that do not comply with the requirements of this policy. 838 | 839 | Mozilla will take any steps we deem appropriate to protect our users 840 | if we learn that a CA operator has knowingly or intentionally mis-issued one 841 | or more certificates. This MAY include, but is not limited to, 842 | disablement (partially or fully) or removal of all the CA operator’s 843 | certificates from Mozilla’s root store. 844 | 845 | The category of mis-issued certificates includes (but is not limited to) those 846 | issued to someone who should not have received them, those containing 847 | information which was not properly validated, those having incorrect technical 848 | constraints, and those using algorithms other than those permitted. 849 | 850 | A failure to provide notifications or updates in the CCADB or 851 | as otherwise required in a timely manner SHALL also be grounds for 852 | disabling a CA operator’s root certificates or removing them from Mozilla's root 853 | store. For this policy and the CCADB policies, "a timely manner" means 854 | within 30 days of when the appropriate data or documentation becomes 855 | available to the CA operator, unless a Mozilla policy document specifies a different 856 | rule. 857 | 858 | If Mozilla disables or removes a CA operator’s certificate(s) from Mozilla’s 859 | root store based on a CA operator’s actions (or failure to act) that are 860 | contrary to this policy, Mozilla will publicize 861 | that fact (for example, on the [Mozilla dev-security-policy list][MDSP], and on our websites) and MAY also alert 862 | relevant news, government, or industry organizations. 863 | 864 | ### 7.4 Root CA Lifecycles 865 | 866 | For a root CA certificate trusted for server authentication, Mozilla will remove the websites trust bit when the CA key material is more than 15 years from the CA key material generation date. For a root CA certificate trusted for secure email, Mozilla will set the "Distrust for S/MIME After Date" for the CA certificate to 18 years from the CA key material generation date. The CA key material generation date SHALL be determined by reference to the auditor-witnessed key generation ceremony report. If the CA operator cannot provide the key generation ceremony report for a root CA certificate created before July 1, 2012, then Mozilla will use the “Valid From” date in the root CA certificate to establish the key material generation date. For transition purposes, root CA certificates in the Mozilla root store will be distrusted according to the schedule located at https://wiki.mozilla.org/CA/Root_CA_Lifecycles, which is subject to change if underlying algorithms become more susceptible to cryptanalytic attack or if other circumstances arise that make this schedule obsolete. 867 | 868 | CA operators are strongly urged to apply to Mozilla for inclusion of their next generation root certificate at least 2 years before the distrust date of the CA certificate they wish to replace. 869 | 870 | ### 7.5 Dedicated Root Certificates 871 | 872 | All root CA certificates added to Mozilla's Root Store after March 15, 2025, will only be trusted for either TLS server authentication (websites trust bit) or S/MIME email protection (email trust bit). Existing root CA certificates that do not comply with this requirement MUST transition to one or the other prior to December 31, 2028, i.e., by having one of their trust bits (websites or email) removed. 873 | 874 | CA operators with root certificates that have both the websites and email trust bits enabled SHOULD review the transition schedule associated with Section 7.4 (Root CA Lifecycles) when planning their compliance with this section 7.5. Specifically, CA operators SHOULD be aware that Mozilla’s trust bit transition schedule will result in the removal of the websites trust bit from certain root certificates before December 31, 2028. 875 | 876 | #### 7.5.1 Server Authentication Hierarchies 877 | 878 | Subordinate CA and end entity certificates issued under a Root CA certificate added after March 15, 2025, with the websites trust bit enabled MUST include an extendedKeyUsage extension that asserts only id-kp-serverAuth or both id-kp-serverAuth and id-kp-clientAuth. OCSP signing certificates are exempt from this EKU restriction and MUST only include the id-kp-OCSPSigning EKU. 879 | 880 | #### 7.5.2 S/MIME Hierarchies 881 | 882 | Subordinate CA and end entity certificates issued under a Root CA certificate added after March 15, 2025, with the email trust bit enabled MUST include an extendedKeyUsage extension that asserts id-kp-emailProtection. They MAY include other extendedKeyUsages, but they MUST NOT include extendedKeyUsages of id-kp-serverAuth, id-kp-codeSigning, id-kp-timeStamping, or anyExtendedKeyUsage. OCSP signing certificates are exempt from this EKU restriction and MUST only include the id-kp-OCSPSigning EKU. 883 | 884 | #### 7.5.3 Transition Plan for Existing Roots 885 | 886 | Root CA certificates included in Mozilla's Root Store as of January 1, 2025, that have both the websites and the email trust bits enabled MAY remain trusted after April 15, 2026, if the CA operator has submitted a transition plan by April 15, 2026, to migrate to dedicated hierarchies by December 31, 2028. 887 | 888 | Transition plans MAY include: 889 | 890 | 1. Submission of requests for inclusion of single-purpose roots; 891 | 2. Requests to remove the websites trust bit or the email trust bit from a dual-purpose root; 892 | 3. Timelines for phasing out conflicting uses of the root (e.g. dates by which inconsistent certificates will expire or issuance will cease); and 893 | 4. Revocation or replacement of certificates that do not meet the requirements of Sections 7.5.1 or 7.5.2. 894 | 895 | ## 8. CA Operational Changes 896 | 897 | CA operators SHALL NOT assume that trust is transferable. All CA operators whose certificates 898 | are included in Mozilla's root store MUST [notify Mozilla][Email-Us] before: 899 | 900 | * ownership or control of the CA’s certificate(s) changes; 901 | * an organization other than the CA operator obtains control of an unconstrained 902 | intermediate certificate (as defined in section 5.3 of this policy) that 903 | directly or transitively chains to a certificate included in Mozilla's root store - see [Process for non-Technically-Constrained Subordinate CAs][Process-for-External-CAs]; 904 | * ownership or control of the CA’s operations changes; *or* 905 | * there is a change in the CA's operations that could affect the CA's ability to comply with the requirements of this Policy. 906 | 907 | CA operators SHOULD err on the side of notification if there is any doubt. Mozilla will 908 | normally keep commercially sensitive information confidential. Throughout any 909 | change, CA operations MUST continue to meet the requirements of this policy. If 910 | one of the above events occurs, Mozilla MAY require additional audit(s) as a 911 | condition of remaining in the root store. CA operators are encouraged to notify Mozilla in 912 | advance in order to avoid unfortunate surprises. 913 | 914 | In addition, one or more of the following sections MAY apply. 915 | 916 | ### 8.1 Change in Legal Ownership 917 | 918 | This section applies when one company buys or takes a controlling stake in 919 | a CA or CA operator, or when an organization obtains control of a CA key pair that is 920 | within the scope of Mozilla's root store, unless it is constrained in 921 | compliance with section 5.3.1 of this policy. 922 | 923 | Mozilla MUST be notified of any resulting changes in the CA operator's CP, CPS, or combined CP/CPS. 924 | 925 | If the receiving or acquiring company is new to the Mozilla root store, 926 | it MUST demonstrate compliance with the entirety of this policy. There 927 | MUST be a public discussion regarding its admittance to the root store. 928 | If Mozilla reaches a positive conclusion after public discussion, then the affected certificate(s) MAY remain in the root store. If the entire 929 | CA operation is not included in the scope of the transaction, issuance is not 930 | permitted until the discussion has been resolved with a positive conclusion. 931 | 932 | ### 8.2 Change in Operational Personnel 933 | 934 | This section applies when operation of a CA certificate that is within the 935 | scope of Mozilla's root store and not constrained in compliance with section 936 | 5.3.1 of this policy is transferred to a different organization, 937 | whether by acquisition or contract. 938 | 939 | The transferor MUST ensure that the transferee is able to fully comply with 940 | this policy. The transferor will continue to be responsible for the root 941 | certificate's private key until Mozilla has been provided with an audit 942 | statement (or opinion letter) confirming successful transfer of the root 943 | certificate and key. Issuance MUST NOT occur until the transferee 944 | has provided all the information required by the CCADB, and demonstrated to 945 | Mozilla that they have all the appropriate audits, CP/CPS documents, and other 946 | systems in place. 947 | 948 | The transferor MUST notify Mozilla about any necessary changes to EV status or 949 | trust bits in Mozilla's root store. If the transferee will be technically capable of issuing EV certificates, the transferor MUST confirm that the 950 | transferee has or will get the relevant audits before issuing EV certificates. 951 | 952 | ### 8.3 Change in Secure Location 953 | 954 | This section only applies when section 8.1 and/or section 8.2 applies, and when the 955 | cryptographic hardware related to a CA certificate that is within the scope of 956 | Mozilla's root store and not constrained in compliance with section 957 | 5.3.1 of this policy is consequently moved from one secure location to another. 958 | 959 | This policy and the relevant WebTrust or ETSI requirements apply at all times, 960 | even during the physical relocation of a CA's online operations to a new data 961 | center and moving parts of an offline root certificate from one location to 962 | another. As such, a CA operator MUST always ensure that physical access to CA equipment 963 | is limited to authorized individuals, the equipment is operated under multi-person control, and unauthorized CA system usage is able to be detected at all 964 | times. The auditor MUST confirm that there are appropriate procedures in place 965 | to ensure that the requirements are met and that those procedures are followed. 966 | 967 | The following steps MUST be taken by the organization(s) concerned: 968 | 969 | * ensure that annual audit statements are current; 970 | * notify Mozilla of the pending change; 971 | * create a transfer plan (and legal agreement if more than one organization is 972 | involved) and have it reviewed by the auditors; 973 | * stop new certificate issuance at the current site before the transfer begins; 974 | * have an audit performed at the current site to confirm when the root 975 | certificate is ready for transfer, and ensure that key material is 976 | properly secured; 977 | * have the transfer ceremony witnessed by auditors and video recorded, 978 | with a physical exchange of the HSM or ciphertext containing the associated key 979 | material and certificates, and the multi-party authorization keys; 980 | * perform an audit at the new site to confirm that the transfer was successful, 981 | that the private key remained secure throughout the transfer, and that the root 982 | certificate is ready to resume issuance. This requirement MAY be met by 983 | including the transferred root certificate and key in the new owner's regular 984 | audits or by getting a point-in-time audit; *and* 985 | * send links to the updated CP, CPS, and the updated audit statements, opinion 986 | letter, or point-in-time audit statement to Mozilla. 987 | 988 | The regular annual audit statements MUST still happen in a timely manner. 989 | 990 | If a security issue arises during key transfer, then the organization(s) concerned MUST immediately file a [Vulnerability Disclosure][Vulnerability-Disclosure] in Bugzilla using a [secure bug][Sec-Bugs]. 991 | 992 | ### 8.4 Externally-Operated Subordinate CAs 993 | 994 | The operator of a root CA certificate that is included in Mozilla’s root store is at all times completely and ultimately accountable for every certificate signed under that root CA certificate, whether directly or through subordinate CAs or cross-certified CAs. The operator of the root CA certificate SHALL ensure that the operator of each subordinate or cross-certified CA fully and continually adheres to this policy. 995 | 996 | The root CA operator MUST complete Mozilla’s [Process for non-Technically-Constrained Subordinate CAs][Process-for-External-CAs] (including successful review and approval by Mozilla) before a new externally-operated subordinate CA begins issuing certificates under any of the following conditions: 997 | 998 | * the subordinate CA operator will obtain a unconstrained (per section 5.3.1 of this policy) CA certificate, and the subordinate CA operator is not approved by Mozilla to issue the type of certificates (email, TLS, or EV TLS), which they will be able to issue under the new CA certificate; 999 | * the root CA operator is cross-signing a CA certificate of a CA operator who is not currently in Mozilla’s root store; *or* 1000 | * the root CA operator is cross-signing a CA certificate of another CA operator who is currently in Mozilla’s root store, but the other CA operator has not been approved for the same trust bits (email or websites) or EV, and those trust bits or EV will be recognized under the cross-signed certificate that it will be receiving. 1001 | 1002 | We reserve the right to not approve subordinate CA certificates. This includes (but is not limited to) cases where we believe that approval of a subordinate CA operator would cause undue risks to users’ security. Mozilla is under no obligation to explain the reasoning behind such decisions. 1003 | 1004 | When any of the following conditions apply, the root CA operator is not required to perform Mozilla’s [Process for non-Technically-Constrained Subordinate CAs][Process-for-External-CAs] before the subordinate CA certificate begins issuing certificates: 1005 | 1006 | * the subordinate CA will be operated directly by the root CA operator under the exact same policies and practices of the root CA operator and within the same scope of audit reporting, and no new organizations will be involved in the management or operation of the CA; 1007 | * the CA certificate is technically constrained as described in section 5.3.1 of this policy; 1008 | * the subordinate CA operator: 1009 | - has previously undergone the [Process for non-Technically-Constrained Subordinate CAs][Process-for-External-CAs]; 1010 | - has been approved for the type of certificates to be issued (email, TLS, or EV TLS); *and* 1011 | - will operate under the same policies and practices as the previous review, and under the same scope of audit reporting as the prior subordinate CA certificate. (Newer versions of policies and practices MAY be used, provided that the subordinate CA operator follows the same versions of the policies for both the existing and new CA certificates.) 1012 | * as of June 1, 2022, the subordinate CA operator was already trusted for issuing the same type of certificates under an existing subordinate CA certificate that directly or transitively chains to a certificate included in Mozilla’s root store; *or* 1013 | * the root CA operator is cross-signing a CA certificate of another CA operator that is currently in Mozilla’s root store, and that other CA operator: 1014 | - will only be able to issue the same type of certificate (email, TLS, or EV TLS) that they are already approved for in Mozilla’s root store; *and* 1015 | - will operate both the cross-signed certificate and their CA certificate(s) under the same policies, practices, and scope of audit that their CA certificate was approved for. Newer versions of policies and practices MAY be used, provided that the cross-signed CA operator follows the same versions of the policies for both the cross-signed certificate and their CA certificate(s). 1016 | 1017 | ----- 1018 | 1019 | Any copyright in this document is [dedicated to the Public Domain][CC-0]. 1020 | 1021 | [Email-Us]: mailto:certificates@mozilla.org 1022 | [Bugzilla]: https://bugzilla.mozilla.org 1023 | [Trademark-Policy]: https://www.mozilla.org/foundation/trademarks/policy/ 1024 | [CA-Cert-Module]: https://wiki.mozilla.org/Modules/Activities#CA_Certificates 1025 | [CA-Policy-Module]: https://wiki.mozilla.org/Modules/Activities#Mozilla_CA_Certificate_Policy 1026 | [Gov-Module]: https://wiki.mozilla.org/Modules/Firefox_Technical_Leadership 1027 | [MDSP]: https://groups.google.com/a/mozilla.org/g/dev-security-policy 1028 | [EVGLs]: https://cabforum.org/working-groups/server/extended-validation/documents/ 1029 | [TLS-BRs]: https://cabforum.org/working-groups/server/baseline-requirements/documents/ 1030 | [SMIME-BRs]: https://cabforum.org/working-groups/smime/documents/ 1031 | [NSRs]: https://cabforum.org/working-groups/netsec/documents/ 1032 | [ETSI-319-411-1]: https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.04.01_60/en_31941101v010401p.pdf 1033 | [ETSI-319-411-2]: https://www.etsi.org/deliver/etsi_en/319400_319499/31941102/02.05.01_60/en_31941102v020501p.pdf 1034 | [ETSI-119-411-6]: https://www.etsi.org/deliver/etsi_ts/119400_119499/11941106/01.01.01_60/ts_11941106v010101p.pdf 1035 | [WebTrust-2.2.2]: https://www.cpacanada.ca/-/media/site/operational/ep-education-pld/docs/mds21216webtrustca-222final-(15).pdf 1036 | [WebTrust-NetSec]: https://www.cpacanada.ca/-/media/site/operational/ms-member-services/docs/webtrust/01618-ms_24-3464_webtrust-for-ca-network-security-v1-7_final.pdf 1037 | [WebTrust-BRs]: https://www.cpacanada.ca/-/media/site/operational/ms-member-services/docs/webtrust/01618-ms_24-3464_webtrust-for-ca-ssl-baseline-v2-8_final.pdf 1038 | [WebTrust-SMIME]: https://www.cpacanada.ca/-/media/site/operational/ms-member-services/docs/webtrust/01618-ms_24-3464_webtrust-for-ca-smime-certificates-v1-0-3_final.pdf 1039 | [WebTrust-For-CAs]: https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/principles-and-criteria 1040 | [WebTrust-EV]: https://www.cpacanada.ca/-/media/site/operational/ms-member-services/docs/webtrust/01618_ms_extended-validation-ssl_final_aoda-compliant.pdf 1041 | [CC-BY]: https://creativecommons.org/licenses/by/4.0/ 1042 | [CC-BY-SA]: https://creativecommons.org/licenses/by-sa/4.0/ 1043 | [CC-BY-ND]: https://creativecommons.org/licenses/by-nd/4.0/ 1044 | [CC-0]: https://creativecommons.org/publicdomain/zero/1.0/ 1045 | [CCADB-List]: https://groups.google.com/a/ccadb.org/g/public 1046 | [CCADB-Policy]: https://www.ccadb.org/policy 1047 | [CCADB-Revocation]: https://www.ccadb.org/cas/fields#revocation-information 1048 | [3647-6]: https://datatracker.ietf.org/doc/html/rfc3647#section-6 1049 | [5280-6.1.4]: https://datatracker.ietf.org/doc/html/rfc5280#section-6.1.4 1050 | [5280-4.2.1.12]: https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12 1051 | [6962-3.1]: https://datatracker.ietf.org/doc/html/rfc6962#section-3.1 1052 | [CA-Cert-Bug]: https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&product=CA%20Program&component=CA%20Certificate%20Root%20Program 1053 | [How-To-Apply]: https://wiki.mozilla.org/CA/Application_Process 1054 | [Root-Changes]: https://wiki.mozilla.org/CA/Certificate_Change_Process 1055 | [Sec-Bugs]: https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&component=CA%20Security%20Vulnerability&groups=ca-program-security&product=CA%20Program 1056 | [Policy-Update-Process]: https://wiki.mozilla.org/CA/Updating_Root_Store_Policy 1057 | [Policy-Archive]: https://wiki.mozilla.org/CA/Root_Store_Policy_Archive 1058 | [Incident]: https://wiki.mozilla.org/CA/Responding_To_An_Incident 1059 | [Capable-of-EV]: https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable 1060 | [Audited-Location]: https://wiki.mozilla.org/CA/Audit_Statements#Audited_Locations 1061 | [Auditor-Qualifications]: https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications 1062 | [Process-for-External-CAs]: https://wiki.mozilla.org/CA/External_Sub_CAs 1063 | [ACAB'c]: https://www.acab-c.com/members/ 1064 | [WebTrust Practitioners]: https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/licensed-webtrust-practitioners-international 1065 | [Revocation-Reasons]: https://wiki.mozilla.org/CA/Revocation_Reasons 1066 | [Vulnerability-Disclosure]: https://wiki.mozilla.org/CA/Vulnerability_Disclosure 1067 | 1068 | --------------------------------------------------------------------------------