On Tuesday, September 18, 2018 at 8:53:58 PM UTC-4, Wayne Thayer wrote: > This request is to enable EV treatment for the Identrust Commercial Root CA > 1 as documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1339292 > > * BR Self Assessment is here: > https://bugzilla.mozilla.org/attachment.cgi?id=8964414 > > * Summary of Information Gathered and Verified: > https://bug1339292.bmoattachments.org/attachment.cgi?id=8965525 > > * Root Certificate Download URL: > https://bugzilla.mozilla.org/attachment.cgi?id=8473319 > > CP/CPS: > ** CP: > https://www.identrust.com/sites/default/files/resources/IdenTrust_TrustID_Certificate_Policy_V4.1_08172018.pdf > ** CPS: > https://www.identrust.com/sites/default/files/resources/IdenTrust_TrustID_Certificate_Practices_Statement_V4.1_08172018.pdf > > * This root is already included with Websites and Email trust bits. EV > treatment is requested. > ** EV Policy OID: 2.23.140.1.1 > ** Original inclusion request: > https://bugzilla.mozilla.org/show_bug.cgi?id=1037590 > > * Test Websites: > ** Valid: https://ev-valid.identrustssl.com/ > ** Expired: https://ev-expired.identrustssl.com/ > ** Revoked: https://ev-revoked.identrustssl.com/ > > * CRL URL: http://validation.identrust.com/trustidcaa52.crl > * OCSP URL: http://commercial.ocsp.identrust.com/ > > * Audit: Annual audits are performed by Schellman according to the WebTrust > for CA, BR, and EV audit criteria. > ** WebTrust: https://cert.webtrust.org/ViewSeal?id=2331 > ** BR: https://www.cpacanada.ca/webtrustseal?sealid=2334 > ** EV: https://www.cpacanada.ca/webtrustseal?sealid=2335 > > I’ve reviewed the CPS, BR Self Assessment, and related information for the > Identrust Commercial Root CA 1 EV request that is being tracked in this bug > and have 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.
> * 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. > This begins the 3-week comment period for this request [8]. > > I will greatly appreciate your thoughtful and constructive feedback on the > decision to grant EV treatment to this root certificate. > > - Wayne > > [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 > [7] > https://groups.google.com/d/msg/mozilla.dev.security.policy/RHsIInIjJA0/LKrNi35aAQAJ > [8] https://wiki.mozilla.org/CA/Application_Process _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
