On Thu, Jan 18, 2018 at 4:24 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On 17/01/18 15:13, Jonathan Rudenberg wrote: > > I like this concept a lot. Some concrete ideas in this space: > > > > - Limit the validity period of root certificates to a few years, so that > the criteria can be re-evaluated, updated, and re-applied on a rolling > basis. > > Are you saying we should do this for new entrants only? If so, surely > that would give existing CAs a significant competitive advantage? Or, if > not, what is the relevance of your point to the question under > consideration? > 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. 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). 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. This allows for substantial undetectable, unreported misissuance (which, for what it's worth, we have seen in the processing of root inclusion requests) for those that are 'grandfathered' in. If Mozilla was committed to an equitable set of criteria for both incumbents and newcomers, then one natural consequence of this is that all incumbents should be required to rotate their keys to new roots, created under audit criteria acceptable to Mozilla, and to transition issuance to these roots. This is, for what it's worth, notably similar to the consensus proposal regarding Symantec and the Managed Partner Infrastructure, and serves to mitigate a broad swath of risks. So I don't see any argument suggesting it *shouldn't* apply to existing roots - if anything, such a policy requirement would go substantially to both reduce the benefits afforded to incumbents through entropy, and to ensure that Mozilla's users are adequately protected as the emerging security and threat landscape changes. It does not prevent devices which cannot update (as you can cross-certify), but ensures that the security critical, responsibly-developed applications that do update can ensure their users are protected. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
