Further to the latest report making no mention of that incident, in #1890898 there is a statement of intent of there being a second amended final report: https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c66 > Yes, we will amend the final incident report to reflect that we did our analysis
Is there any intent on there being a final report or is this cycle going to continue? If a judgment on Entrust's ability to make concrete statements will be made, there needs to be a final statement at some point. And in regards to your response my statement let us not turn this into an ongoing back-and-forth with individuals. I will only address the last question whereby Entrust will not share how their new team will show any divergence from previous mistakes. The point of asking for an analysis of the 'new team' versus what happened historically is to provide any trust that the same mistakes will not be repeated but with a new badge in place. The lack of confidence in being able to provide that is distressing at this stage. - Wayne On Tuesday, June 25, 2024 at 10:01:47 PM UTC+1 Bruce Morton wrote: > On Friday, June 21, 2024 at 5:17:30 PM UTC-4 Wayne wrote: > > >>Note: During our investigation of this issue, we noted that a subset of > 1,975 EV certificates were also issued without the Entrust EV policy > identifier (OID), based on our interpretation of the ballot update. > >This is also a miscount, presumably due to the original figure being 1963 > + 6 certs on a test site that are being double-counted. > > On reading further in 2.1.1 Entrust have outright stated they still stand > by their incorrect analysis as previously noted in this reply. This speaks > volumes as to the decisions that will occur going forward. Within 2.1.3 > there is a mention of Entrust continuing to issue certificates and advocate > their position, but I am seeing no reflection as to the root cause of what > causes them to advocate for their incorrect positions to this day. Not a > single line of 2.1.4 addresses this either. > > We have clarified our position on this bug > https://bugzilla.mozilla.org/show_bug.cgi?id=1890898#c61. > > > Regarding ACME, I previously stated this question and will repeat it now: > Can you make any guarantees that ACME will be a requirement for subscribers > going forward, and that they will not be charged extra for using these > systems? > > > We are offering ACME free of charge now and are adding support for ARI. > We will increase efforts to educate and promote adoption, but we cannot > guarantee it as not all subscriber environments support ACME. > > > Looking into 4.3 Appendix 3: Success Measures I won't address each > individually. I am curious how you intend to get the WebTrust annual audit > results to result in 0 qualifications in the space of a year. I would > suggest an element for Communication is added to address how often a > question has to be restated or followed up on due to a lack of clarity and > transparency. Otherwise the list presents a minimal standard for any > complying CA, if this is not kept by any CA it would be further cause for > concern. > > > Entrust will have qualifications which have already been reported in our > current incident reports. These qualifications are being addressed and will > be closed in this audit period. Our goal moving forward is to have 0 new > qualifications in our current audit period. > > Once again in evaluating against what was requested I am struck at how the > systemic failures are not being addressed. We have commitments to > committees and boards, but the decisions are what truly matter. There is no > mention of what policies caused these initial issues and how they were not > adhered to. The 2020 commitments are only highlighted due to every comment > noting it specifically, no attempt seems to exist to evaluate against > historical issues. > > On the 2020 commitments I am deeply troubled about this statement in > particular: > "Knowledge of 2020 commitments was similarly confined to a small number of > business unit employees, without broader leadership team/organizational > awareness." > This should have came up in audits which cover incidents on bugzilla. What > happened? Did the auditor only address this with the same small number of > business unit employees and somehow no note of these commitments made it > into any report that went further up the chain? What confidence can we have > in any bugzilla-specific commitments outside of this report going forward? > > > Yes, that is correct. The issues were addressed with a small number of > business unit employees. We have made significant changes (as described in > our response) to ensure that Bugzilla commitments are tracked and met > moving forward through our corporate compliance governance process. It's a > process we use effectively today for other Entrust business units. > > > As a final note I will highlight this section: > "As part of our response process to the Mozilla community, Entrust > assigned a group of three senior leaders, as well as an external > consultant, to review each incident to validate and expand root cause > analysis." > > Can we please have a breakdown on Entrust's end of what their original > opinion was at the start of each incident, and how these personnel would > evaluate the situation if it were to happen today? I sincerely hope that > #1890898 is not an example going forward. > > > Each of these issues had a different set of circumstances, but the common > element was that they all were decided by a small number of business unit > employees without broader cross-functional review and alignment on > requirements and the process for decision making. Moving forward, we will > initiate our incident response process (outlined in our response), to > ensure swift action consistent with CA/B requirements. > > > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/deb1efdc-da3b-430e-a250-99ddab0dceacn%40mozilla.org.
