Certisign CP/CPS Review based on:
The CP and CPS must be revised and updated annually. Mozilla Root Store Policy 3.3.4 - https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses
Table of Contents
Good - Document follows the RFC 3647 framework.
First bullet says, “CERTISIGN TRUST NETWORK PKI service providers who have to operate in terms of their own Certificate Practices (CP) that complies with the requirements laid down by the CPS,” which raises the question, who are the PKI service providers affiliated with or working with Certisign in providing the PKI services described in this CPS?
References to CA/Browser Forum guidelines are outdated and need to be updated. The specific references could be replaced with language about complying to “the then-current” version of each of the specified CABF Guidelines.
Typo – “throught”
Reference made to “Affiliates act as RAs”. Who are affiliates?
RAs and Enterprise RAs may not perform domain validation. The CPS should explicitly say that delegation of domain validation to third parties is prohibited.
1.2.1 CABF Policy Identifiers
Title “CABF Policy Identifiers” should be changed to just “Policy Identifiers”
What does the “16” stand for at the end of the OID?
Table is good. It shows document change control.
1.3 PKI Participants
Cross reference to Certisign CP makes it difficult to evaluate Certisign’s PKI Practices.
Certisign Network CP has not been updated in over one year.
Certisign CP section 1.3.2 clarifies that RAs are not allowed to perform domain and IP address validation under sections 126.96.36.199 and 188.8.131.52 of the CP, but this is not stated as the practice in the CPS.
1.4 Certificate Usage
Typo or wrong word ”throught” in sentence, “CERTISIGN SSL CERTIFICATE AUTHORITY issues certificate to be used by Subscribers to secure websites throught Organization Validation.”
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.
2.2 Publication of Information
Typo – publishs
2.3 Time or Frequency of Publication
Section 2.3 of the CP states that Certisign updates the CP and CPS at least annually, but those updates have not yet been made publicly available in over a year.
2.4 Access Controls on Repositories
CP states that “CERTISIGN and Affiliates SHALL, however, require persons to agree to a Relying Party Agreement or CRL Usage Agreement as a condition to accessing Certificates, Certificate status information or CRLs.” How is this implemented?
3.1.1 Type of Names (EV SSL CPS)
For Table 2, review and update it in accordance with section 9.2 of the EV Guidelines.
184.108.40.206 CABF Naming Requirements
Good - Section asserts that DV and OV SSL Certificates conform to the CA / Browser Forum Baseline requirements, but section 220.127.116.11 of the EV CPS shouldn’t have that language.
For Issuer Organization Name, the CP and CPS state, “The field MUST NOT contain a generic designation such as “Root” or “CA1””. I think that requirement was removed from the BRs. It wasn’t an entirely accurate. The field must not contain “only” a generic designation. (The CN has to be somewhat descriptive.) I think this sentence could be deleted from the CP and CPS.
“Issuer commonName (Optional)” is misleading. Section 18.104.22.168.1. of the Baseline Requirements makes the CN field in CA’s subject required. “Contents: This field MUST be present and the contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate.”
These comments apply equally to the EV CPS. Section 22.214.171.124 of the EV CPS should be updated in accordance with Section 9.2 of the EV Guidelines.
3.1.3 Anonymity or Pseudonymity of Subscribers
Section 3.2.2 of the Baseline Requirements says that if the certificate asserts an identity, that identity must be verified. Section 126.96.36.199.2 of the Baseline Requirements requires that the contents of the certificate are what has been verified. In other words, pseudonymity is not allowed for OV and EV. (DV certificates don’t contain such information, so one could argue there is some anonymity with DV.)
188.8.131.52. CABF Verification Requirements for EV
This section seems misplaced. (It’s located as a subsection of 3.2.1 Method to Prove Possession of Private Key.) Shouldn’t it be a subsection to section 3.2.2?
184.108.40.206. Validation of Domain Authorization or Control
This section of the BRs has been revised.
Please describe in detail if these methods are used and how your CA meets the BR section 220.127.116.11 requirements.
18.104.22.168.1 Validating the Applicant as a Domain Contact
This method SHALL NOT be used.
22.214.171.124.2 Email, Fax, SMS, or Postal Mail to Domain Contact
126.96.36.199.3 Phone Contact with Domain Contact
This method has been replaced by 188.8.131.52.15 and SHALL NOT be used. (Validations completed as of 31-May-2019 may be used until 20-August-2021.)
184.108.40.206.4 Constructed Email to Domain Contact
220.127.116.11.5 Domain Authorization Document
This method SHALL NOT be used for validation.
18.104.22.168.6 Agreed‐Upon Change to Website
Replaced with BR section 22.214.171.124.18 (effective 3/3/2020)
126.96.36.199.7 DNS Change
188.8.131.52.8 IP Address
184.108.40.206.9 Test Certificate
This method SHALL NOT be used.
220.127.116.11.10. TLS Using a Random Number
Allowed (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.)
18.104.22.168.11 Any Other Method
This method SHALL NOT be used.
22.214.171.124.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.
126.96.36.199.13 Email to DNS CAA Contact
188.8.131.52.14 Email to DNS TXT Contact
184.108.40.206.15 Phone Contact with Domain Contact
220.127.116.11.16 Phone Contact with DNS TXT Record Phone Contact
18.104.22.168.17 Phone Contact with DNS CAA Phone Contact
22.214.171.124.18 Agreed-Upon Change to Website v2
126.96.36.199.19 Agreed-Upon Change to Website - ACME
188.8.131.52. Authentication for an IP Address
This section of the BRs has been revised.
Please describe in detail if these methods are used and how your CA meets the BR section 184.108.40.206 requirements.
220.127.116.11.1. Agreed-Upon Change to Website
18.104.22.168.2. Email, Fax, SMS, or Postal Mail to IP Address Contact
22.214.171.124.3. Reverse Address Lookup
126.96.36.199.4. Any Other Method
This method SHALL NOT be used.
188.8.131.52.5. Phone Contact with IP Address Contact
184.108.40.206.6 ACME “http-01” method for IP Addresses
220.127.116.11.7 ACME “tls-alpn-01” method for IP Addresses
18.104.22.168 (EV CPS)
The EV Guidelines have different sections for this -- 11.11.5 Qualified Independent Information Source; 11.11.6 Qualified Government Information Source; and 11.11.7 Qualified Government Tax Information Source.
22.214.171.124. CAA Records
Please note that RFC 6844 has been replaced by RFC 8659 (even though the Baseline Requirements have not yet been updated).
126.96.36.199 CABF Verification Requirements for Organization Applicants
The title doesn’t seem to match the discussion of IDNs and domain names.
3.2.3 Authentication of Individual Identity (EV CPS)
Section 11.2.1(3), 11.2.2(3) and (4), and 11.11.3 of the EV Guidelines set forth the requirements for this section 3.2.3 of the CPS. Also, the EV Guidelines don’t use “Reliable Method of Communication”. Instead they use “Verified Method of Communication.”
3.2.4 Non-Verified Subscriber information (EV CPS)
Section 9.2.7 of the EV Guidelines allows the OU field if the CA “has verified this information in accordance with Section 11.” Thus, I don’t think it is “non-verified” information.
3.2.5 Validation of Authority (EV CPS)
The EV Guidelines don’t use “Reliable Method of Communication”. Instead they use “Verified Method of Communication.” Section 11.5.2 of the EV Guidelines specifies how to establish a “Verified Method of Communication” with the Applicant. Section 188.8.131.52 of the EV CPS cannot be used as the basis for establishing a Verified Method of Communication. Sections 11.8, 11.9, and 11.10 of the EV Guidelines specify how authority is validated.
3.2.6 Criteria for Interoperation
Section 8 of the Mozilla Root Store Policy requires that Mozilla receive notice whenever “an organization other than the CA obtains control of an unconstrained intermediate certificate (as defined in section 5.3.2 of [the Mozilla Root Store Policy]) that directly or transitively chains to the CA's included certificate(s).” See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#8-ca-operational-changes
184.108.40.206.1 SSL Certificates
This section references “aging and updating” which is not found in section 3.3.1. Currently for DV and OV certificates, information may be reused for 825 days (BR 4.2.1 and SSL CPS section 220.127.116.11-see below). For EV certificates, the reuse period is 13 months (EVG 11.14.3). (This EV period appears to be stated in Appendix C, Item 14.3, of the CP and EV CPS.)
Also, the phrase “in order to comply with these Requirements and the CA’s Certificate Policy and/or Certification Practice Statement” appears to be a copy-and-paste and not customized by Certisign.
4.2.1 Performing Identification and Authentication Functions
Only for DV certificates is the following absolutely correct: “Applicant information MUST include, but not be limited to, at least one FQDN or IP address to be included in the Certificate’s SubjectAltName extension.” (Applicant information for OV and EV certificates must include more information than just what is in the SAN.)
18.104.22.168. CABF Requirements for SSL Certificates
SSL CPS - Because it is now after March 1, 2018, some of this language can be removed.
EV SSL CPS – This is inaccurate. This should be replaced with reference to the 13 months in section 14.3 of Appendix C.
22.214.171.124. CABF Requirements for SSL Certificates
This language is obsolete and can be deleted. (It is addressed in Certisign CP/CPS section 126.96.36.199.1.1 - Reserved IP Address or Internal Names).
4.2.4 CABF Certificate Authority Authorization (CAA) Requirement
The Baseline Requirements now contain more items that must be discussed in a CA’s CP/CPS. Please review BR section 2.2.
4.5.1 Subscriber Private Key and Certificate Usage
Since Subscriber Keys are not being escrowed, “except as set forth in section 4.12” should be deleted.
188.8.131.52. Reasons for Revoking a Subordinate CA Certificate
The CPSes should contain the language in BR 184.108.40.206, or at least cross-reference CP section 220.127.116.11.
4.9.8 Maximum Latency for CRLs
The content about OCSP information isn’t proper for this section. Also, the following sentences are confusing and should be deleted. “Processing Centers shall have a web-based repository that permits Relying Parties to make online inquiries regarding revocation and other Certificate status information. A Processing Center, as part of its contract with a Service Center, shall host such a repository on behalf of the Service Center.” The location for OCSP responders should be embedded in the AIA extension of the certificate. That OCSP information needs to appear in either section 4.9.10 or section 4.10.
18.104.22.168. CABF Requirements for Delegation of Functions to Registration Authorities and Subcontractors for EV and EV Code Signing Certificates
The first sentence should be amended to prohibit the delegation of domain validation. “CERTISIGN MAY delegate the performance of all or any part of a requirement, except domain validation, to an Affiliate or a Registration Authority (RA) or subcontractor …”
5.7.3 Entity Private Key Compromise Procedures
According to section 4 of the CCADB Policy, “If an intermediate certificate is revoked, the CCADB must be updated to mark it as revoked, giving the reason why, within 24 hours for a security incident, and within 7 days for any other reason.” See https://www.ccadb.org/policy#4-intermediate-certificates
Below the phrase, “If CA Certificate revocation is REQUIRED, the following procedures are performed:” add something to the effect that Certisign will “update the CA record in the CCADB, giving the reason why, within 24 hours for a security incident, and within 7 days for any other reason.”
22.214.171.124. CABF CA Key Pair Generation Requirements
Mozilla Root Store Policy section 5.2 prohibits CAs from generating key pairs for subscribers. See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#52-forbidden-and-required-practices
6.1.6 Public Key Parameters Generation and Quality Checking
Mozilla Root Store Policy section 5.1 also requires that RSA keys have a “modulus size that in bits is divisible by 8, and is at least 2048.” https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#51-algorithms
6.1.7 Key Usage Purposes (as per X.509 v3 Key Usage Field)
Why are keys used for SSL required to have the nonrepudiation bit? This seems contrary to RFC 5280, section 126.96.36.199. Extended Key Usage, which says that only digitalSignature, keyEncipherment or keyAgreement key usage bits are consistent with the serverAuth EKU.
6.5 Computer Security Controls
Should cross-reference CP section 6.5 instead of saying “not applicable”.
6.7 Network Security Controls
Should cross-reference CP section 6.7 instead of saying “not applicable”.
188.8.131.52.1. CABF Subject Alternative Name Extension Requirements
Section 184.108.40.206.1 of the Baseline Requirements simplifies some of this language concerning underscores: “Entries in the dNSName MUST be in the "preferred name syntax", as specified in RFC 5280, and thus MUST NOT contain underscore characters ("_").”
220.127.116.11.2. CABF Subject Distinguished Name Fields Requirements (EV CPS) and 18.104.22.168.3. Subject Distinguished Name Fields for EV Certificates
Section 22.214.171.124.2 of the EV SSL CPS is not needed (“Not applicable”) because all of the EV Subject Distinguished Name fields are set forth in section 126.96.36.199.3 of the Certisign EV SSL CPS.
7.1.5 Name Constraints
This section is to discuss the application of name constraints to subordinate CAs, not certificate transparency.
188.8.131.52. Subscriber Certificates
Section 3.A.10 of the Microsoft Root Certificate Program Requirements ( https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#a-root-requirements) requires use of the CA/Browser Forum OIDs in Subscriber Certificates.
8.6 Communications of Results
Note that Mozilla and the CCADB Policy require that CAs provide annual updates of their audits. See https://www.ccadb.org/cas/updates; see also https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#3-documentation
Appendix A: Table of Acronyms and Definitions
Various definitions still reference the EV Guidelines without saying “EV Guidelines”. For example, “Section 11.11.1 of these Guidelines”, etc.
CICA has been renamed “CPA Canada”
The AICPA no longer runs the WebTrust Program. It is only run by CPA Canada.
“CPA” means “Chartered Professional Accountant” in Canada, and “Certified Public Accountant” in the U.S.
“Entry Date” should be “Expiry Date”
“VOID” should be “VoIP”
Appendix B: References
CA/Browser Forum document references need to be updated.