ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Updated August 2022 to include BR v. 1.8.4
2
CA Self-Assessment of CP/CPS and Compliance to CABF's Baseline Requirements
3
Introduction must include:
1) CA Operator's Legal Name
2) Clear indication (subject and SHA1 or SHA256 fingerprints) about which root certificates are being evaluated, and their full CA hierarchy.
3) List the specific version(s) of the Baseline Requirements that you used, e.g. BR v.1.8.4
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 Compliance 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
BR v. 1.8.4CA SELF-ASSESSMENT
List the specific documents and section numbers of those CA documents that explain how the CA meets the requirements and explain if necessary.		DETAILED ROOT PROGRAM REVIEW
Reviewer Comments (Highlight deficiencies in yellow for further review)
6
Preliminary Matters
7
Is the CP/CPS structured in accordance with RFC 3647?
The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 with no blank sections. (BR § 2.2)
8
CCADB Policy 5. "CAs must provide English versions of any Certificate Policy, Certification Practice Statement and Audit documents which are not originally in English, with version numbers matching the document they are a translation of. The English version is not required to be authoritative in all cases of dispute, but the CA must attest that the translation is not materially different to the original."
9
Baseline Requirements for TLS Server Certificates
10
1 INTRODUCTION
11
1.1 Overview
Statement of adherence to BRs and their precedence (BR § 2.2) “The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version”, including a statement such as “in the event of any inconsistency between this CP/CPS and CA/Browser Forum Requirements, those Requirements take precedence.”
12
1.2.1. Revisions
Your CP/CPS should have its own table of revisions and there should be a statement somewhere in your CP/CPS that explicitly requires an annual update to your CP/CPS. (BR § 2.3) CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document. Also, version history tables provide evidence of compliance and good change management practices.
13
1.2.2. Relevant Dates
Note the Compliance date for each item in this table found in the BRs. 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.
14
15
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 per BR § 1.3.2).
16
17
1.5.2 Contact person
In addition to providing contact information in CP/CPS § 1.5.2, BR § 4.9.3 requires that CP/CPS § 1.5.2 also 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.
18
2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
19
Annually update CP and/or CPS. (BR § 2)
20
2.1. Repositories
Provide the direct URLs to the CA's repositories
21
2.2 Publication of information - RFC 3647
22
CP/CPS MUST include all material required by RFC 3647. (BR § 2.2)
23
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.
24
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)
25
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.
26
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 (and the Mozilla Root Store Policy) are reviewed regularly, and that the CA's CP/CPS is updated at least annually.
27
28
3. IDENTIFICATION AND AUTHENTICATION
29
3.1 Naming
Naming must be compliant with X.500, RFC5280 and BRs. The structure and use of names in certificates must comply with the Baseline Requirements (and EV Guidelines, if applicable), and other standards. Names for CAs should be meaningful and descriptive. Also, CNs and SANs in TLS server certificates cannot contain internal names or reserved IP addresses, see § 7.1.4.2.1 below.
30
3.1 Naming
Also, the CA should describe its practices for handling Internationalized Domain Names (IDNs) in its CP/CPS.
31
3.2.2 Authentication of Organization and Domain Identity
It is insufficient to just state that WHOIS is checked
32
3.2.2.1 Identity
If the certificate will contain Subject Identity Information (e.g. OV certificates with name or address of an organization), then indicate how your CP/CPS meets the requirements in this section of the BRs.
33
3.2.2.2 DBA/Tradename
If the certificate will contain a DBA or tradename, then indicate how your CP/CPS meets the requirements in this section of the BRs.
34
3.2.2.3 Verification of Country
If the subject:countryName field will be present in certificates, then indicate how your CP/CPS meets the requirements in this section of the BRs.
35
3.2.2.4 Domain Validation
Make sure the CP/CPS states what the CA actually does, not what it could do. Be sure to identify the specific subsection(s) of BR 3.2.2.4 that is/are being used and describe how the CA complies with that stated domain validation method.
36
3.2.2.4 If the CA will issue .onion certificates, then explain how your CA validates the FQDN in accordance with Appendix B.
37
3.2.2.4 For each FQDN validated, does your CA maintain a record of which of the following domain validation methods was used, including the relevant BR version number?
38
3.2.2.4.1 Validating the Applicant as a Domain Contact
This method SHALL NOT be used.
39
3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact
If your CA uses this method of domain validation, then 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.4 Constructed Email to Domain Contact
If your CA uses this method of domain validation, then 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.5 Domain Authorization Document
This method SHALL NOT be used.
42
3.2.2.4.6 Agreed‐Upon Change to Website
This method has been replaced with BR § 3.2.2.4.18 and shall not be used.
43
3.2.2.4.7 DNS Change
If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
44
3.2.2.4.8 IP Address
If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
45
3.2.2.4.9 Test Certificate
This method SHALL NOT be used.
46
3.2.2.4.10. TLS Using a Random Number
This method SHALL NOT be used.
47
3.2.2.4.11 Any Other Method
This method SHALL NOT be used.
48
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, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
49
3.2.2.4.13 Email to DNS CAA Contact
If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
50
3.2.2.4.14 Email to DNS TXT Contact
If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
51
3.2.2.4.15 Phone Contact with Domain Contact
If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
52
3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact
If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
53
3.2.2.4.17 Phone Contact with DNS CAA Phone Contact
If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
54
3.2.2.4.18 Agreed-Upon Change to Website v2
If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
55
3.2.2.4.19 Agreed-Upon Change to Website - ACME
If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
56
3.2.2.4.20 TLS Using ALPN - If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
57
3.2.2.5 Authentication for an IP Address
If your CA allows IP Addresses to be listed in certificates, indicate which methods your CA uses and how your CA meets the requirements in this section of the BRs. CA operators must "clearly specify the procedure(s) that the CA employs, and each documented procedure must state which subsection of 3.2.2.5 it is complying with." Also, CAs must maintain a record of the IP validation method used for each IP address and the relevant BR version number.

58
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 section of the BRs.
59
3.2.2.7 Data Source Accuracy
The CA's CP/CPS must explain how the CA determines that a third-party data source is reliable.
For OV – “[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.” (Additional criteria are found in BR § 3.2.2.7)
60
3.2.2.8 CAs MUST retrieve and process CAA records
Indicate how your CA meets the requirements of sections 2.2 and 3.2.2.8 of the BRs. NOTE: BR § 2.2 requires that "Section 4.2. of a CA's Certificate Policy and/or Certification Practice Statement ... state the CA’s policy or practice on processing CAA Records for Fully Qualified Domain Names [and] ... clearly specify the set of Issuer Domain Names that the CA recognises in CAA "issue" or "issuewild" records as permitting it to issue."
61
3.2.3. Authentication of Individual Identity
"The CA SHALL ... inspect the copy [of any personal ID] for any indication of alteration or falsification."
62
63
3.2.5. Validation of Authority
"[T]he CA SHALL use a Reliable Method of Communication to verify the authenticity of the Applicant Representative’s certificate request."
64
65
3.3.1 Identification and authentication for routine re-key
For data re-use, see BR § 4.2.1.
66
4. CERTIFICATE LIFE‑CYCLE OPERATIONAL REQUIREMENTS
67
4.1.1. Who Can Submit a Certificate Application
Indicate how your CA identifies suspicious certificate requests.
68
4.1.2. Enrollment Process and Responsibilities
The process must require 1. a certificate request, and 2. a Subscriber Agreement.
69
4.2. Certificate application processing
As previously stated above, BR § 2.2 says that the CA's CAA records processing must appear somewhere in section 4.2 of the CP/CPS.
70
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
71
4.2.2. Approval or Rejection of Certificate Applications
BR § 4.2.2 says, "CAs SHALL NOT issue certificates containing Internal Names." (This prohibition can appear elsewhere in your CP/CPS.)
72
4.9.1 Circumstances for revocation
CAs must revoke certificates with private keys that are known to be compromised, or for which verification of subscriber information is known to be invalid.
73
4.9.1.1 Reasons for Revoking a Subscriber Certificate
Your CA's CP/CPS' reasons and timeframes for revoking an end entity certificate must be consistent with the reasons and timeframes required by this section of the BRs (24-hour revocation for reasons 1 through 5, and 5 days for the second set of reasons 1 through 11).
74
4.9.1.2 Reasons for Revoking a Subordinate CA Certificate
Your CA's CP/CPS's reasons and timeframes for revoking subordinate CA certificates must be consistent with the reasons and timeframes required by this section of the BRs. (Revocation within 7 days for reasons 1 through 9). 
75
4.9.2. Who Can Request Revocation
In addition to accepting revocation requests from Subscribers, your CA should also accept revocation requests from Relying Parties, Application Software Suppliers, and other third parties who file Certificate Problem Reports. See BR § 4.9.3.
76
4.9.3. Procedure for Revocation Request
The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports. ... The CA SHALL publicly disclose clear instructions through readily accessible online means and in section 1.5.2 of their CPS.
77
4.9.5. Time within which CA Must Process the Revocation Request
The CA shall investigate and preliminarily respond to the Subscriber and the person filing a Certificate Problem Report within 24 hours. In any case requiring revocation, the timeframe from notice to revocation shall not exceed that stated in BR § 4.9.1.1.
78
4.9.7. CRL Issuance Frequency
Indicate if your CA publishes CRLs. If yes, then please test your CA's CRLs. CRLs must be issued at least every 7 days w/ nextUpdate of not more than 10 days (MRSP § 6)
79
4.9.9. On-line Revocation/Status Checking Availability
OCSP responses must be updated at least every 4 days w/ max. expiration of 10 days (MRSP § 6)        
80
4.9.10. Online 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 erroneous return of "good" status.
81
4.9.12 "CA's CP/CPS MUST clearly specify the methods that parties may use to demonstrate private key compromise." (MRSP § 6)
82
4.9.13 Certificate suspension
Suspension must not be supported (for TLS server certificates).
83
4.10 Certificate status services
84
4.10.2. Service Availability
CRL and OCSP resources must provide a response time of ten seconds or less under normal operating conditions.
85
5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS
86
The Network and Certificate System Security Requirements are incorporated by reference, and the CA SHALL develop, implement, and maintain a comprehensive security program. The security program MUST include an annual Risk Assessment. Based on the Risk Assessment, the CA SHALL develop, implement, and maintain a security plan. (BR § 5)
87
5.2.2. Number of Individuals Required per Task
CA Private Keys shall be managed only by personnel in trusted roles using, at least, dual control in a physically secured environment
88
5.3.1. Qualifications, Experience, and Clearance Requirements
The CA shall verify the identity and trustworthiness of persons involved in certificate management processes.
89
5.3.3. Training Requirements and Procedures
The CA must train and keep training records for personnel performing information verification duties.
90
5.3.4. Retraining Frequency and Requirements
All persons in trusted roles must maintain the necessary skills.
91
5.3.7. Independent Contractor Controls
Third parties performing information verification duties must meet the requirements of BR § 5.3.3.
92
5.4.1. Types of Events Recorded
Indicate how your CA meets the requirements of this section.
93
5.4.3. Retention Period for Audit Logs
Certain information has to be maintained for 2 years after certificate expiration/revocation or the occurrence of the security event.
94
5.4.8. Vulnerability Assessments
Indicate how your CA meets the requirements of this section.
95
5.5.2. Retention Period for Archive
Certain certificate information must be maintained in an archive for 7 years following expiration/revocation.
96
97
6. TECHNICAL SECURITY CONTROLS
98
6.1.1. Key Pair Generation
Indicate how your CA meets the requirements of this section.
99
6.1.1.3 Subscriber Key Pair Generation - For TLS server certificates, 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.
100
6.1.2. Private Key Delivery to Subscriber
"Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key without authorization by the Subscriber."