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
