On Thu, Jan 28, 2021 at 1:32 PM Burton <j...@0.me.uk> wrote: > Hi Ryan, > > The answer to your questions. > > A remediation plan is only useful in cases of slight CA non-compliance to > the rules set forth by the root store policy. > > A remediation plans in cases of slight CA non-compliance provides > assurance of CA commitment to compliance. >
Sure, and I think (and hopefully I'm fairly stating), that the goal is these should be provided in the Incident Reports themselves. That is, the remediation should address both the immediate and systemic issues, and future incidents of the CA will be judged against this. The intent is certainly that anyone in the community participates and reviews these, and I think we see a lot of fantastic activity on the bug reports from people who do, which is a healthy sign, even though they're often calling out concerns with the remediation or highlighting how it fails to meet the expectations. > A CA under investigation of serious non-compliance with detailed > documented evidence of non-compliance incidents has reach the stage of no > return. > > A remediation plan in the cases of serious non-compliance is a reference > document in the case of new root inclusion as documented evidence of > commitment to compliance. > > The CA roots should be removed in the case of serious non-compliance and > asked to reapply for inclusion again to the root store with new roots and > new commitment to compliance with new audits from a different auditor and > reformed practices and management. > Right, and I think this might be premature or giving false hope, at least to CAs that assume every CA, once removed, can simply reapply with a remediation plan. I agree with you, it's incredibly valuable to understand how the CA plans to address the issues, and just like incident reports, it's useful to understand how the CA views the incidents that might lead up to distrust and how it plans to mitigate them before reapplying. Yet we've often seen CAs believe that because a remediation plan exists for the identified issues, it's sufficient to apply for new roots, when really, such CAs are working from a serious trust deficit, and so not only need to remediate the identified issues, but show how they're going above and beyond addressing the systemic issues, in order to justify the risk of trusting them again. Understandably, this depends on a case-by-case basis. To your original point, historically CA actions (generally) worked in three phases: 1) A pattern is believed to exist (of incidents), or an incident is so severe it warrants immediate public discussion. The community is asked to provide details - e.g. of incidents that were overlooked, of other relevant data - to ensure that a full and comprehensive picture of relevant facts are gathered and understood. The CA is invited to share details (e.g. how they mitigated such issues) or to respond to the facts, if they believe they're not accurate. 2) A discussion about the issues themselves, to evaluate the nature of the incidents, as well as solicit proposals from the community in particular (rather than the CA, although the CA is welcome to contribute) about how to mitigate the risks these issues and incidents highlight. 3) At least for Mozilla, a proposed plan for Mozilla products, which is often based on suggestions from the community (in #2) as well as Mozilla's own product and security considerations. Mozilla may solicit further feedback on their plan, from the community and the CA, to make sure they've balanced the concerns and considerations raised in #2 accurately, or may decide it warrants immediate action. This is a rough guide, obviously there are exceptions. For example, Mozilla and other browsers blocking MITM roots hasn't always involved all three stages. Similarly, in CA compromise events, Step 2 and 3 may be skipped entirely, because the only viable solution is obvious. Other programs, whether Apple, Google, or Microsoft, don't necessarily operate the same way. For example, Google, Apple and Microsoft don't provide any statement at all about public engagement, although they may closely monitor the discussions in #1 and #2. Step #1 has, intentionally and by design, largely been replaced by the Incident Reporting requirements incorporated into the Root Policies of both Mozilla and Google Chrome. That is, the incident reports, and the public discussions of the incidents, serve to contemporaneously address issues, identify remediations, and understand and identify how well the CA understands the risks and is able to take meaningful corrective action. These days, Step #1 is merely summarizing the incidents based on the information in the incidents, and thus may not need the same lengthy discussion in the past, prior to the incident disclosure requirements (e.g. StartCom, WoSign). Step #2 is still widely practiced, as we've seen throughout a number of recent and past events. Without wanting to put words into Mozilla's mouth, certainly it's a reflection of the principles of Mozilla's policy. Browsers like Google Chrome, Apple Safari, and Microsoft Edge don't require #2 to happen, although it can often provide valuable insight into their own root programs and evaluation of the CA. Chrome comes the closest, that I'm aware of, of calling this out, at https://g.co/chrome/root-policy, as something they consider (they also consider discussions for inclusion, but that's separate from this discussion) Step #3 is fairly unique to Mozilla. I think you're right for highlighting the community benefits from a timely transition from Step #2 to Step #3, although that's often situational, depending on the nature and complexity of incidents, compatibility risks between browsers, etc. In some cases, Step #3 has called out next steps if the CA wants to pursue "#4) Reapply" - or at least, an absolute minimum set of goals that must be met (rather than a necessary and sufficient set of goals). But that doesn't require an explicit/formal remediation plan - it may be a product decision for Mozilla up-front, or it might be something that's deferred to if/when a CA decides to reapply. This is, at least, historically how things have worked in the time I've been here, but of course, that's always subject to change, and has changed as well throughout the time I've participated (e.g. transitioning #1 to primarily formal incident reporting) It sounds like the main thrust of your suggestion, then, is providing clearer timelines about the transitions to these stages. Is that fair to say? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
