Added " Although not expressed in the bug, it appears that certificate revocation was delayed as well."
On Fri, May 10, 2024 at 10:54 AM George <geo...@fozzie.dev> wrote: > 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. >> > 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/CA%2B1gtaYodvK9YaYhthgxDUbpo-z%2B8O41mDWhyQygdOPVqbRJ3w%40mail.gmail.com.
