While Entrust have not provided details on their incident handling and decision-making as requested in this report, a few details have came to light in a reply to an incident today. This is specifically regarding #1886532 the delayed revocation CPSuri certificates.
https://bugzilla.mozilla.org/show_bug.cgi?id=1886532#c51 I will do this mailing a list a courtesy by not embedding it all, however I feel that similar details not being included for all of these incidents in this report already is troublesome. This comment shows that Entrust has all of this information available, they just did not feel it worth including despite it being asked for. On Friday, June 7, 2024 at 11:42:34 PM UTC+1 Watson Ladd wrote: > Dear Bruce, > > This report is completely unsatisfactory. It starts by presuming that > the problem is 4 incidents. Entrust is always under an obligation to > explain the root causes of incidents and what it is doing to avoid > them as per the CCADB incident report guidelines. That's not the > reason Ben and the community need this report. Rather it's to go > beyond the incident report to draw broader lessons and to say more to > help us judge Entrust's continued ability to stay in the root store. > The report falls short of what was asked for, in a way that makes me > suspect that Entrust is organizationally incapable of reading a > document, understanding it, and ensuring each of the clearly worded > requests is followed. The implications for being a CA are obvious. > > To start Ben specifically asked for an analysis involving the > historical run of issues and a comparison. I don't see that in this > report, at all. The list of incidents only has ones from 2024 listed, > there's no discussion of the two issues specifically listed by Ben in > his email. > > Secondly the remedial actions seem to be largely copy pasted from > incident to incident without a lot of explanation. Saying the > organizational structure will be changed to enhance support, > governance and resourcing really doesn't leave us with a lot of > ability to judge success or explain how the changes made (sparse on > details) will lead to improvements. Similarly process weaknesses are > not really discussed in ways that make clear what happened. How can I > use this report if I was a different CA to examine my organization and > see if I can do better? How can we as a community judge the adequacy > of the remedial actions in this report? > > Section 2.4 I find mystifying. To my mind there's no inherent > connection between a failure to update public information in a place > it appears, a delay in reconfiguring a responder, and a bug in the CRL > generation process beyond the organizational. These are three separate > functions of rather different complexity. If there's a similarity it's > between the latter two issues where there was a failure to notice a > change in requirements that required action, but that's not what the > report says! Why were these three grouped together, and not others? > What's the common failure here that doesn't exist with the other > incidents? > > If this is the best Entrust can do, why should we expect Entrust to be > worthy of inclusion in the future? To be clear, there are CAs that > have come back from profound failures of governance and judgement. But > the first step in that process has been a full and honest accounting > of what their failures have been, in a way that has helped others > understand where the risks are and helps the community understand why > they are trustworthy. > > Sincerely, > Watson Ladd > -- > Astra mortemque praestare gradatim > -- 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/e374c341-8de4-4be3-9e5c-89a8feab1aadn%40mozilla.org.
