Reviewed Identrust’s CPS, v. 4.7.1 on 4-May-2020
RFC 3647 Format
The CPS is in RFC-3647 format without blank sections, which is good.
As a preliminary matter, the CPS says that it “is confidential material, is the intellectual property of IdenTrust Services, LLC, and intended for use only by IdenTrust, PKI Participants (as described herein) and licensees of IdenTrust. This document shall not be duplicated, used or disclosed, in whole or in part, for any purposes other than those approved by IdenTrust Services, LLC. IdenTrust TM is a trademark and service mark of IdenTrust, Inc., and is protected under the laws of the United States.”
In contrast, Mozilla Policy Section 3.3 states that if one of the enumerated Creative Commons licenses is not specified, “the fact of application is considered as permission from the CA to allow Mozilla and the public to deal with these documents, and any later versions for root certificates which are included in Mozilla's trust store, under CC-BY-ND 4.0.”
Table 1 is a revision history. This is good because it demonstrates document revision control.
Table 2 indicates that the CA/Browser Forum OIDs will be used, which is good.
This section indicates that Identrust always handles domain validation or IP Address Validation. Good.
Identrust prohibits use of certificates for active eavesdropping (e.g., MitM;) or traffic management of Domain Names or IP Addresses that the Organization does not own or control. This is good.
This section contains an email address for Certificate Problem Report submission. Good.
Identrust indicates that it conducts and annual review and revision of the CPS, even when no other changes are made. This is good.
Provides that the CA/Browser Forum requirements take precedence in the event of a conflict. This is good.
3.1.1 and 3.1.2
For naming, Identrust states that it follows the X.500 standard, except for Server Certificates where a null DN is allowable and suggested under CA/B Forum Baseline Requirements.
It is recommended that section 3.1.1. instead state that Identrust follows/complies with X.500, RFC 5280 and CA/Browser Forum requirements for naming.
Please consider revising and updating the table in section 3.1.2 based on a review of BR section 18.104.22.168. The row for “Server Extended Validation (EV)” should be based on a review of that plus section 9.2 of the EV Guidelines.
The CA/B Forum does not discourage the use of the subject DN. It is mainly the CN that is discouraged, but which is still allowed. The EV Guidelines govern what is in the DN for EV Certificates. The Baseline Requirements contain rules for what may be contained in the DN of OV and DV certificates. For what it is worth, many CAs, including those that issue DV certificates, include a country code, which is allowed under sections 22.214.171.124 and 126.96.36.199.2.h of the Baseline Requirements.
Contains language prohibiting internal names and reserved IP addresses. Good.
Note that Phone Contact under BR section 188.8.131.52.3 has been replaced with BR section 184.108.40.206.15 and that Agreed-Upon Change to Website under BR section 220.127.116.11.6 has been replaced by BR section 18.104.22.168.18.
All information in certificates is verified – good.
Be aware that RFC 6844 has been replaced by RFC 8659.
The reuse limits on validation information for an EV certificate is 13 months, according to section 11.14.3 of the EV Guidelines.
4.2.2 and 22.214.171.124
Contain references to “Identrust.com” as the CAA domain - good.
Maybe it is present, but I couldn’t find where Identrust states that it “enforce[s] multi-factor authentication for all accounts capable of causing certificate issuance or performing Registration Authority or Delegated Third Party functions” or that it “implement[s] technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses.” See Mozilla Root Store Policy section 2.1.3. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#21-ca-operations
Follows sections 126.96.36.199 and 188.8.131.52 of the CA/B Forum Baseline Requirements – good.
4.9.7 and 4.9.9
CRLs and OCSP responses issued every 12 hours – good
Suspension is not available for SSL/TLS – good.
Browsers notified in the event of a private key compromise – good.
This section states, “IdenTrust does not generate signature Private Keys for Subscribers.” However, Mozilla Root Store Policy 5.2 states, “CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage.” See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#52-forbidden-and-required-practices
The Identrust CPS says the “public exponent is in the range between 2^(16+1) and 2^(256-1).” However, the Baseline Requirements say the public exponent SHOULD be in the range between 2^(16) +1 and 2^(256) -1. (The font needs to be changed on the +1 and -1.)
Mozilla Root Store Policy also has an additional requirement that the RSA modulus size, in bits, shall not only be at least 2048 bits, but that it be divisible by 8. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#51-algorithms
There is also a typo in this section. “7.1.13” should be “7.1.3,” Initially, the intent of the sentence was unclear until I looked at section 7.1.3 of the CP, which had a more complete Table 8.
Validity Period – Identrust should remove the reference to a validity period of thirty-nine months.
Contains a certificate hierarchy – good.