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/CACsn0ckZYa-Ycz0XFMpJNp7ECih5Ghy_3wbDC_H26CQLW3Asyw%40mail.gmail.com.
