Closed Bug 1339292 Opened 3 years ago Closed 1 year ago

Enable EV for "IdenTrust Commercial Root CA 1"

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: roots, Assigned: kwilson)

Details

(Whiteboard: [ca-denied] Comment #33)

Attachments

(12 files, 2 obsolete files)

205.37 KB, application/pdf
Details
187.42 KB, application/pdf
Details
122.00 KB, application/pdf
Details
47.41 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
119.96 KB, application/pdf
Details
326.41 KB, application/pdf
Details
1.11 MB, application/pdf
Details
84.32 KB, application/pdf
Details
67.74 KB, application/pdf
Details
187.42 KB, application/pdf
Details
4.56 MB, application/pdf
Details
1.52 MB, application/pdf
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

The original inclusion request bug is:  Bug 1037590.  https://bugzilla.mozilla.org/show_bug.cgi?id=1037590 

The CP and CPS associated to this request can be found here: https://secure.identrust.com/certificates/policy/ts/

At this time, IdenTrust has undergone a Point in Time audit.  The report is attached to this bug.

The EV check results are also attached.
Assignee: nobody → kwilson
Component: Untriaged → CA Certificates
Product: Firefox → mozilla.org
Version: 51 Branch → other
Whiteboard: [ca-initial] -- OK to begin Information Verification
Whiteboard: [ca-initial] -- OK to begin Information Verification → [ca-verifying]
Assignee: kwilson → awu
Hi,

I have started this certificate information verification process, I need your help to make sure that you have acknowledgement our policy and also identify in which CP/CPS section describes each of following items:

please read through our wiki link provided below.

Recommended Practices:

1. NEED CA's response to each of the items listed in https://wiki.mozilla.org/CA:Recommended_Practices#CA_Recommended_Practices

1) Publicly Available CP and CPS: (please provide direct links)
2) CA Hierarchy: (please provide which sections in CP/CPS, same for all following items)
3) Audit Criteria: 
4) Document Handling of IDNs in CP/CPS: 
5) Revocation of Compromised Certificates: 
6) Verifying Domain Name Ownership: 
7) Verifying Email Address Control: 
8) Verifying Identity of Code Signing Certificate Subscriber:  
9) DNS names go in SAN: 
10) Domain owned by a Natural Person: 
11) OCSP: 
12) Network Security Controls:


Problematic Practices:

2. NEED CA's response to each of the items listed in https://wiki.mozilla.org/CA:Problematic_Practices#Potentially_problematic_CA_practices

1) Long-lived DV certificates:
2) Wildcard DV SSL certificates:
3) Email Address Prefixes for DV Certs: 
4) Delegation of Domain / Email validation to third parties: 
5) Issuing end entity certificates directly from roots: 
6) Allowing external entities to operate subordinate CAs: 
7) Distributing generated private keys in PKCS#12 files: 
8) Certificates referencing hostnames or private IP addresses: 
9) Issuing SSL Certificates for Internal Domains: 
10) OCSP Responses signed by a certificate under a different root: 
11) SHA-1 Certificates:
12) Generic names for CAs: 
13) Lack of Communication With End Users: 
14) Backdating the notBefore date:

And 
Thank you very much!

Kind regards,
Aaron
Hi,

Please also perform the BR Self Assessment, and attach the resulting BR-self-assessment document to this bug.

Note:
Current version of the BRs: https://cabforum.org/baseline-requirements-documents/
Until a version of the BRs is published that describes all of the allowed methods of domain validation, use version 1.4.1 for section 3.2.2.4 (Domain validation): https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

= Background = 

We are adding a BR-self-assessment step to Mozilla's root inclusion/change process.

Description of this new step is here:
https://wiki.mozilla.org/CA:BRs-Self-Assessment

It includes a link to a template for CA's BR Self Assessment, which is a Google Doc:
https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing

Phase-in plan is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Y-PxWRCIcck/Fi9y6vOACQAJ

Please let me know if you have any question, thank you!


Kind regards,
Aaron
Whiteboard: [ca-verifying] → [ca-verifying] - Need BR Self Assessment
Product: mozilla.org → NSS
The requested self-assessment to resume SSL/TLS EV Certificates
Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324
Assignee: awu → kwilson
Comment on attachment 8939021 [details]
IdenTrust Commercial Root CA A1 Self-Assessment

Please use the attached most recent self-assessment as of Jan/31/2018
Attachment #8939021 - Attachment is obsolete: true
The attached document shows the current status of Information Verification for this request to enable EV treatment for the "IdenTrust Commercial Root CA 1" root cert.

The open items are in regards to the CA hierarchy. Mozilla must consider the full CA Hierarchy chaining up to each included root certificate, so please respond to all questions keeping in mind that your answers must take into account the full CA Hierarchy. 
** I am being redundant here, in an effort to avoid what happened here: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1037590#c23

I am concerned that the BR Self Assessment may have only been in regards to the root certificate, and may not have taken into account the full hierarchy chaining up to that root certificate. The intent of the BR Self Assessment is to take into account the full hierarchy.


In the attached document you will find the following items were clarification is needed.

1) NEED Identrust to explain their current CA hierarchy and audits.
The record for the "Booz Allen Hamilton BA CA 01" intermediate cert in CCADB says "Audits Same as Parent".
It is not clear if this intermediate cert is internally-operated by IdentTrust, or if it is operated by BAH.

IMPORTANT: Future audit statements must include the SHA-256 fingergerpritns of all root and intermediate certs that were in scope of the audit.
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#public-audit-information

2) NEED Identrust to explain the discrepancy between their BR Self Assessment and their CP/CPS:
Cross-certification with other, external CAs is allowed, per CP section 1.3.4.
However, BR Self Assessment says: "There are no cross-certified entities for the TrustID program, therefore this requirement is not applicable."

3) NEED Identrust to explain the discrepancy between their BR Self Assessment and their CP/CPS:
External RAs are allowed per CPS sections 1.3.3, 5.2.4; and CP sections 1.3.1.3, 2.1.3, 2.7.4,
However, in the BR Self Assessment Identrust said: "IdenTrust does not allow for Delegated Third Parties".
Whiteboard: [ca-verifying] - Need BR Self Assessment → [ca-verifying] - KW Comment #8 2018-03-26
We appreciate the feedback.  We will review and provide the required clarifications as soon as possible.   Thanks
Attachment #8948390 - Attachment is obsolete: true
(In reply to Kathleen Wilson from comment #8)
> Created attachment 8962543 [details]
> 1339292-CA-Information-March26-2018.pdf
> 
> The attached document shows the current status of Information Verification
> for this request to enable EV treatment for the "IdenTrust Commercial Root
> CA 1" root cert.
> 
> The open items are in regards to the CA hierarchy. Mozilla must consider the
> full CA Hierarchy chaining up to each included root certificate, so please
> respond to all questions keeping in mind that your answers must take into
> account the full CA Hierarchy. 
> ** I am being redundant here, in an effort to avoid what happened here: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1037590#c23
> 
> I am concerned that the BR Self Assessment may have only been in regards to
> the root certificate, and may not have taken into account the full hierarchy
> chaining up to that root certificate. The intent of the BR Self Assessment
> is to take into account the full hierarchy.
> 
> 
> In the attached document you will find the following items were
> clarification is needed.
> 
> 1) NEED Identrust to explain their current CA hierarchy and audits.
> The record for the "Booz Allen Hamilton BA CA 01" intermediate cert in CCADB
> says "Audits Same as Parent".
> It is not clear if this intermediate cert is internally-operated by
> IdentTrust, or if it is operated by BAH.
Identrust: It is operated by IdenTrust

> IMPORTANT: Future audit statements must include the SHA-256 fingergerpritns
> of all root and intermediate certs that were in scope of the audit.
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
> policy#public-audit-information
Identrust: Yes, our external auditor is made aware that for the audit report must include not only the roots but also the intermediate Sub-CAs
> 2) NEED Identrust to explain the discrepancy between their BR Self
> Assessment and their CP/CPS:
> Cross-certification with other, external CAs is allowed, per CP section
> 1.3.4.
> However, BR Self Assessment says: "There are no cross-certified entities for
> the TrustID program, therefore this requirement is not applicable."
IdenTrust: The BR Self-Assessment was corrected accordingly and attached here - Prior version was made obsolete.
> 3) NEED Identrust to explain the discrepancy between their BR Self
> Assessment and their CP/CPS:
> External RAs are allowed per CPS sections 1.3.3, 5.2.4; and CP sections
> 1.3.1.3, 2.1.3, 2.7.4,
> However, in the BR Self Assessment Identrust said: "IdenTrust does not allow
> for Delegated Third Parties".
IdenTrust: The BR Self-Assessment was corrected accordingly and attached here - Prior version was made obsolete.
This EV-enablement 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.
Assignee: kwilson → wthayer
Whiteboard: [ca-verifying] - KW Comment #8 2018-03-26 → [ca-cps-review] - KW 2018-04-05
I have performed a preliminary review of this request and have the following questions/concerns:

1. Please provide audit statements (WebTrust, BR, EV) for the two prior periods (2014-2015 and 2015-2016) during which this root existed.

2. The CPS describes a number of methods of domain name validation in section 3.2.10.5 that do not appear to fully comply with the BRs. Would you like to update the CPS to more clearly describe these methods (in line with Mozilla policy section 2.2) prior to moving to a public discussion of this request?

3. Three intermediate certificates have been disclosed under this root, but the EV audit explicitly lists only the TrustID Server CA A52 as in-scope. The A12 intermediate is constrained to emailProtection so that is out-of-scope, but the Booz Allen Hamilton BA CA 01 is not. The Booz Allen Hamilton BA CA 01 does contain a set of policy OIDs that exclude Identrust’s EV policy, but I do not believe this satisfies section 3.1.2 of Mozilla policy. In addition, two of the policy OIDs listed in this intermediate certificate are not documented in Identrust’s CP or CPS and thus cannot be verified to exclude EV.
* Have I missed any relevant information in my analysis of this issue?
* Would Identrust like to add the Booz Allen Hamilton BA CA 01 to their EV audit scope or take other actions before moving to a public discussion of this request?
Flags: needinfo?(roots)
Whiteboard: [ca-cps-review] - KW 2018-04-05 → [ca-cps-review] - Pending CA Response 19-July 2018
Hi Wayne,
Please let us review and provide a formal reply within the next few days.  Thanks
(In reply to Wayne Thayer [:wayne] from comment #14)
> I have performed a preliminary review of this request and have the following
> questions/concerns:
> 1. Please provide audit statements (WebTrust, BR, EV) for the two prior
> periods (2014-2015 and 2015-2016) during which this root existed.
IdenTrust:
Yes, please see attachment
> 2. The CPS describes a number of methods of domain name validation in
> section 3.2.10.5 that do not appear to fully comply with the BRs. Would you
> like to update the CPS to more clearly describe these methods (in line with
> Mozilla policy section 2.2) prior to moving to a public discussion of this
> request?
IdenTrust:
Thank you for giving us the opportunity to update the CPS accordingly, including the missing OIDs for #3 below. We will have this done within a few weeks and will let you know when the approved versions are published.
> 3. Three intermediate certificates have been disclosed under this root, but
> the EV audit explicitly lists only the TrustID Server CA A52 as in-scope.
> The A12 intermediate is constrained to emailProtection so that is
> out-of-scope, but the Booz Allen Hamilton BA CA 01 is not. The Booz Allen
> Hamilton BA CA 01 does contain a set of policy OIDs that exclude Identrust’s
> EV policy, but I do not believe this satisfies section 3.1.2 of Mozilla
> policy. In addition, two of the policy OIDs listed in this intermediate
> certificate are not documented in Identrust’s CP or CPS and thus cannot be
> verified to exclude EV.
IdenTrust:
For #3, Section 3.1.2 is requiring all three audits for all subordinate CAs.  Unfortunately, this requirement does not take into account (or at least provide a way to address ) a scenario in which there exists a subordinate CA that is not technically constrained but also does not issue SSL (or EV SSL) certificates.  This is the case with the Booz Allen Hamilton (BAH) SubCA.  The BAH SubCA is constrained by practice (note in Appendix C of TrustID CPS) to only issue end entity certificates that are allowed Client Authentication, Digital Signature, and  S/MIME capability through the EKU extension on the end entity certificate.  In addition, the policy OID extension on the BAH SubCA certificate does not include policy OIDs associated with SSL certificates.  As such, in practical operations the BAH SubCA is constrained and does not issue SSL certificates (or has ever issued an SSL certificate).  Please note that the BAH SubCA is included in our WebTrust audit. In the 2018 WebTrust Audit report we will ensure that all subca's of the root are properly addressed including full compliance with Mozilla policy section 3.1.4.
> * Have I missed any relevant information in my analysis of this issue?
> * Would Identrust like to add the Booz Allen Hamilton BA CA 01 to their EV
> audit scope or take other actions before moving to a public discussion of
> this request?
Flags: needinfo?(roots)
(In reply to roots from comment #16)
> (In reply to Wayne Thayer [:wayne] from comment #14)
> > I have performed a preliminary review of this request and have the following
> > questions/concerns:
> > 1. Please provide audit statements (WebTrust, BR, EV) for the two prior
> > periods (2014-2015 and 2015-2016) during which this root existed.
> IdenTrust:
> Yes, please see attachment
> > 2. The CPS describes a number of methods of domain name validation in
> > section 3.2.10.5 that do not appear to fully comply with the BRs. Would you
> > like to update the CPS to more clearly describe these methods (in line with
> > Mozilla policy section 2.2) prior to moving to a public discussion of this
> > request?
> IdenTrust:
> Thank you for giving us the opportunity to update the CPS accordingly,
> including the missing OIDs for #3 below. We will have this done within a few
> weeks and will let you know when the approved versions are published.
> > 3. Three intermediate certificates have been disclosed under this root, but
> > the EV audit explicitly lists only the TrustID Server CA A52 as in-scope.
> > The A12 intermediate is constrained to emailProtection so that is
> > out-of-scope, but the Booz Allen Hamilton BA CA 01 is not. The Booz Allen
> > Hamilton BA CA 01 does contain a set of policy OIDs that exclude Identrust’s
> > EV policy, but I do not believe this satisfies section 3.1.2 of Mozilla
> > policy. In addition, two of the policy OIDs listed in this intermediate
> > certificate are not documented in Identrust’s CP or CPS and thus cannot be
> > verified to exclude EV.
> IdenTrust:
> For #3, Section 3.1.2 is requiring all three audits for all subordinate CAs.
> Unfortunately, this requirement does not take into account (or at least
> provide a way to address ) a scenario in which there exists a subordinate CA
> that is not technically constrained but also does not issue SSL (or EV SSL)
> certificates.  This is the case with the Booz Allen Hamilton (BAH) SubCA. 
> The BAH SubCA is constrained by practice (note in Appendix C of TrustID CPS)
> to only issue end entity certificates that are allowed Client
> Authentication, Digital Signature, and  S/MIME capability through the EKU
> extension on the end entity certificate.  In addition, the policy OID
> extension on the BAH SubCA certificate does not include policy OIDs
> associated with SSL certificates.  As such, in practical operations the BAH
> SubCA is constrained and does not issue SSL certificates (or has ever issued
> an SSL certificate).  Please note that the BAH SubCA is included in our
> WebTrust audit. In the 2018 WebTrust Audit report we will ensure that all
> subca's of the root are properly addressed including full compliance with
> Mozilla policy section 3.1.4.
> > * Have I missed any relevant information in my analysis of this issue?
> > * Would Identrust like to add the Booz Allen Hamilton BA CA 01 to their EV
> > audit scope or take other actions before moving to a public discussion of
> > this request?

Our latest CPS version 4.1 dated August 17, 2018 covering the expected details on domain validation methods and missing OID's has been published and it is available on our web portal at https://www.identrust.com/sites/default/files/resources/IdenTrust_TrustID_Certificate_Policy_V4.1_08172018.pdf
The link you provided in comment #22 is for an updated CP, but the concern I reported was with the CPS. Your repository doesn't reference newer versions of either document.

Also, will you please provide 2013-2014 audit statements? This root was created in Jan 2014, so the 2014-2015 statements don't go back quite far enough.
Flags: needinfo?(roots)
(In reply to Wayne Thayer [:wayne] from comment #23)
> The link you provided in comment #22 is for an updated CP, but the concern I
> reported was with the CPS. Your repository doesn't reference newer versions
> of either document.
> 
> Also, will you please provide 2013-2014 audit statements? This root was
> created in Jan 2014, so the 2014-2015 statements don't go back quite far
> enough.

Here is the link for the CPS:https://www.identrust.com/sites/default/files/resources/IdenTrust_TrustID_Certificate_Practices_Statement_V4.1_08172018.pdf
Also in the attachments section I have added the 2013-2014 WebTrust Audit Reports
Flags: needinfo?(roots)
2014-08-04 IdenTrust - 2014 WebTrust for CA - Report.pd
IdenTrust (SSL) - 2014 WebTrust - Report.pdf
Although I found some additional issues with the CP and CPS during my detailed review, I went ahead and started the discussion period with the following comments:

==Good==
* Identrust’s audits prior to 2016 don’t list specific roots, but this root appears to have been audited back to its creation in 2014.
* In their latest BR audit statement [1], Identrust’s auditor includes an “Emphasis on Matters” section in which they list four BR violations disclosed by Identrust. All of these issues were previously known and are included in comments below.
* CPS section 1.4.2 expressly prohibits the use of Identrust certificates for MitM.

==Meh==
* There are a few misissued certs documented under this root [2][3]. All appear to be expired or revoked.
* Identrust was the subject of two compliance bugs last year [4][5]. Both have been resolved, but it was noted that Identrust was slow to respond to Mozilla’s questions.
* Three intermediate certificates have been disclosed under this root, but the EV audit explicitly lists only the TrustID Server CA A52 as in-scope. The A12 intermediate is constrained by EKU to emailProtection, but the Booz Allen Hamilton BA CA 01 is not. The Booz Allen Hamilton BA CA 01 does contain a set of policy OIDs that exclude Identrust’s EV policy, but that does not satisfy section 3.1.2 of Mozilla policy. However, Firefox will not display an EV indication if the intermediate certificate’s certificatePolicies extension does not include either anyPolicy or the CAs or CABF EV policy OID, so I believe this is a problem with our policy.
* Identrust’s CPS section 1.3.2 allow delegation of the RA function but doesn’t explicitly state that domain validation must be performed by Identrust. The CPS does state that it complies with the BRs which forbid delegation of domain validation.
* CPS section 2.3 states that the PMA updates the CPS on an annual basis to include the most recent CAB Forum requirements, but Mozilla expects CPS updates to happen whenever required by changes to either CAB Forum requirements or Mozilla policy. However, both the CP and CPS have been updated more frequently in the past year.
* Typo in CPS section 6.9 heading: “ENGINREERING”

==Bad==
* Identrust had an open compliance bug for improper encoding of 6 wildcard certificates [6]. Remediation for this bug included the implementation of pre-issuance linting by the end of Q3, more than 6 months after the issue was reported. Identrust also chose to wait a week before revoking all of the misissued certificates. This could be considered another example of Identrust being slow to respond, but they did confirm that pre-issuance linting was deployed in August, well ahead of their goal.
* The version of the CPS that I initially reviewed (4.0) describes a number of methods of domain name validation in section 3.2.10.5 that do not appear to fully comply with the BRs. This was corrected in the current version, but one of the methods listed is BR 3.2.2.4.10, which contains a known vulnerability [7].
* Two of the Identrust policy OIDs listed in the Booz Allen Hamilton BA CA 0 intermediate certificate were not documented in Identrust’s CP or CPS, but have been added to the latest version.
* Section 3.2 of the CPS states that “All documents and data provided for verifying the Server Certificate must not be used by the RA if the document or data was obtained 39 or more months prior to the Issuance of the Certificate or in the case of EV SSL, 13 months prior to issuance.”. The BRs now only allow reuse for up to 825 days.
* CP section 9.8 paragraph 3 appears to violate EVGL section 18’s restriction on liability limits for EV certificates by limiting aggregate liability. CPS section 9.8 may also contradict both the liability limits in the CP and the EVGL requirement.

[1] https://bug1484318.bmoattachments.org/attachment.cgi?id=9006626
[2] https://crt.sh/?caid=1588&opt=cablint,zlint,x509lint&minNotBefore=2014-01-01
[3] https://crt.sh/?caid=47552&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1391000
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1398255
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1446121
Whiteboard: [ca-cps-review] - Pending CA Response 19-July 2018 → [ca-in-discussion] - ends after 9-October 2018
(In reply to Wayne Thayer [:wayne] from comment #27)
> Although I found some additional issues with the CP and CPS during my
> detailed review, I went ahead and started the discussion period with the
> following comments:
> 
> ==Good==
> * Identrust’s audits prior to 2016 don’t list specific roots, but this root
> appears to have been audited back to its creation in 2014.
> * In their latest BR audit statement [1], Identrust’s auditor includes an
> “Emphasis on Matters” section in which they list four BR violations
> disclosed by Identrust. All of these issues were previously known and are
> included in comments below.
> * CPS section 1.4.2 expressly prohibits the use of Identrust certificates
> for MitM.
> 
> ==Meh==
> * There are a few misissued certs documented under this root [2][3]. All
> appear to be expired or revoked.
> * Identrust was the subject of two compliance bugs last year [4][5]. Both
> have been resolved, but it was noted that Identrust was slow to respond to
> Mozilla’s questions.
> * Three intermediate certificates have been disclosed under this root, but
> the EV audit explicitly lists only the TrustID Server CA A52 as in-scope.
> The A12 intermediate is constrained by EKU to emailProtection, but the Booz
> Allen Hamilton BA CA 01 is not. The Booz Allen Hamilton BA CA 01 does
> contain a set of policy OIDs that exclude Identrust’s EV policy, but that
> does not satisfy section 3.1.2 of Mozilla policy. However, Firefox will not
> display an EV indication if the intermediate certificate’s
> certificatePolicies extension does not include either anyPolicy or the CAs
> or CABF EV policy OID, so I believe this is a problem with our policy.
> * Identrust’s CPS section 1.3.2 allow delegation of the RA function but
> doesn’t explicitly state that domain validation must be performed by
> Identrust. The CPS does state that it complies with the BRs which forbid
> delegation of domain validation.
[IdenTrust:]Agree with this comment and confirm that IdenTrust as issuing CA is responsible for and does handle domain name validation prior the issuance of any server certificate. CPS Section 1.3.2 will be updated accordingly.
[IdenTrust:]
> * CPS section 2.3 states that the PMA updates the CPS on an annual basis to
> include the most recent CAB Forum requirements, but Mozilla expects CPS
> updates to happen whenever required by changes to either CAB Forum
> requirements or Mozilla policy. However, both the CP and CPS have been
> updated more frequently in the past year.
[IdenTrust:]
Agree with this comment and confirm that policy documents have been updated and published more than once a year.  CPS section 2.3 will be updated accordingly.

> * Typo in CPS section 6.9 heading: “ENGINREERING”
[IdenTrust:]Thanks for pointing out this typo; it will be corrected in the next CPS version.

> ==Bad==
> * Identrust had an open compliance bug for improper encoding of 6 wildcard
> certificates [6]. Remediation for this bug included the implementation of
> pre-issuance linting by the end of Q3, more than 6 months after the issue
> was reported. Identrust also chose to wait a week before revoking all of the
> misissued certificates. This could be considered another example of
> Identrust being slow to respond, but they did confirm that pre-issuance
> linting was deployed in August, well ahead of their goal.
> * The version of the CPS that I initially reviewed (4.0) describes a number
> of methods of domain name validation in section 3.2.10.5 that do not appear
> to fully comply with the BRs. This was corrected in the current version, but
> one of the methods listed is BR 3.2.2.4.10, which contains a known
> vulnerability [7].
[IdenTrust:]We have confirmed in the Jan/2018 CA Communication Survey that this method has not been used by IdenTrust. We added it to the CPS on 8/17/2017 as we were exploring the possibility to use it in the future but have decided to discard that option. This validation method will be removed for the CPS.   We also confirm that we have not used this validation method for any certificate issuance.
> * Two of the Identrust policy OIDs listed in the Booz Allen Hamilton BA CA 0
> intermediate certificate were not documented in Identrust’s CP or CPS, but
> have been added to the latest version.

> * Section 3.2 of the CPS states that “All documents and data provided for
> verifying the Server Certificate must not be used by the RA if the document
> or data was obtained 39 or more months prior to the Issuance of the
> Certificate or in the case of EV SSL, 13 months prior to issuance.”. The BRs
> now only allow reuse for up to 825 days.
[IdenTrust:] Updating this was inadvertently omitted in the CPS when the document was updated to  remove future issuance of 3 year SSL certificates. As of April 20, 2018, IdenTrust have not used documents older than 27 months for standards SSL certificates or older than 13 months for EV SSL certificates.
The CPS section 3.2 will be corrected accordingly.

> * CP section 9.8 paragraph 3 appears to violate EVGL section 18’s
> restriction on liability limits for EV certificates by limiting aggregate
> liability. CPS section 9.8 may also contradict both the liability limits in
> the CP and the EVGL requirement.
[IdenTrust:]We will update the CPS to comply with EVGL Section 18 liability limits.  We will publish an updated CPS by October 18, 2018. 
> 
> [1] https://bug1484318.bmoattachments.org/attachment.cgi?id=9006626
> [2]
> https://crt.sh/?caid=1588&opt=cablint,zlint,x509lint&minNotBefore=2014-01-01
> [3]
> https://crt.sh/?caid=47552&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1391000
> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1398255
> [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1446121
With one exception, I was able to confirm that all of my concerns with CPS have been addressed with the new version at https://identrust.com/sites/default/files/resources/IdenTrust_TrustID_CPS_v4.2_20181018.pdf

While the language in section 9.8 has been changed a bit, I don't think the change brings it into compliance with EVGL Section 18 liability limits. Please explain?
Flags: needinfo?(roots)
QA Contact: kwilson
During the public discussion, Nicholas Hatch reported a certificate containing an .INT domain.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1500593
I recommend that this request be denied due to bug #1500593

Public discussion: https://groups.google.com/d/msg/mozilla.dev.security.policy/fTeHAGGTBqg/ikgMfJeiAgAJ
Assignee: wthayer → kwilson
Whiteboard: [ca-in-discussion] - ends after 9-October 2018 → [ca-in-discussion]
(In reply to Wayne Thayer [:wayne] from comment #29)
> With one exception, I was able to confirm that all of my concerns with CPS
> have been addressed with the new version at
> https://identrust.com/sites/default/files/resources/IdenTrust_TrustID_CPS_v4.
> 2_20181018.pdf
> 
> While the language in section 9.8 has been changed a bit, I don't think the
> change brings it into compliance with EVGL Section 18 liability limits.
> Please explain?

Would this adjustment in the CP section 9.8 which is referenced in the CPS, is more suitable with EVGL?
QUOTE
With respect to relying on any single TrustID Extended Validation SSL/TLS Certificate, the maximum aggregate liability for an Issuing CA or RA to any Relying Party or Subscriber will be limited to $2,000 per Subscriber or Relying Party per TrustID Extended Validation SSL/TLS Certificate.
UNQUOTE
Thanks
Flags: needinfo?(roots)
Per Comment #31, I am closing this request to enable EV treatment for the "IdenTrust Commercial Root CA 1" root certificate.

This CA may re-apply for EV treatment for this root or for a new root[1] by creating a new request[2].

[1] https://groups.google.com/d/msg/mozilla.dev.security.policy/fTeHAGGTBqg/NLdaHQSUAgAJ

[2] https://wiki.mozilla.org/CA/Application_Process#Process_Overview
Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → WONTFIX
Whiteboard: [ca-in-discussion] → [ca-denied] Comment #33
You need to log in before you can comment on or make changes to this bug.