On Fri, Dec 1, 2017 at 10:23 AM, Hubert Kario <[email protected]> wrote: > > > - Windows and NSS both apply DER-like BER parsers and do not strictly > > reject (Postel's principle, despite Postel-was-wrong) > > NSS did till very recently reject them, OpenSSL 1.0.2 still rejects them > (probably even 1.1.0), are you certain that Windows doesn't reject > certificates with SPKI with RSA-PSS OID? I mean, you _need_ additional > code to > know that the public key for OID rsaEncryption and rsassaPss is formatted > in > one and the same way... If you don't don't have that code, it looks like > completely different key type (think EdDSA or ECDSA for RSA-only > implementation) >
Apologies for again not being very precise here (and now you can see why I also like precision in policy) Both Windows and (as of now) NSS accept RSS-PSS SPKIs, but they apply rather liberal decoders that do not enforce the DER encoding rules - for example, it's valid to supply an explicitly encoded SHA-1 hash, rather than omit it, despite DER rules stating you don't encode the default value. That's why I say they do not strictly reject - they demonstrate the very problem I'm suggesting we avoid (by memcmp()ing), which is that validation is hard and not consistently implemented. > 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? 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. Is that correct? If that is, I'm not sure why a policy of disable-by-default and allow code wanting to experiment with TLS1.3 (knowing it's experimental) from enabling the experimental (but incomplete) PSS support. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
