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