This request is to include the Entrust Root Certification Authority - G4 as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1480510
* BR Self Assessment is here: https://bug1480510.bmoattachments.org/attachment.cgi?id=8997108 * Summary of Information Gathered and Verified: https://bug1480510.bmoattachments.org/attachment.cgi?id=9016839 * Root Certificate Download URL: https://bug1480510.bmoattachments.org/attachment.cgi?id=8997105 * CP/CPS: https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20190725-version-35.pdf * This request is for Websites and Email trust bits. EV treatment is requested. ** EV Policy OID: .16.840.1.114028.10.1.2 * Test Websites: ** Valid: https://validg4.entrust.net/ ** Expired: https://expiredg4.entrust.net/ ** Revoked: https://revokedg4.entrust.net/ * CRL URL: http://crl.entrust.net/g4ca.crl * OCSP URL: http://ocsp.entrust.net/ * Audit: Annual audits are performed by Deloitte according to the WebTrust for CA, BR, and EV audit criteria. ** WebTrust for CAs and EV: https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=230012 ** BR: https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ecs/2019-entrust-baseline-requirements-report.pdf I’ve reviewed the CPS, BR Self Assessment, and related information for the Entrust Root Certification Authority - G4 inclusion request that is being tracked in this bug and have the following comments: ==Good== * I’m pleased to see the “Other Matters” section of this and last year’s audit reports. * This root was signed in 2015, but there is no evidence that it has been used other than to sign test certificates, and I can find no evidence of misissued certificates chaining to this root. ==Meh== * Entrust has had some compliance issues recorded during the life of this root certificate that are now resolved: ** Metadata in ST and OU fields [1] [2] ** OCSP responding “good” for unknown certificates. [3] ** IP address in dNSName form [4] and [5] ** Late revocation of misissued certificates [6] ** Question marks in certificate O and L fields [7] ** Issued certificates to incorrect organization [8] ** AffirmTrust Issuing CA Impacted by EJBCA Serial Number Issue [9] ** Late revocation of underscore certificates [10] * External RAs are permitted, but the CPS I originally reviewed (version 3.2) did not make it clear that domain validation will not be delegated as required by BR section 1.3.2. Entrust addressed this in the current version. * BR section 2.2 requires section 4.2 of a CA’s CP and/or CPS to “clearly specify the set of Issuer Domain Names that the CA recognises in CAA "issue" or "issuewild" records as permitting it to issue.” The Entrust CPS instead references section 3.2.2.8 where the Issuer Domain Name is listed. * CPS section 9.12.3 is blank. Mozilla recommends against this [11]. ==Bad== * Entrust self-reported a bug in which they had improperly encoded an IP address in a certificate. [4] In March 2018, they indicated in the bug that they would implement pre-issuance linting, but not until early 2019. It was ultimately implemented in May 2019. While pre-issuance linting is not a requirement, it is certainly a best practice and taking over a year to implement it is discouraging. It appears [12] that at least one other misissuance would have been prevented if pre-issuance linting had been implemented sooner. * Entrust’s current and prior [13] BR audit reports contain a qualification for failing to address critical vulnerabilities within 96 hours. Entrust engaged Deloitte to confirm the the problem had been remediated in September 2018. [14] The current period-of-time report confirms that the issue was remediated as of 30-June 2018. * The most recent BR audit report lists two additional qualifications related to the Network Security requirements: ** During the Period, there were instances of some Certificate Systems not undergoing a Vulnerability Scan at least every three (3) months. ** During the Period, there were instances where a technical control to restrict remote access to only those devices owned or controlled by Entrust did not operate effectively. * Entrust has the following open CA compliance bugs (as of 25-June): ** Outdated audit statement for intermediate cert [15] ** Certificate issued with incorrect Country Code [16] ** Certificate issued with validity greater than 825 days [17] ** SHA-1 Issuance and other misissuance while testing [18] * CPS version 3.2 section 9.8.2.2 appeared to limit liability to $1000 USD per Subscriber, but EVGL section 18 sets a minimum of $2000 USD. Entrust addressed this in the current version. This begins the 3-week (minimum) comment period for this request [19]. I will greatly appreciate your thoughtful and constructive feedback on the decision to include this root certificate. - Wayne [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1512018 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1390996 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1428891 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1448986 [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1524876 [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1520876 [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1552562 [8] https://bugzilla.mozilla.org/show_bug.cgi?id=1535735 [9] https://bugzilla.mozilla.org/show_bug.cgi?id=1536287 [10] https://bugzilla.mozilla.org/show_bug.cgi?id=1521520 [11] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647 [12] https://crt.sh/?id=958918578&opt=cablint [13] https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/entrust_baselinerequirements_2018.pdf?la=en [14] https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/2018-specified-procedures-report.pdf [15] https://bugzilla.mozilla.org/show_bug.cgi?id=1549862 [16] https://bugzilla.mozilla.org/show_bug.cgi?id=1559376 [17] https://bugzilla.mozilla.org/show_bug.cgi?id=1561013 [18] https://bugzilla.mozilla.org/show_bug.cgi?id=1567659 [19] https://wiki.mozilla.org/CA/Application_Process _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
