Hi Ryan, I included the remediation plan in the proposal because a CA will mostly always include a remediation plan when they reach the stage of serious non-compliance investigation by root store policy owners. The first remediation plan is always a draft version as it's updated as the discussion is ongoing. Take the recent discussion for example, the remediation plan is version 5 which seems to be the final version.
New evidence does sometimes appear in public discussions about the CA that wasn't found or documented earlier and I included that in the proposal as requests for additional information. I do agree that CAs who reach the stage of non-compliance investigation should submit new roots. Thank you Burton On Wed, Jan 27, 2021 at 6:58 PM Ryan Sleevi <r...@sleevi.com> wrote: > > > 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
