Why not just make the changes at the CAB Forum? That's the purpose of the CAB Forum afterall - to discuss these policies. Seems like it would be better to add restrictions there first before creating a separate policy.
-----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Ryan Sleevi Sent: Tuesday, January 24, 2017 10:12 AM To: Richard Barnes <[email protected]> Cc: [email protected]; Gervase Markham <[email protected]> Subject: Re: Appropriate role for lists of algorithms and key sizes I mostly agree with Richard's sentiments - that is, the BRs are likely to be more liberal than what Mozilla may want - but not sure how 0/1 falls out from that. I think 2/3 are implemented the same, just different expressions of 'why' - and I think both reasons are valid. That is, Mozilla may want to discourage some keys because they're weak - OR because they cause interoperability issues. I'm not sure that it's a three-level hierarchy - that is, I don't think you'd want to have a situation where Mozilla Policy != Firefox, if anything, because of interoperability concerns. This means, as a practical matter, I strongly agree with Brian Smith's suggestion of having an explicit, enumerated list of algorithms (and parameters) in the Mozilla policy, with the caveat/expectation that Mozilla policy will be able to be updated in a timely fashion w/r/t this section if need be. On Tue, Jan 24, 2017 at 8:26 AM, Richard Barnes <[email protected]> wrote: > My gut reaction is 0+1, maybe 2. > > - The CAB Forum should specify the overall envelope of what is > acceptable in the Web PKI > - Firefox will enforce restrictions that are mores strict than the BRs > requirements > > If we do (2), then this will just be a three level hierarchy, with BRs > < Mozilla Policy < Firefox. > > > On Tue, Jan 24, 2017 at 10:30 AM, Gervase Markham <[email protected]> > wrote: > > > A discussion inspired by > > https://github.com/mozilla/pkipolicy/issues/5 > > > > Should Mozilla's root store policy contain any list of approved > > and/or disapproved algorithms/key sizes, or not? Possible positions > > include at > > least: > > > > 0) No; what algorithms and/or key sizes are supported by Firefox > > and/or NSS is a decision for the hackers on those projects. There's > > no need for a separate policy about it. > > > > 1) No; the Baseline Requirements, section 6.1.5, specify a set of > > algorithms and key sizes: > > https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf . > > If Mozilla's list is the same, there is no point; if it's different, > > you just end up with the intersection. > > > > 2) Yes; we should have a list of banned algorithms and/or key sizes > > which are weak and therefore dangerous for the web PKI, so we can > > use the power of the policy to force them out of the system. But if > > an algorithm or key size is not actively dangerous, anything else > > should be permitted. > > > > 3) Yes; there are advantages such as interoperability (what else?) > > to Mozilla using the power of the policy to define what algorithms > > and/or key sizes are acceptable in the Web PKI; as long as we keep > > the list under review, this is a good thing. > > > > Thoughts? > > > > Gerv > > _______________________________________________ > > dev-security-policy mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-security-policy > > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
