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. > 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. > Obviously, during the introduction of the > Baseline Requirements, this was not the case for any incumbents - and > Mozilla further granted an effective 3 years for incumbents beyond the BRs > effective date to come up to date, while simultaneously examining new CAs > against the modernized criteria. I'm not sure it was that long, and even if it was, I think this criticism is a little harsh given that we have been at the forefront of giving the BRs any teeth at all. Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
