Here are draft summaries of the additional historic incidents. I'll be adding these to the Entrust Issues page: https://wiki.mozilla.org/CA/Entrust_Issues
*Invalid data in State/Province Field -* https://bugzilla.mozilla.org/show_bug.cgi?id=1658792 It was initially discovered that Entrust had issued 395 OV SSL certificates to a large international organization with “NA” for the state/province information. Entrust worked on a drop-down list to prevent the error. Certificate revocation would not occur within established timeframes, so Bug #1658794 for delayed revocation was opened. *Late Revocation for Invalid State/Province Issue - * https://bugzilla.mozilla.org/show_bug.cgi?id=1658794 This is the delayed revocation bug related to Bug #1658792, above. Entrust said that when educating large institutions about rapid revocation, factors include who owns a certificate, where it is deployed, and the type of system or application that requires the certificate. It also said that it was advocating automation with such institutions to help speed up certificate replacement and to minimize human error. *EV TLS Certificate incorrect jurisdiction -* https://bugzilla.mozilla.org/show_bug.cgi?id=1802916 Entrust mis-issued 322 EV certificates with the wrong state and locality jurisdiction fields due to complex data entry processes. Entrust implemented a different automated dropdown system for jurisdiction selection. Certificate revocation would not occur within established timeframes, so Bug #1804753 for delayed revocation was opened. *Delayed Revocation for EV TLS Certificate incorrect jurisdiction - * https://bugzilla.mozilla.org/show_bug.cgi?id=1804753 This is the delayed revocation bug related to Bug #1802916, above. Entrust listed 8 Subscribers who were pushing back on immediate certificate revocation and the reasons given (e.g. extensions granted due to end-of-year freezes). Entrust committed to “continue to develop and extend methods for automatic certificate renewal.” *Jurisdiction Locality Wrong in EV Certificate -* https://bugzilla.mozilla.org/show_bug.cgi?id=1867130 Two EV TLS Certificates were mis-issued due to human error in the Jurisdiction Locality field. (The incident revealed 340 additional accounts needing similar updates.) Entrust said it would enhance its linting processes to include possibly using an external service to validate locality data against verified country data. *SHA-256 hash algorithm used with ECC P-384 key - * https://bugzilla.mozilla.org/show_bug.cgi?id=1648472 A Mozilla policy was adopted to require hashing with SHA-384 for an ECC P-384 key. Existing CAs using SHA-256 were not re-configured when Mozilla adopted this policy. This incident revealed a serious gap in taking new requirements and implementing them. Ryan Sleevi noted that linting was just a safety net and not a systemic solution. Entrust was also criticized for the lack of detail in its incident report and its decision to not revoke the certificates. Entrust committed to improving its monitoring and implementation of policy changes to prevent similar incidents. Ryan set forth a number of proactive systemic corrections that Entrust needed to take, rather than taking a reactive stance on matters of non-compliance. Entrust committed to rigorous review of certificate profiles, browser policy revisions, and industry developments. As a final comment, Ryan said, “My big concern is, going forward, we see incident reports from Entrust take a more systemic, holistic response, like Comment #16, to try and cover the scenarios, and to provide sufficient detail about the situation and its failures to understand how those relate. The goal isn't to make CAs wear proverbial sackcloth, it's to try and make sure we're understanding how things go wrong, so that we can effectively collaborate on identifying solutions to avoid that going forward.” *Late Revocation due to SHA-256 hash algorithm - * https://bugzilla.mozilla.org/show_bug.cgi?id=1651481 This bug is related to Bug #1648472. Entrust issued TLS certificates using ECC P-384 keys hashed with SHA-256, contrary to Mozilla policy requiring SHA-384 for hashing. Entrust’s initial decision was to allow certificates to expire naturally without revocation, but this was revised with a decision to revoke all affected certificates. Entrust committed to: filing incident report within one business day for future incidents, filing late revocation incident reports within the required 24 hours or 5 days, as applicable, and advising Subscribers about revocation within 24 hours or 5 days, or provide an explanation if they are unable to meet such timeframes. Entrust was told it needed to align its revocation procedures more closely with the Baseline Requirements and Mozilla’s policy, especially in providing a detailed rationale for any delays in revocation on a per-subscriber basis and ensuring timely revocation in line with the Baseline Requirements. On Thu, May 9, 2024 at 8:13 PM Watson Ladd <watsonbl...@gmail.com> wrote: > Could we add a section for geographical incidents? This is slightly > outside your time window, but I think reading the series here has some > uncanny echos in the ones in your window. > > https://bugzilla.mozilla.org/show_bug.cgi?id=1658792 > https://bugzilla.mozilla.org/show_bug.cgi?id=1658794 > https://bugzilla.mozilla.org/show_bug.cgi?id=1802916 > https://bugzilla.mozilla.org/show_bug.cgi?id=1804753 > https://bugzilla.mozilla.org/show_bug.cgi?id=1867130 > > On Tue, May 7, 2024 at 7:59 AM 'Ben Wilson' via > dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> > wrote: > > > > Dear Mozilla Community, > > > > Over the past couple of months, a substantial number of compliance > incidents have arisen in relation to Entrust. We have summarized these > recent incidents in a dedicated wiki page: > https://wiki.mozilla.org/CA/Entrust_Issues. In brief, these incidents > arose out of certificate mis-issuance due to a misunderstanding of the EV > Guidelines, followed by numerous mistakes in incident handling (including a > deliberate decision to continue mis-issuance), which have been compounded > by a failure to remediate the issues in a timely fashion in line with > well-established norms and root store requirements. > > > > Our preliminary assessment of these incidents is that while they were > relatively minor initially, the poor incident response has substantially > aggravated them and the progress towards full remediation remains > unacceptably slow. This is particularly disappointing in light of previous > incidents in 2020 (#1651481 and #1648472), which arose out of similar > misunderstandings of the requirements, similar poor decision-making in the > initial response, and lengthy remediation periods that fell well below > expectations. Entrust gave commitments in those bugs to address the root > problems through process improvements, and it is concerning to see so > little improvement 4 years later. > > > > In light of these recent incidents, we are requesting that Entrust > produce a detailed report of them. This report should cover in detail: > > > > The factors and root causes that lead to the initial incidents, > highlighting commonalities among the incidents and any systemic failures; > > > > Entrust’s initial incident handling and decision-making in response to > these incidents, including any internal policies or protocols used by > Entrust to guide their response and an evaluation of whether their > decisions and overall response complied with Entrust’s policies, their > practice statement, and the requirements of the Mozilla Root Program; > > > > A detailed timeline of the remediation process and an apportionment of > delays to root causes; and > > > > An evaluation of how these recent issues compare to the historical > issues referenced above and Entrust’s compliance with its previously stated > commitments. > > > > Finally, Entrust’s report should include a detailed proposal on how it > plans to address the root causes of these issues. In light of previous > guarantees given by Entrust in 2020 to ensure speedy remediation in future > incidents, this proposal should include: > > > > Clear and concrete steps that Entrust proposes to take to address the > root causes of these incidents and delayed remediation; > > > > Measurable and objective criteria for Mozilla and the community to > evaluate Entrust’s progress in deploying these solutions; and > > > > A timeline for which Entrust will commit to meeting these criteria. > > > > We strongly recommend that Entrust go beyond their existing commitment > to offer systematic, automated solutions for effective remediation, like > ACME ARI and that it also include clear and measurable targets for the > adoption of these tools by new and existing subscribers. > > > > This report should be submitted to Mozilla dev-security-policy mailing > list for evaluation by the community and Mozilla, who will weigh whether > Entrust’s report presents a credible and effective path towards > re-establishing trust in Entrust’s operation. Submission should be no later > than June 7, 2024. > > > > We thank community members for their engagement on these issues and look > forward to their feedback on Entrust’s report and proposed commitments. > > > > Thanks, > > > > Ben Wilson > > > > Mozilla Root Program > > > > -- > > You received this message because you are subscribed to the Google > Groups "dev-security-policy@mozilla.org" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to dev-security-policy+unsubscr...@mozilla.org. > > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYURqFzRqVmJdc7fBXE1mbGs25HpSkp5wZ0Xm%2BRG0YHCA%40mail.gmail.com > . > > > > -- > Astra mortemque praestare gradatim > -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabu3a3FRyG4C%3DDdXDSAAMbdPVKApACYnE%2Be2tFCsdULSQ%40mail.gmail.com.
