Closed Bug 1551703 Opened 2 years ago Closed 24 days ago

Enable EV for the "IdenTrust Commercial Root CA 1"

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: roots, Assigned: kwilson)

References

Details

(Whiteboard: [ca-approved] - In FF 84)

Attachments

(3 files)

12.60 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
60.36 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
56.56 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36

Steps to reproduce:

This request is to enable EV for the "IdenTrust Commercial Root CA 1"
root certificate.
The information for this request has been entered into the CCADB here:
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000417

Type: defect → enhancement
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Type: enhancement → task
Summary: Add IdenTrust root certificates → Enable EV for the "IdenTrust Commercial Root CA 1"

Bug #1339292 requested EV treatment for this "IdenTrust Commercial Root CA 1" root certificate, but the request was denied due to Bug #1500593 during the public discussion:

https://groups.google.com/d/msg/mozilla.dev.security.policy/fTeHAGGTBqg/ikgMfJeiAgAJ

Then I closed the bug/request with:
"This CA may re-apply for EV treatment for this root or for a new root by creating a new request"

Please explain the reason for re-applying for EV treatment for the same root.

(In reply to Kathleen Wilson from comment #1)

Bug #1339292 requested EV treatment for this "IdenTrust Commercial Root CA 1" root certificate, but the request was denied due to Bug #1500593 during the public discussion:

https://groups.google.com/d/msg/mozilla.dev.security.policy/fTeHAGGTBqg/ikgMfJeiAgAJ

Then I closed the bug/request with:
"This CA may re-apply for EV treatment for this root or for a new root by creating a new request"

Please explain the reason for re-applying for EV treatment for the same root.
IdenTrust is applying for extending our CA root “IdenTrust Commercial Root CA 1” to include EV SSL recognition with Mozilla browsers. We had previously submitted such request for the same root on March 2017, which was rejected on November 2018 with the conclusion: “This CA may re-apply for EV treatment for this root or for a new root by creating a new request”. The rejection of the previous application was due to failure by IdenTrust to disclose and remediate mis-issuance of 3 SSL certificates in February 2018 in a timely manner (https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/fTeHAGGTBqg/ikgMfJeiAgAJ and Bug #1500593).

We are reapplying because we have successfully remediated the behavior that prompted denial of the previous application. Since February 2018, we have disclosed and remediated issues that demonstrates our commitment to disclosure and remediation in line with expectations of the CA/B Forum and Mozilla community. In addition, we have established improved controls including the performance of periodic internal audits to ensure CA/B Forum and Mozilla Root policy compliance. Examples of these are: (i) Bug #1526099; and Bug#1542082. It should be noted that all reported items will also be included in our annual audit findings scheduled to be published in September 2019.

The information for this root inclusion request is available at the following URL.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000417

This request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.

There is a queue waiting for detailed CP/CPS reviews:
https://wiki.mozilla.org/CA/Dashboard#Detailed_CP.2FCPS_Review

Assignee: kwilson → wthayer
Whiteboard: [ca-cps-review] - KW 2019-06-04
Assignee: wthayer → bwilson

Reviewed Identrust’s CPS, v. 4.7.1 on 4-May-2020
https://www.identrust.com/sites/default/files/resources/TrustID_CPS_v4.7.1_3.26.2020_0.pdf

Preliminary Matters

RFC 3647 Format

The CPS is in RFC-3647 format without blank sections, which is good.

IP License

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.”

1.2

Table 1 is a revision history. This is good because it demonstrates document revision control.

1.2.2

Table 2 indicates that the CA/Browser Forum OIDs will be used, which is good.

1.3.2

This section indicates that Identrust always handles domain validation or IP Address Validation. Good.

1.4.2

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.

1.5.2

This section contains an email address for Certificate Problem Report submission. Good.

1.5.5.5

Identrust indicates that it conducts and annual review and revision of the CPS, even when no other changes are made. This is good.

2.2.2

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 7.1.4.2. 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 3.2.2.3 and 7.1.4.2.2.h of the Baseline Requirements.

3.2.2.3.3

Contains language prohibiting internal names and reserved IP addresses. Good.

3.2.2.4

Note that Phone Contact under BR section 3.2.2.4.3 has been replaced with BR section 3.2.2.4.15 and that Agreed-Upon Change to Website under BR section 3.2.2.4.6 has been replaced by BR section 3.2.2.4.18.

3.2.4

All information in certificates is verified – good.

4.2

Be aware that RFC 6844 has been replaced by RFC 8659.

4.2.1

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 4.2.2.1

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

4.9.1

Follows sections 4.9.1.1 and 4.9.1.2 of the CA/B Forum Baseline Requirements – good.

4.9.7 and 4.9.9

CRLs and OCSP responses issued every 12 hours – good

4.9.13

Suspension is not available for SSL/TLS – good.

5.7.3

Browsers notified in the event of a private key compromise – good.

6.1.2

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

6.1.6

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.

10.1.2

Validity Period – Identrust should remove the reference to a validity period of thirty-nine months.

12 Appendix

Contains a certificate hierarchy – good.

Ben, thank you for the preliminary review. We are finishing updates/revisions to the B.R. Self-Assessment mapping compliance to B.R. 1.6.9 in a CP/CPS version that it is being reviewed by our Policy Management Approval (PMA) committee. I will ensure to address your feedback in that version. Once I get PMA approval, I will attach here the updated Self-Assessment spreadsheet.

This an updated self-assessment as the initial one is not only a year-old but since then we have had 6 new CP/CPS updates

(In reply to Ben Wilson from comment #6)

Reviewed Identrust’s CPS, v. 4.7.1 on 4-May-2020
https://www.identrust.com/sites/default/files/resources/TrustID_CPS_v4.7.1_3.26.2020_0.pdf

Reviewed Identrust’s CPS, v. 4.7.2, dated 21-May-2020
https://www.identrust.com/sites/default/files/resources/identrust_trustid_cps_v4.7.2_05212020_0.pdf

IP License

New language has been added: "The copy of the “TrustID® Certificate Practice Statement” attached hereto (the “Policy Copy”) is provided to the Mozilla Foundation subject to the terms of that certain license known as “Creative Commons Attribution-NoDerivatives 4.0 International Public License” (which can be viewed at: https://creativecommons.org/licenses/by-nd/4.0/) "

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 7.1.4.2. 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 3.2.2.3 and 7.1.4.2.2.h of the Baseline Requirements.

Section 3.1.1 now states, "IdenTrust only generates and signs Certificates that contain a non-null Subject Distinguished Name (DN) complying with the X.500 standard, RFC 5280 and the CA/B Forum Baseline Requirements for naming." Also, Section 3.1.2 now states, "The Subject Distinguished Name fields are also subject to the requirements of Section 9.2 of the CA/Browser Forum Guidelines for the Issuance and Management of Extended Validation Certificates." This is good.

However, in a few places in the table in section 3.1.2 it continues to state, "It is allowable for the DN to be empty. CA/B Forum discourages, but does not prohibit the use of DN." Could Identrust please clarify this statement? I don't think this is correct, especially for OV and EV certificates. It seems that, by definition, OV and EV certificates populate the Subject DN with organization information, so I believe those statements are inaccurate.

3.2.2.4
Note that Phone Contact under BR section 3.2.2.4.3 has been replaced with BR section 3.2.2.4.15 and that Agreed-Upon Change to Website under BR section 3.2.2.4.6 has been replaced by BR section 3.2.2.4.18.

Section 3.2.2.4.2 (Constructed Email to Domain Contact) states, "This validation method is in line with CA/B Forum Baseline Requirements Section 3.2.2.4.6." I think this line is a mistake that needs to be deleted.

CPS Section 3.2.2.4.4 (Agreed-Upon Change to Website) now references "CA/B Forum Baseline Requirements Section 3.2.2.4.18." This is correct.

BR section 3.2.2.4.15 isn't referenced in this version of the CPS. Has phone call to the domain contact been eliminated?

4.2.1

The reuse limits on validation information for an EV certificate is 13 months, according to section 11.14.3 of the EV Guidelines.

Section 4.2.1 now states, "Effective September 1, 2020, reuse of previous validations is limited to no more than 398 days for all Server Certificates." This is good.

4.2.2 and 4.2.2.1

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

It is noted that section 6.5.1 of the Identrust CPS states, "All IdenTrust TrustID systems, including CA, CSA and RA server side, incorporate proper user Identity Proofing methodology. This methodology includes the use of user ID/password, Private/Public Key, and/or biometrics authentication schemes, plus multi-factor authentication where such is supported."

6.1.2
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

Section 6..1.2 of the Identrust CPS now states, "IdenTrust does not generate the key pairs for Subscriber Certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage."

6.1.6

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.)

This error has been fixed.

10.1.2

Validity Period – Identrust should remove the reference to a validity period of thirty-nine months.

This section now states, "Up to 815 days when issued after April 20, 2018 and up to 398 days when issued after August 31, 2020." Thanks.

Flags: needinfo?(roots)

(In reply to Ben Wilson from comment #9)

(In reply to Ben Wilson from comment #6)
However, in a few places in the table in section 3.1.2 it continues to state, "It is allowable for the DN to be empty. CA/B Forum discourages, but does not prohibit the use of DN." Could Identrust please clarify this statement? I don't think this is correct, especially for OV and EV certificates. It seems that, by definition, OV and EV certificates populate the Subject DN with organization information, so I believe those statements are inaccurate.
IdenTrust:
We have addressed this in CPS Ver. 4.7.3 approved on 06-15-2020 to be publish on or before 06-19-2020

3.2.2.4
Note that Phone Contact under BR section 3.2.2.4.3 has been replaced with BR section 3.2.2.4.15 and that Agreed-Upon Change to Website under BR section 3.2.2.4.6 has been replaced by BR section 3.2.2.4.18.

Section 3.2.2.4.2 (Constructed Email to Domain Contact) states, "This validation method is in line with CA/B Forum Baseline Requirements Section 3.2.2.4.6." I think this line is a mistake that needs to be deleted.
IdenTrust:
Corrected in CPS Ver. 4.7.3 approved on 06-15-2020 to be publish on or before 06-19-2020

BR section 3.2.2.4.15 isn't referenced in this version of the CPS. Has phone call to the domain contact been eliminated?
IdenTrust:
Correct, we do not use this validation method and therefore removed from the CPS

4.2.2 and 4.2.2.1

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

It is noted that section 6.5.1 of the Identrust CPS states, "All IdenTrust TrustID systems, including CA, CSA and RA server side, incorporate proper user Identity Proofing methodology. This methodology includes the use of user ID/password, Private/Public Key, and/or biometrics authentication schemes, plus multi-factor authentication where such is supported."
IdenTrust:
Correct

Our latest CP/CPS version 4.7.3 has been published: https://www.identrust.com/support/documents/trustid

Flags: needinfo?(roots)
Whiteboard: [ca-cps-review] - KW 2019-06-04 → [ca-ready-for-discussion 2020-06-16]

I just posted the following to the m.d.s.p. list:

This is a request to EV-enable the IdenTrust Commercial Root CA 1, as documented here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1551703

  • Summary of Information Gathered and Verified:

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000417

  • SHA2 hash for Root CA Certificate: 5D56499BE4D2E08BCFCAD08A3E38723D50503BDE706948E42F55603019E528AE

  • Root Certificate Download URL:

http://validation.identrust.com/roots/commercialrootca1.p7c

  • Identrust’s BR Self Assessment is located here:

https://bugzilla.mozilla.org/attachment.cgi?id=9153636 (Excel Spreadsheet Download)

  • CPS:

https://www.identrust.com/sites/default/files/resources/identrust_trustid_cps_v4.7.3_06.15.2020.pdf

  • Test Website:

https://ev-valid.identrustssl.com/

  • EV Policy OIDs:

2.16.840.1.113839.0.6.9, 2.23.140.1.1

  • CRL URL:

http://validation.identrust.com/crl/commercialrootca1.crl

  • OCSP URL:

http://commercial.ocsp.identrust.com

  • Audit:

A period of time WebTrust EV annual audit report was provided on August 16, 2019, by Schellman & Company, LLC, a licensed WebTrust auditor. That and other WebTrust audit reports are available from the bottom of the following applicant page: https://www.identrust.com/support/documents/trustid.

I’ve reviewed the CPS, BR Self Assessment, and related information for this inclusion request. Comments and concerns regarding the CPS were satisfactorily addressed as noted in https://bugzilla.mozilla.org/show_bug.cgi?id=1551703. I now recommend that the IdenTrust Commercial Root CA 1 be enabled for Extended Validation treatment.

This begins the 3-week comment period for this request.

I will greatly appreciate your thoughtful and constructive feedback on Identrust’s request.

Sincerely yours,

Ben Wilson

Whiteboard: [ca-ready-for-discussion 2020-06-16] → [ca-in-discussion] - 2020-07-10

Hi Kathleen,
The public discussion period for EV enablement has proceeded without comment. See https://groups.google.com/g/mozilla.dev.security.policy/c/s3WLH8was-k/m/BThPOPfmBwAJ in which I stated, "I intend to recommend that this request be approved unless there are any reasons why
the request should be denied."
I hereby recommend that we EV-enable the IdenTrust Commercial Root CA 1. I'll post another more official/final email to m.d.s.p.
Ben

Assignee: bwilson → kwilson
Flags: needinfo?(kwilson)
Whiteboard: [ca-in-discussion] - 2020-07-10 → EV - approved
Flags: needinfo?(kwilson)
Whiteboard: EV - approved → [ca-pending-approval] - 2020-08-03

As per Comment #13, and on behalf of Mozilla I approve this request from IdenTrust to enable EV for the following root certificate that is already included in NSS.

** 'IdenTrust Commercial Root CA 1' (Email, Websites), enable EV

I will file the PSM bug to enable EV treatment.

Whiteboard: [ca-pending-approval] - 2020-08-03 → [ca-approved] - Pending PSM code changes
Depends on: 1658596

I have filed bug #1658596 for the actual changes in PSM.

Status: ASSIGNED → RESOLVED
Closed: 24 days ago
Resolution: --- → FIXED
Whiteboard: [ca-approved] - Pending PSM code changes → [ca-approved] - In FF 84
You need to log in before you can comment on or make changes to this bug.