On Thu, Jan 18, 2018 at 9:06 AM, Gervase Markham via dev-security-policy < [email protected]> wrote:
> On 18/01/18 13:53, Ryan Sleevi wrote: > > But Gerv, Mozilla's policies already unequally favor the incumbent CAs, > at > > the detriment to both user security and the ecosystem. If your goal is > for > > policies that do not favor incumbents, then it seems a significantly > > different discussion should happen - and proposals such as Jonathan's > > inherently provide a way to normalize that field. > > If Jonathan's proposal were applied to all CAs, it might well reduce > incumbent advantage. But that would be a different discussion from > inclusion criteria. If it were applied only to new CAs, it would be > relevant to the current discussion - but then it would entrench > incumbent advantage. > Or, conversely, that we cannot discuss inclusion policies in isolation from discussion root policies - we cannot simultaneously work to strengthen inclusion without acknowledging the elephant in the room of the extant CAs. > > A prime example, recently highlighted in ongoing CA inclusion > discussions, > > is whether or not a CA must have an unbroken series of audits since their > > key was created (the PITRA). > > Yes. It seems that we have come to the position that it does not > necessarily have to. But I would raise an eyebrow at a root that had > been operating for 10 years and had only got its first set of audits > last week. > Isn't this effectively the VISA situation? When were their first audits - late 2016 / early 2017? This is why it's important to have that discussion - incumbents are already being granted advantages in inclusion policies. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
