Although it was not mentioned in the original bug, it may be worth adding that the certificates in [bug 1867130](https://bugzilla.mozilla.org/show_bug.cgi?id=1867130) were also not revoked within 5 days of discovery. Entrust might've based the start of the 5 day deadline at the time the "Director of compliance confirmed investigation conclusions to support team" at 2023-11-21 15:00 UTC with all certificates being revoked by 2023-11-26 14:50 UTC, but I don't think that's correct if that was the case.
On Friday, May 10th, 2024 at 5:27 PM, 'Ben Wilson' via dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> wrote: > 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](mailto:dev-security-policy%2bunsubscr...@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. -- 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/oSftQDixu-mllVs1CdG_xkziVooOmSyxvLkv_aDPUf5iMx6lVPmnpVSHbft-MBxJNCqO8rwYRUE_TQZXbhNFouSGcMNbkRiunO52OYyph6I%3D%40fozzie.dev.
