(In a personal capacity, as normally noted but making sure to extra-note it here)
Hi Wayne, It wasn't clear to me from the inclusion request, did Entrust give a reason for the requested addition? For example, do they plan to stop issuing from one of the included roots and have it removed? In general, my thoughts as it applies to any new root inclusion is to ask about the value provided to the community. I think there is exceptional value in retiring roots that may have existed prior to the Baseline Requirements, or which had a significant number of compliance issues. I think a transition to a 'clean' root helps restore confidence and trust in the organization level, by reducing the risk at the certificate-level. Similarly, additions for algorithm agility may also be beneficial to the community, by helping ensure robust and consistent support. It wasn't clear to me if either of these applied. Put differently, will Entrust be retiring one or more of its existing roots in support of adding this new root? I can think of several ways they might be able to do so seamlessly, as demonstrated by other CAs, so it would seem a useful exercise to consider. With respect to the compliance matters, as captured on the bugs, I am concerned, both about the nature of the issues and the detail provided. Comparatively, other CAs have been much more descriptive in their analysis and evaluations, and that's helped restore faith in the organization after an incident has occurred. For example, I've highlighted on other CAs' incidents quality responses like [1], or highly detailed responses like [2]. I note that many of the incidents you've noted don't really rise to that level of detail, and thus some lingering concerns remain. I'm wondering if whether the present root inclusion request provides an opportunity to improve that situation, without discouraging the reporting of incidents. I'm not sure I have something concrete on how to do that right now, but wanted to highlight it for possible consideration and discussion. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1551374 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1556948 On Fri, Jul 26, 2019 at 1:25 PM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
