On Wed, Jan 27, 2021 at 10:11 AM Burton <j...@0.me.uk> wrote: > Hello, > > The Mozilla root store policy should include a section that sets out time > limit periods in numbered stages for non-compliance CA discussions. That > way everything is fair, can't be disputed and everyone knows when the > discussion of the non-compliance CA will conclude. Then the decision from > the root store policy owners will proceed shortly afterwards to either > accept the remediation plan from the CA or proceed with the partial or > complete removal of the CA from the root store. > > These time limits below should be enough ample time for the discussion to > take place between the CA, the community and the root store policy owners. > > Stage 1 (Discussion Period: *1 Week*): > > - Official notification to all that an investigation regarding the > non-compliance issues of the CA has started. > - Requests for additional information, etc. > > Stage 2 (Discussion Period: *4 Weeks*): > > - The CA to produces a draft remediation plan. > - The CA answers all questions from the root store policy owners and > the community. > - Requests for additional information, etc. > > Stage 3 (Discussion Period: *2 Weeks*): > > - Discussion of the final remediation plan proposed by the CA. > - Discussion of whether to partial distrust or full distrust of the > CA. > - Requests for anymore additional information. > > The decision by the root store policy owners. >
>From a proposal standpoint, could you explain a bit more about the goals of a "draft remediation plan"? The point and purpose of Incident Reports is so that CAs are continuously improving, and adopting meaningful improvements and remediations. At the point at which a CA is being discussed, isn't that already evidence alone that the CA's failure to remediate not just the incidents, but the systemic root issues, has failed? Recent replies such as https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg14089.html and https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg14090.html have captured how, given the nature of how PKI works, the only viable remediation plans are those that transition to new roots. This is something that, for example, Google Chrome explicitly recommends and encourages, at https://g.co/chrome/root-policy , as a way of minimizing the risk to their users. Without expressing opinions on the current, ongoing discussion for Mozilla, it may be useful to examine past CA incidents, as it seems that there were several remediation plans posed by CAs in the past, yet consistently, every single one of them failed to adequately address the very core issues, and every one of them revealed actions the CA was already expected to be taking, either in light of incidents or as part of the bare minimum expectation of CAs. I mention all of this because your emphasis on remediation plan does seem to suggest you see there being viable paths forward, other than (at a minimum), a transition from problematic roots to new roots, so I was hoping you could expand, using perhaps past CA discussions rather than the current one, as they provide ample evidence of problematic patterns. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
