On Mon, Mar 4, 2019 at 3:29 AM Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Writing with my personal hat on: > > > > -----Ursprüngliche Nachricht----- > > Von: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> > Im Auftrag von Matthew Hardeman via dev-security-policy > > On Sun, Mar 3, 2019 at 2:17 PM bxward85--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Insane that this is even being debated. If the floodgates are opened > > > here you will NOT be able to get things back under control. > > > > While I can appreciate the passion of comments such as this, I think > we're still back at a core problem: > > > > How can you reconcile this position with the actual program rules & > guidelines? If they're declined on some discretionary basis, you > > loose the transparency that's made the Mozilla root program so uniquely > valuable. > > > > Other than the relatively minor issues which have already been brought > to light (and presently DarkMatter seems to be contemplating > > the generation of a whole new root and issuing heirarchy to address > those), where are the rules violations that would keep them out? > > If I remember correctly, there was once a fundamental agreement not to > include new TSP's Root CAs if they don't bring structural benefit for the > whole eco system. I can't see, how DarkMatter brings any benefit for the > eco system at all, so I believe there is good reason not to accept this > root inclusion request. > > If this was the standard, far more inclusion requests would be denied. A stronger argument along these lines is that we have plenty of CAs, so there is no good reason to take a risk on one that we lack confidence in. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
