Closed Bug 1037590 Opened 5 years ago Closed 5 years ago

Add Renewal IdenTrust root certificates

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: roots, Assigned: kwilson)

References

Details

(Whiteboard: In NSS 3.18, Firefox 38)

Attachments

(7 files, 3 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 6.1; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.3; rv:11.0) like Gecko

Steps to reproduce:

This is a request to renew IdenTrust root certificates.  The new certificate names are: "IdenTrust Public Sector Root CA 1" and "IdenTrust Commercial Root CA 1".  They replace "DST ACES X6" and "DST Root X3" respectively.

All information about requirements for inclusion has been explained in the attached file. "Submission Package for Mozilla - Public-Commercial Roots - 071014.

File is provided in Word and PDF formats
The original root submission is under Bugzilla ID: 394733
I am accepting this bug, and will work on it as soon as possible, but I have a large backlog.
https://wiki.mozilla.org/CA:Schedule#Requests_in_the_Information_Gathering_and_Verification_Phase

I will update this bug when I begin the Information Verification phase.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attached file Initial CA Information Document (obsolete) —
Whiteboard: Information incomplete
The attached document summarizes the information that has been verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness, and provide the necessary information in this bug.
Attachment #8473387 - Attachment is obsolete: true
Comment on attachment 8476932 [details]
Initial CA Information Document

The following are answers to your questions for the DST Root X3

Question: 
Are there any externally-operated subordinate CAs that have been signed by the “DST Root X3” root?
IdenTrust Answer:
Yes.  IdenTrust has signed one subordinate CA that is externally operated.  This subordinate CA has a policy publicly published and has been audited under the WebTrust regime.  You can find the policy document, subordinate CA certificate and audit report in the test pages provided here: 

http://testssl.identrust.com/root_x3_intermediates.html

Question:
Are there any third-party issuers (e.g. RAs) that can cause the issuance of certs in the CA hierarchy of the “DST Root X3”

IdenTrust Answer:
Yes. Under the DST Root X3 there are RAs who can issue certificates.  Those RAs are bound by legal agreement to follow the Trust ID CP/CPS in issuing certificates.  IdenTrust does not currently have RAs who can approve SSL certificates.  
For the issuance of SSL certificates within large organizations, IdenTrust uses the Enterprise RA role in consistency with Baseline Requirements.  For this use case, IdenTrust has implemented procedural and technical controls.  In this instance, IdenTrust LRAs verify the domain ownership/control in every case (See section 3.2.7.2).  Then, systems are configured to allow the issuance of SSL certificates that are derivative subdomains of those domains previously authorized.  Enterprise RAs have a limited role. Section 5.2.4.12 outlines their functions.

Question:
Who is the TrustID CP intended for?

IdenTrust Answer:
TrustID CP is intended for the issuance of Certificates for Individual and Organizations, see Section 1.3.2.1. The purpose of those certificates is outline in Section 1.3.3.

Question:
Can anyone outside of IdenTrust verify that the domain name to be included in the certificate is owned/controlled by the certificate subscriber?  Where in the CPS is it stated who can do domain validation?

IdenTrust Answer:
Only LRAs that work for IdenTrust or an RA can verify domain ownership/control of a domain name.  LRAs are obligated to follow the procedures outlined in the CPS.  Currently, IdenTrust does not have any RAs that approve SSL certificates.  Section 3.2.7.2 explains the practices around domain ownership/control validation.  As seen there, only LRAs, not Enterprise RAs have this function.  Section 1.3.3 explains the relationship between IdenTrust, RA and LRAs.  Furthermore, Section 5.2.4.4 explains other LRA obligations. The definition of the Enterprise RA term can be found in Section 1.6.
Comment on attachment 8476932 [details]
Initial CA Information Document

The following are answers for the DST ACES X6 root

Question:
Are there any externally-operated subordinate CAs that have been signed by the “DST ACES X6” root?

IdenTrust Answer:
Currently there is no externally-operated subordinate CAs under this root.


Question:
Are there any third-party issuers (e.g. RAs) that can cause the issuance of certs in the CA hierarchy of the “DST ACES X6”

IdenTrust Answer:
Currently there are not third party issuers under this root.


Question
The ACES CPS Addendum has information about LRAs. Does the CPS or Addendum say that the LRA cannot do the verification of the domain name to be included in the certificate? Or does the CPS or addendum say that the LRA is an IdenTrust employee?

IdenTrust Answer:
Only LRAs that work for IdenTrust or an RA can verify domain ownership/control of a domain name.  LRAs are obligated to follow the procedures outlined in the CPS.  Currently, IdenTrust does not have any RAs that approve SSL certificates under this policy and root.  Section 3.1.9.4 explains the practices around domain ownership/control validation.  Under this CP/CPS, the Enterprise role does not currently exist.
Attached file Completed CA Information Document (obsolete) —
Just noticed the dates on the audit statements...
Please update this bug when the new audit statements are available.
Whiteboard: Information incomplete → Information incomplete -- Need updated audits
The new audit statements are now published here:

WebTrust for CAs
https://cert.webtrust.org/ViewSeal?id=1720

WebTrust Baseline Requirements
https://secure.identrust.com/certificates/policy/ts/current-baseline-requirements-audit.pdf

These links are also available in our test page: 
http://testssl.identrust.com/
Attachment #8497886 - Attachment is obsolete: true
This request has been added to the queue for public discussion. 
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Whiteboard: Information incomplete -- Need updated audits → Information confirmed complete
I am now opening the first public discussion period for this request from IdenTrust to include the “IdenTrust Commercial Root CA 1” and “IdenTrust Public Sector Root CA 1” root certificates, and turn on the Websites and Email trust bits for both. The “IdenTrust Commercial Root CA 1” root will eventually replace the “DST Root X3” certificate, and the “IdenTrust Public Sector Root CA 1” root will eventually replace the “DST ACES X6” certificate. Both of the currently-included root certificates were included via Bugzilla Bug #394733.

For a description of the public discussion phase, see 
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy forum.
https://www.mozilla.org/en-US/about/forums/#dev-security-policy

The discussion thread is called “IdenTrust Root Renewal Request”.

Please actively review, respond, and contribute to the discussion.

A representative of IdenTrust must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: Information confirmed complete → In Public Discussion
The public comment period for this request is now over. 

This request has been evaluated as per Mozilla’s CA Certificate Inclusion Policy at

https://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

Inclusion Policy Section 4 [Technical]. I am not aware of instances where IdenTrust has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug.

Inclusion Policy Section 6 [Relevance and Policy]. IdenTrust appears to provide a service relevant to Mozilla users. It is a for-profit corporation serving the private, commercial, and government sectors.

Below is a summary of each root certificate that was evaluated for this request.

Based on this assessment I intend to approve this request as stated below.

=== Root 1 of 2 ===

Subject: Include IdenTrust Commercial Root CA 1

Root Certificate Name: IdenTrust Commercial Root CA 1
O From Issuer Field: IdenTrust
Trust Bits: Email; Websites
EV Policy OID(s): Not EV

Root Certificate Download URL: https://bugzilla.mozilla.org/attachment.cgi?id=8473319

Certificate Summary: This SHA-256 root will eventually replace the SHA-1 “DST Root X3” certificate that was included via Bug #394733. The intent is to issue email and SSL certificates.

CA Document Repository: https://secure.identrust.com/certificates/policy/ts/
CP: https://secure.identrust.com/certificates/policy/ts/TrustID_CP_v1.6.1_20130912.pdf
CPS: https://secure.identrust.com/certificates/policy/ts/identrust_trustid_cps_v2.3_20140109.pdf
Other Relevant Documents: 

Certificate Revocation

CRL URL(s): http://validation.identrust.com/crl/commercialrootca1.crl
http://validation.identrust.com/crl/trustidcaa52.crl
(CRL NextUpdate: 24 hours)
TrustID CPS section 4.9.7: twenty-four hours

OCSP URL(s): http://commercial.ocsp.identrust.com

Inclusion Policy Section 7 [Validation]. IdenTrust appears to meet the minimum requirements for subscriber verification, as follows:

SSL Verification Procedures: According to the TrustID CPS section 3.2.7.2, IdenTrust verifies that the PKI Sponsor has the right to use or has control of the FQDN(s) or IP address(es) listed in the Certificate application by checking the WHOIS Domain Name Registrant, and contacting the Domain Name Registrant via email to confirm the authority of the PKI Sponsor to request a Device Certificate for the Domain Name(s) for which the PKI Sponsor has applied. If the PKI Sponsor applies for a Domain Name that contains a two-letter country code (ccTLD) (e.g. www.identrust.uk as opposed to www.identrust.com), this confirmation will be sought from the Domain Name level to which the ccTLD applies

Email Verification Procedures: According to Trust ID CPS section 3.2.5, Email verification can be done in two ways; electronically and manually through a list submitted by a Trusted Agent. Electronic verification is done via an email challenge-response mechanism. For Manual verification a Trusted Agent provides the list of authorized Applicants/PKI Sponsors, the email address is validated by the Trusted Agent based on the internal knowledge of the Sponsoring Organization. The Trusted Agent may use internal databases and directories to ensure the email accuracy.

Code Signing Subscriber Verification Procedures: Not requesting the code signing trust bit.

Inclusion Policy Sections 11-14 [Audit]. 
Annual audits are performed by BrightLine according to the WebTrust criteria.

Standard Audit: https://cert.webtrust.org/SealFile?seal=1720&file=pdf
BR Audit: https://secure.identrust.com/certificates/policy/ts/current-baseline-requirements-audit.pdf

Inclusion Policy Section 18 [Certificate Hierarchy]

CA Hierarchy: The intent is to generate the subordinate CA Certificates that will support our current lines of business under the root being replaced. At this time not all of the subordinate CA certificates have been generated (names may change)
- [Internal]TrustID CA A52 (s/mime certificates)
- [Internal]TrustID CA A12 (Device/SSL Certificates)

Externally Operated SubCAs: Currently none. In the future, there is the possibility of issuance of externally operated CAs under this root. In such case, IdenTrust will favor the independently audited and publicly disclose subordinate CA model of operation. 
Note that the “DST Root X3” root has signed one subordinate CA that is externally operated. This subordinate CA has a policy publicly published and has been audited under the WebTrust regime.

=== Root 2 of 2 ===

Subject: Include IdenTrust Public Sector Root CA 1

Root Certificate Name: IdenTrust Public Sector Root CA 1
O From Issuer Field: IdenTrust
Trust Bits: Email; Websites
EV Policy OID(s): Not EV

Root Certificate Download URL: https://bugzilla.mozilla.org/attachment.cgi?id=8473320

Certificate Summary: This SHA-256 root will eventually replace the SHA-1 “DST ACES X6” certificate that was included via Bug #394733. The intent is to issue email and SSL certificates.

CA Document Repository: https://secure.identrust.com/certificates/policy/aces/
CPS: https://secure.identrust.com/certificates/policy/aces/dst-aces-cps-v20040617.pdf
ACES CPS Addendum: https://secure.identrust.com/certificates/policy/aces/IdenTrust-Addendum-2013-11-26.pdf

Certificate Revocation

CRL URL(s): http://validation.identrust.com/crl/publicrootca1.crl
http://validation.identrust.com/crl/acesca2.crl
(CRL NextUpdate: 24 hours)
ACES CPS section 4.4.5.1: 18 to 24 hours

OCSP URL(s): http://public.ocsp.identrust.com

Inclusion Policy Section 7 [Validation]. IdenTrust appears to meet the minimum requirements for subscriber verification, as follows:

SSL Verification Procedures: According to ACES CPS Addendum section 3.1.9.4:, IdenTrust verifies that the PKI Sponsor has the right to use or has control of the FQDN(s) or IP address(es) listed in the Certificate application by checking the WHOIS Domain Name Registrant, and contacting the Domain Name Registrant via email to confirm the authority of the PKI Sponsor to request a Device Certificate for the Domain Name(s) for which the PKI Sponsor has applied. If the PKI Sponsor applies for a Domain Name that contains a two-letter country code (ccTLD) (e.g. www.identrust.uk as opposed to www.identrust.com), this confirmation will be sought from the Domain Name level to which the ccTLD applies

Email Verification Procedures: According to ACES Addendum section 3.1.9.7, Email verification can be done in two ways; electronically and manually through a list submitted by a Trusted Agent. Electronic verification is done via an email challenge-response mechanism. For Manual verification a Trusted Agent provides the list of authorized Applicants/PKI Sponsors, the email address is validated by the Trusted Agent based on the internal knowledge of the Sponsoring Organization. The Trusted Agent may use internal databases and directories to ensure the email accuracy.

Code Signing Subscriber Verification Procedures: Not requesting the code signing trust bit.

Inclusion Policy Sections 11-14 [Audit]. 
Annual audits are performed by BrightLine according to the WebTrust criteria.

Standard Audit: https://cert.webtrust.org/SealFile?seal=1720&file=pdf
BR Audit: https://secure.identrust.com/certificates/policy/ts/current-baseline-requirements-audit.pdf

Inclusion Policy Section 18 [Certificate Hierarchy]

CA Hierarchy: At the time of generation of this document, the intent is to generate the following subordinate under this root:
- [Internal]IdenTrust ACES CA 2 (s/mime, device/SSL certificates)

Externally Operated SubCAs: There are no plans to have externally operated subordinate CAs off this root at this time  Note that there are no externally-operated subordinate CAs that have been signed by the “DST ACES X6” root.

====

CA’s Response to Mozilla’s list of Potentially Problematic Practices
* Currently, IdenTrust does not issue Domain Validated certificates. If, in the future, DV certificates are issued, they will comply with current policy that limits certificates to 39 months.
* Wildcard SSL Certificates for the commercial root are OV.
TrustID CPS section 3.1.2: The entire Domain Namespace in Wildcard Certificates must be rightfully controlled by the Subscriber Organization.
* IdenTrust validates Domains for SSL certificates issued and does not delegate such validation. See TrustID CPS section 3.2.7.2 and ACES CPS Addendum 3.1.9.4.
* IdenTrust allows Trusted Agents to, in particular cases, manually validate the email of certificates. Trusted Agents are employees of the organizations requesting the certificate and are under agreement with IdenTrust. Trusted Agents validation is limited to emails within their organization and only in circumstances where automatic validation is not possible. See TrustID CPS section 3.2.5 and ACES CPS Addendum section 3.1.9.7 for detail.
* Commercial Root CA: There is a possibility of externally operated subordinate CAs. In such case, IdenTrust will favor the externally audited and publicly disclose model of operation.
* TrustID CPS: 3.2.7.3 Verification of DBA or Tradename: “…IdenTrust does not and will not issue SSL Certificates to reserved IP addresses or internal server names. “
ACES CPS Addendum: 1.3.2.3.1 – Agency and Relying Party Application SSL Server Certificates: “…IdenTrust does not and will not issue SSL Certificates to reserved IP addresses or internal server names.”
Whiteboard: In Public Discussion → Pending Approval
Attached file 1037590-CAInformation-SF.pdf (obsolete) —
For reference, attaching the completed CA Information as generated from SalesForce.
Attachment #8538036 - Attachment is obsolete: true
As per the summary in Comment #16, and on behalf of Mozilla I approve this request from IdenTrust to include the following root certificates:

** “IdenTrust Commercial Root CA 1” (websites, email)
** “IdenTrust Public Sector Root CA 1” (websites, email)

I will file the NSS bug for the approved changes.
Whiteboard: Pending Approval → Approved - awaiting NSS changes
Depends on: 1118020
I have filed bug #1118020 for the actual changes.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Whiteboard: Approved - awaiting NSS changes → In NSS 3.18, Firefox 38
IdenTrust folks: I noticed that even though you said Comment 9 there are no externally operated subordinate CAs or third-party issuers.  However, it appears that you have cross-certified the Federal Bridge CA underneath this root.

Subject: C=US, O=U.S. Government, OU=FPKI, CN=Federal Bridge CA 2013
Issuer:  C=US, O=IdenTrust, OU=IdenTrust Public Sector, CN=IdenTrust ACES CA 1
https://crt.sh/?id=9114292

Subject: C=US, O=IdenTrust, OU=IdenTrust Public Sector, CN=IdenTrust ACES CA 1
Issuer:  C=US, O=Digital Signature Trust, OU=DST ACES, CN=DST ACES CA X6
https://crt.sh/?id=136954

As I'm sure you're aware, the Mozilla Root CA Certificate Policy requires the following: "All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to a certificate included in Mozilla’s CA Certificate Program, MUST be operated in accordance with Mozilla’s CA Certificate Policy and MUST either be technically constrained or be publicly disclosed and audited."
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/

Could you please explain how you believe this cross-certificate to comply with this provision of the policy, or else what your plans are to fix this issue?
Flags: needinfo?(roots)
Richard: you are correct that in Comment 9, IdenTrust answered that no externally-operated subordinate CA for the “DST ACES CA x6” have been signed by the Root. At the time of the comment, we understood the question to apply to the Root only. We did not expand the question to subordinate CAs as the other the text you referenced requires.  

As you pointed out, the “IdenTrust ACES CA 1” Subordinate CA certificate has signed a cross-certificate that is managed by the United States Federal Bridge. This cross-certificate is not technically constrained beyond including the policy mapping extensions.

Cross-certifying a subordinated CA has been standard practice by not only IdenTrust, but other large CAs such as Symantec for more than a decade, based on a process that establishes: 

•	the Federal Bridge responsibilities to comply with the practices established for a Medium Assurance level within their Certificate Policy, which include publically documented practices and requirements for audits; and 
•	practices equivalency between the IdenTrust and Federal Bridge Certificate Policies.  

Upon further evaluation we have determined that this cross-certificate does not provide benefit to our customer and as such are not needed. IdenTrust will revoke this cross-certificate.  At this time, IdenTrust is consulting with the Federal Bridge on the revocation action and will execute it as soon as possible and most likely by February 19th.
Flags: needinfo?(roots)
Richard, you are correct that in Comment 9, IdenTrust answered that no externally-operated subordinate CA for the “DST ACES CA x6” have been signed by the Root. At the time of the comment, we understood the question to apply to the Root only. We did not expand the question to subordinate CAs as the other the text you referenced requires.  

As you pointed out, the “IdenTrust ACES CA 1” Subordinate CA certificate has signed a cross-certificate that is managed by the United States Federal Bridge. This cross-certificate is not technically constrained beyond including the policy mapping extensions.

Cross-certifying a subordinated CA has been standard practice by not only IdenTrust, but other large CAs such as Symantec for more than a decade, based on a process that establishes: 
•	the Federal Bridge responsibilities to comply with the practices established for a Medium Assurance level within their Certificate Policy, which include publically documented practices and requirements for audits; and 
•	practices equivalency between the IdenTrust and Federal Bridge Certificate Policies.  

Upon further evaluation we have determined that this cross-certificate does not provide benefit to our customer and as such are not needed. IdenTrust will revoke this cross-certificate.  At this time, IdenTrust is consulting with the Federal Bridge on the revocation action and will execute it as soon as possible and most likely by February 19th.
Thanks, I think that revoking the cross-certificate should address this issue.  This might be a good time to check for any other cross-signatures that might need to be disclosed or revoked.

Once you have revoked the certificate, please file a bug to add it to OneCRL and CC Mark Goodwin <mgoodwin@mozilla.com>
> Once you have revoked the certificate, please file a bug to add it to OneCRL

Rather than creating a new bug, you can add the info for this revoked certificate to Bug #1208264.
To ground the discussion, here is an endpoint serving a Federal PKI certificate alone (with no chain):
https://test1.fpki.18f.gov

And here is an endpoint serving a Federal PKI certificate with a chain up to Identrust's "DST ACES X6" root:
https://test3.fpki.18f.gov

When I visit the "test3" site above in Firefox, or on Chrome on Ubuntu 15.10, or using cURL with either OpenSSL or with GnuTLS on Ubuntu, it is validated as publicly trusted. 

"test1" is not validated and throws an error as chaining to an untrusted authority, the path construction doesn't work out. However, because of intermediate certificate caching, once I visit "test3", subsequent visits to "test1" begin working.

Though this may be relevant to another bug, I'll also note here that I created an additional test site using the same Federal PKI certificate that chains to a Symantec-owned CA trusted by Mozilla, which also validates in Firefox and other clients:
https://test4.fpki.18f.gov

(Intermediate certificate caching may inhibit easy browser testing of both test3 and test4, so you may need to use other clients, or reliably clear cached intermediates.)

x.509 extensions are not my area of expertise, but there is some discussion suggesting that, despite these cross-signatures, there are policy constraint extensions enabled that are supposed to prevent RFC 5280-compliant clients from validating these chains:

https://github.com/18F/fpki-testing/issues/1

In any case, I should be able to keep the test domains above active for use in testing at least until the revocation has been completed and widely deployed.
(In reply to Richard Barnes [:rbarnes] from comment #24)
> Thanks, I think that revoking the cross-certificate should address this
> issue.  This might be a good time to check for any other cross-signatures
> that might need to be disclosed or revoked.

Richard, as discussed IdenTrust has revoked the certificate.  Revocation was completed on February 17. We have verified that the chaining no longer works.  Let us know if you have any questions.
Well over 96 hours later, the referenced certificate path demonstrated in Comment 26 still remains valid:

https://github.com/18F/fpki-testing/issues/2
It does seem like there may be an issue with Firefox's revocation verification code. https://test3.fpki.18f.gov continues to validate for me.

There is some discussion in this Twitter thread about issues which may contribute to the problem:
https://twitter.com/kaiengert/status/701723146546757633

I have the "Query OCSP responder servers to confirm the current validity of certificates" option enabled in the Advanced options of Firefox (44.0.2, running on Ubuntu 15.10).
Actually, maybe this is simpler than expected. The revoked certificate is an intermediate, and Mozilla's Revocation Plan (https://wiki.mozilla.org/CA:RevocationPlan) states about OCSP checking:

> Revocation of intermediate certificates is only checked during EV validation.

So, the only way for this to take effect is via OneCRL, the bug for which is Bug #1208264.
Product: mozilla.org → NSS
You need to log in before you can comment on or make changes to this bug.