To me, it seems that Entrust has forgotten why we are all here. The purpose of the WebPKI is to enable end-users to trust that they are communicating with the correct website. This trust relies on the CAs that make up the WebPKI to be transparent and live up to their promises while adhering to ecosystem norms, requirements, and best practices. Root programs act as the arbitrators of who is worthy of that trust by enforcing these norms, rules, and best practices on behalf of the end-users they serve.
As I review the various incidents at hand, the bugs tracking them, the incident responses, and the associated timelines, a few key elements stand out to me: - Lack of Transparency and Accountability: Entrust’s incident reports and responses lacked transparency and failed to acknowledge where the fault lay. - Failure to Meet Previous Commitments: Despite previous commitments made in 2020 to avoid delayed revocations and adhere to BRs, Entrust continued to face similar issues. - Inadequate Root Cause Analysis: The root cause analyses provided by Entrust were often superficial and did not address systemic failures. - Insufficient Remediation Plans: Entrust's remediation plans were vague, lacking concrete, measurable steps, and often repeated previous commitments without acknowledging how they had previously failed to live up to these commitments. - Lack of Organizational Self-awareness: Entrust's responses indicated a lack of self-awareness about the depth of their issues. They did not show a comprehensive understanding of the systemic problems leading to repeated incidents. - Belief in Exemption from Norms: Entrust has demonstrated through their actions and responses that they believe the norms, policies, and requirements do not equally apply to them. - Slow Response Times: Looking at similar incidents, the timeline associated with Entrust's responses was slow relative to other similar-sized organizations and smaller CAs. In Entrust’s responses to these incidents, they have leaned on their long history in this industry and the impact they have had. In that vein, I can't help but see parallels to the recent Microsoft CSRB review of STORM-0558, where the reviewers said that “Microsoft’s security culture was inadequate and requires an overhaul, particularly in light of the company’s centrality in the technology ecosystem and the level of trust customers place in the company to protect their data and operations.” The immediate technical non-conformities we are discussing here, when looked at in isolation, are not major issues. I even understand why Entrust is hesitant to require their customers, who are largely Enterprise customers who are notoriously hard to deal with on such matters, to replace their certificates as a result of Entrust’s operational non-compliance. However, when we consider them as a body of issues, especially over time, and the way Entrust has responded to them, they reach a significant level. We need to be asking ourselves: is this the kind of behavior we want to establish as the norm for the WebPKI? More broadly, the pattern of non-compliance demonstrated by Entrust, combined with the fact that other, smaller CAs with fewer resources have managed to respond significantly faster and more proactively, makes me ask the question: when we see systemic issues, do we wait until they are catastrophic before we, as the custodians of the WebPKI, respond? In the end, the answers to these questions will need to be provided by the root programs. However, if I were at Entrust, I would have been doing some serious soul-searching over the past quarter about the cultural and organizational issues that led to this point. I would also like to encourage other CAs who are watching this transpire to review their practices and ensure their incident response procedures are transparent, proactive, focused on root cause analysis, and more broadly in line with the expected norms of our community. Ryan Hurst -- 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/91a11d66-afc5-440b-bb83-123a665d66e0n%40mozilla.org.
