ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Updated April 2021 to match BR v. 1.7.4 and Mozilla Root Store Policy v. 2.7.1
2
CA's Self-Assessment of CP/CPS documents to CA/Browser Forum Baseline Requirements (BRs)
3
Introduction must include:
1) CA's Legal Name
2) Clear indication (subject and SHA1 or SHA256 fingerprints) about which root certificates are being evaluated, and their full CA hierarchy. In considering a root certificate for inclusion in NSS, Mozilla must also evaluate the current subordinate CAs and the selection/approval criteria for future subordinate CAs. Mozilla's CA Certificate Policy requires full disclosure of non-technically-constrained intermediate certificates chaining up to root certificates in NSS.
3) List the specific version(s) of the BRs that you used. For example: BR version 1.4.2, with the exception of the Domain Validation section 3.2.2.4 for which we used BR version 1.4.1.
4) List the specific versions of the CA's documents that were evaluated, and provide direct URLs to those documents. All provided CA documents must be public-facing, available on the CA's website, and translated into English.
5) If you intend to submit your self-assessment with statements such as "will add/update in our next version of CP/CPS", indicate when you plan to provide the updated documents.
Note: When you are doing your BR Self Assessment, if you find that the required information is not currently in your CP/CPS documents, then you may indicate what your CA currently does, how it is currently documented, that the next version of your CP/CPS will contain this information, and when the next version of your CP/CPS will be available.
4
5
6
BR/RFC 3647 Section NumberList the specific documents and section numbers of those documents which meet the requirements of each BR section Explain how the CA's listed documents meet the requirements of each BR section.
7
1.2.1. Revisions
Note the Effective Date for each item in the table. Certificates created after each Effective Date are expected to be in compliance with the item. Make sure your CA is in compliance with each of these items. After careful consideration, indicate if your CA is fully compliant with all items in the table, or clearly indicate action that your CA is taking to improve compliance.
8
1.2.2. Relevant Dates
Note the Compliance date for each item in the table. Those are the dates by which your CP/CPS and practices are expected to be updated to comply with the item. Make sure your CA is in compliance with each of these items. After careful consideration, indicate if your CA is fully compliant with all items in the table, or clearly indicate action that your CA is taking to improve compliance.
9
1.3.2. Registration Authorities
Indicate whether your CA allows for Delegated Third Parties, or not. Indicate which sections of your CP/CPS specify such requirements, and how the CP/CPS meets the BR requirements for RAs (including non-delegation of domain validation to RAs).
10
1.5.2 Contact person
BR Section 4.9.3 requires that this section 1.5.2 contain clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates.
11
2.1. Repositories
Provide the direct URLs to the CA's repositories
12
2.2 Publication of information - RFC 3647
"The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647."
13
2.2 Publication of information - CAA
Section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement SHALL state the CA's policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent with these Requirements.

It shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA "issue" or "issuewild" records as permitting it to issue. The CA SHALL log all actions taken, if any, consistent with its processing practice.
14
2.2. Publication of information - BR text
"The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest
published version."
--> Copy the specific text that is used into the explanation in this row. (in English)
15
2.2. Publication of information - test websites
"The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired."
--> List the URLs to the three test websites (valid, revoked, expired) for each root certificate under consideration. If you are requesting EV treatment, then the TLS cert for each test website must be EV.
16
2.3. Time or frequency of publication
"The CA SHALL ... annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements. The CA SHALL indicate conformance with this requirement by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document."

Indicate your CA's policies/practices to ensure that the BRs are reviewed regularly, and that the CA's CP/CPS is updated annually.
17
2.4. Access controls on repositories
Acknowledge that all Audit, CP, CPS documents required by Mozilla's CA Certificate Policy and the BRs will continue to be made publicly available.
18
3.2.2.1 Identity
If the Subject Identity Information in certificates is to include the name or address of an organization, indicate how your CP/CPS meets the requirements in this section of the BRs.
19
3.2.2.2 DBA/Tradename
If the Subject Identity Information in certificates is to include a DBA or tradename, indicate how your CP/CPS meets the requirements in this section of the BRs.
20
3.2.2.3 Verification of Country
If the subject:countryName field is present in certificates, indicate how your CP/CPS meets the requirements in this section of the BRs.
21
3.2.2.4 Validation of Domain Authorization or Control
Indicate which of the methods of domain validation your CA uses, and where this is described in your CP/CPS.

Section 2.2 of Mozilla's Root Store Policy states: "For a certificate capable of being used for SSL-enabled servers, the CA must ensure that the applicant has registered all domain(s) referenced in the certificate or has been authorized by the domain registrant to act on their behalf. This must be done using one or more of the methods documented in section 3.2.2.4 of the CA/Browser Forum Baseline Requirements. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with. CAs are not permitted to use 3.2.2.5 (4) ("any other method") to fulfill the requirements of method 3.2.2.4.8 (IP Address)." 		Make sure the CP/CPS states what the CA actually does, not what it could do. Such as which of the allowed domain validation methods the CA uses.
22
3.2.2.4.1 Validating the Applicant as a Domain Contact
This method SHALL NOT be used.		This method SHALL NOT be used.
23
3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact
If your CA uses this method of domain validation, indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
24
3.2.2.4.3 Phone Contact with Domain Contact
This method has been replaced by 3.2.2.4.15 and SHALL NOT be used. (Validations completed as of 31-May-2019 may be used until 20-August-2021.)		This method SHALL NOT be used.
25
3.2.2.4.4 Constructed Email to Domain Contact
If your CA uses this method of domain validation, indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
26
3.2.2.4.5 Domain Authorization Document
"This method SHALL NOT be used."		This method SHALL NOT be used.
27
3.2.2.4.6 Agreed‐Upon Change to Website
Replaced with BR section 3.2.2.4.18 (effective 3/3/2020)		This method SHALL NOT be used.
28
3.2.2.4.7 DNS Change
If your CA uses this method of domain validation, indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
29
3.2.2.4.8 IP Address
If your CA uses this method of domain validation, indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
30
3.2.2.4.9 Test Certificate
"This method SHALL NOT be used."		This method SHALL NOT be used.
31
3.2.2.4.10. TLS Using a Random Number
If your CA uses this method of domain validation, indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.

This subsection contains major vulnerabilities. If the CA uses this method, then the CA should describe how they are mitigating those vulnerabilities. If not using this method, the CPS should say so.		Further explanation is required if this method is used.
32
3.2.2.4.11 Any Other Method
"This method SHALL NOT be used."		This method SHALL NOT be used.
33
3.2.2.4.12 Validating Applicant as a Domain Contact
"This method may only be used if the CA is also the Domain Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name."

If your CA uses this method of domain validation, indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.		Use of this method is restricted, per the BRs.
34
3.2.2.4.13 Email to DNS CAA Contact
If your CA uses this method of domain validation, indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
35
3.2.2.4.14 Email to DNS TXT Contact
If your CA uses this method of domain validation, indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
36
3.2.2.4.15 Phone Contact with Domain Contact
If your CA uses this method of domain validation, indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
37
3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact
If your CA uses this method of domain validation, indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
38
3.2.2.4.17 Phone Contact with DNS CAA Phone Contact
If your CA uses this method of domain validation, indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
39
3.2.2.4.18 Agreed-Upon Change to Website v2
If your CA uses this method of domain validation, indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
40
3.2.2.4.19 Agreed-Upon Change to Website - ACME
If your CA uses this method of domain validation, indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
41
3.2.2.4.20 TLS Using ALPN - If your CA uses this method of domain validation, indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
42
3.2.2.5 Authentication for an IP Address
If your CA allows IP Addresss to be listed in certificates, indicate which methods your CA uses and how your CA meets the requirements in this section of the BRs.

Section 2.2 of Mozilla's root store policy says: "the CA must ensure that the applicant has control over all IP Address(es) referenced in the certificate. This must be done using one or more of the methods documented in section 3.2.2.5 of the CA/Browser Forum Baseline Requirements. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.5 it is complying with."		Method 3.2.2.5.4, Any Other Method, SHALL NOT be used.

"After July 31, 2019, CAs SHALL maintain a record of which IP validation method, including the relevant BR version number, was used to validate every IP Address."

43
3.2.2.6 Wildcard Domain Validation
If your CA allows certificates with a wildcard character (*) in a CN or subjectAltName of type DNS‐ID, then indicate how your CA meets the requirements in this seciton of the BRs.
44
3.2.2.7 Data Source Accuracy
Indicate how your CA meets the requirements in this section of the BRs.
45
3.2.2.8 CAs MUST check and process CAA records
Indicate how your CA meets the requirements in this section of the BRs.

Section 2.2 of the BRs states: "CA's Certificate Policy and/or Certification Practice Statement ... shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA "issue" or "issuewild" records as permitting it to issue."
46
3.2.3. Authentication of Individual Identity
47
3.2.5. Validation of Authority
48
3.2.6. Criteria for Interoperation or Certification
Disclose all cross-certificates in the CA hierarchies under evaluation.
49
4.1.1. Who Can Submit a Certificate Application
Indicate how your CA identifies suspicious certificate requests.
50
4.1.2. Enrollment Process and Responsibilities
51
4.2. Certificate application processing
BR section 2.2 says that section 4.2 of the CP/CPS SHALL state the CA's policy or practice on processing CAA Records for Fully Qualified Domain Names.
52
4.2.1. Performing Identification and Authentication Functions
Indicate how your CA identifies high risk certificate requests.
Re-use of domain / IP address validation is limited to 398 days and re-use of other validation information is limited to 825 days
53
4.2.2. Approval or Rejection of Certificate Applications
"CAs SHALL NOT issue certificates containing Internal Names."
54
4.3.1. CA Actions during Certificate Issuance
55
4.9.1.1 Reasons for Revoking a Subscriber Certificate
Indicate how your CA's CP/CPS lists the reasons for revoking end entity certificates and is consistent with the timeframes required by this section of the BRs.
56
4.9.1.2 Reasons for Revoking a Subordinate CA Certificate
Indicate how your CA's CP/CPS lists the reasons for revoking subordinate CA certificates and is consistent with the timeframes required by this section of the BRs.
57
4.9.2. Who Can Request Revocation
58
4.9.3. Procedure for Revocation Request
The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.
59
4.9.5. Time within which CA Must Process the Revocation Request
60
4.9.7. CRL Issuance Frequency
Indicate if your CA publishes CRLs. If yes, then please test your CA's CRLs.
61
4.9.9. On-line Revocation/Status Checking Availability
62
4.9.10. On-line Revocation Checking Requirements
Indicate how your CA meets all of the requirements listed in this section, including support of GET, update frequency (recently updated), and preventing errounious return of "good" status.
63
4.9.12 "CA's CP/CPS MUST clearly specify the methods that parties may use to demonstrate private key compromise." (MRSP 6)
64
4.9.13 Certificate suspension must not be supported
65
4.10.1. Operational Characteristics
66
4.10.2. Service Availability
67
5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS
68
5.2.2. Number of Individuals Required per Task
69
5.3.1. Qualifications, Experience, and Clearance Requirements
70
5.3.3. Training Requirements and Procedures
71
5.3.4. Retraining Frequency and Requirements
72
5.3.7. Independent Contractor Controls
73
5.4.1. Types of Events Recorded
Indicate how your CA meets the requirements of this section.
74
5.4.3. Retention Period for Audit Logs
75
5.4.8. Vulnerability Assessments
Indicate how your CA meets the requirements of this section.
76
5.5.2. Retention Period for Archive
77
5.7.1. Incident and Compromise Handling Procedures
Indicate how your CA meets the requirements of this section, including notifying Mozilla in the event of key compromise.
78
6.1.1. Key Pair Generation
79
6.1.1.3 Subscriber Key Pair Generation - the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA.
80
6.1.2. Private Key Delivery to Subscriber
81
6.1.5. Key Sizes
82
6.1.6. Public Key Parameters Generation and Quality Checking
83
6.1.7. Key Usage Purposes
84
6.2. Private Key Protection and Cryptographic Module Engineering Controls
85
6.2.5. Private Key Archival
86
6.2.6. Private Key Transfer into or from a Cryptographic Module
87
6.2.7. Private Key Storage on Cryptographic Module
88
6.3.2 Certificates issued SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days. Indicate how your CA meets the requirements of this section.
89
6.5.1. Specific Computer Security Technical Requirements
The CA SHALL enforce multi-factor authentication for all accounts capable of directly causing certificate issuance.
Indicate how your CA meets the requirements of this section.
90
7.1. Certificate profile
CAs SHALL generate non-sequential Certificate serial numbers greater than 0 containing at least 64 bits of output from a CSPRNG.
Indicate how your CA meets the requirements of this section.
91
7.1.1. Version Number(s)
92
7.1.2. Certificate Content and Extensions; Application of RFC 5280
93
7.1.2.1 Root CA Certificate
94
7.1.2.2 Subordinate CA Certificate
95
7.1.2.3 Subscriber Certificate
96
7.1.2.4 All Certificates
97
7.1.2.5 Application of RFC 5280
98
7.1.3. Algorithm Object Identifiers
99
7.1.3.1 SubjectPublicKeyInfo
100
7.1.3.2 Signature AlgorithmIdentifier