On Fri, Dec 1, 2017 at 11:20 AM, Hubert Kario <hka...@redhat.com> wrote:
> On Friday, 1 December 2017 17:11:56 CET Ryan Sleevi wrote: > > On Fri, Dec 1, 2017 at 10:23 AM, Hubert Kario <hka...@redhat.com> wrote: > > > and fine for NSS too, if that changes don't have to be implemented in > next > > > month or two, but have to be implemented before NSS with final TLS 1.3 > > > version > > > ships > > > > Is there a reason not to disable RSA-PSS support in NSS for certificate > > signatures until that time? > > yes, disabling it without disabling RSA-PSS support in TLS (and thus TLS > 1.3 > in its entirety) is non-trivial and not possible with current code base > > > The argument in favor is that this would be a known-buggy implementation > > (as already demonstrated by the parameter decoder) > > The argument against is that, in addition to rejecting definitely-bad > > certs, it would reject definitely-good certs, and thus would limit the > > ability to test TLS1.3's experimental implementation. > > I don't think NSS does reject good certs, can you provide example of such a > certificate? We both said the same thing :) That is, the reason to not disable / the argument against disabling is it'd disable TLS1.3 - unless someone enabled (RSA-PSS & TLS1.3) That said, considering that TLS 1.3 is not "stable" in NSS (after all, it's still a draft), I'm not sure how unreasonable it would be to say that RSA-PSS should only be enabled if the caller enabled TLS1.3, but given Firefox enabling TLS1.3, the value itself may be minimal-to-negative, since it'd always enable RSA-PSS anyways. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
