On Fri, Nov 8, 2019 at 1:54 PM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> A few more questions have come up about this change: > > * Since mozilla::pkix doesn't currently support the RSA-PSS encodings, why > would we include them in our policy? > They were included for completeness sake, as neither Mozilla Policy nor the BRs presently forbid them. I'm much in favor of not permitting them, but since the current restriction on RSA keys does not restrict the signature algorithms used, we wanted to make sure the combinations were suitable. > * Related: would this detailed enumeration of requirements be better to > place in the BRs than in Mozilla policy? > * In that case it wouldn't cover S/MIME certs > * We'd still need to exclude P-521 in Mozilla policy > * It would end up in audit criteria and perhaps engineers implementing > it would be more likely to be aware of it > * Presumably the RSA-PSS encoding would be included in the BRs and > would then potentially need to be excluded from Mozilla policy > I think the benefits are overstated relative the return and risk. It should be deeply concerning if the BRs were to somehow be seen as taking precedence over Mozilla Policy, or that CAs would ignore Mozilla Policy and only pay attention to the BRs. To accept this argument is to suggest Mozilla Policy is perhaps a less-valuable instrument for communicating policy, at which point, the need for Mozilla Policy may be suspect. While that likely sounds extreme, it carries to the logical conclusion the same concerns we've seen with other elements of Mozilla Policy, such as requirements on Intermediates, which were communicated for years, or in the discussions of EKUs. That said, there are already in-progress efforts to add these to the respective linting tools, which ostensibly brings greater visibility than either audits or the BRs. There's also an element which is that these specifications are themselves already covered by the applicable standards (as previously shared). That is, they are already an intrinsic part of the BRs, and it's precisely because we know that people are not paying attention that the vehicle of root policy becomes useful to *emphasize* and *clarify* the expectations. This does seem an excellent candidate to add to Root Policy - in line with existing and long-standing implementation and expectations - and then potentially fold in as part of a browser root policy alignment effort. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
