On Friday, 19 May 2017 15:57:18 CEST Gervase Markham wrote: > Brian Smith filed two issues on our Root Store Policy relating to making > specific requirements of the technical content of certificates: > > "Specify allowed PSS parameters" > https://github.com/mozilla/pkipolicy/issues/37 > > "Specify allowed encoding of RSA PKCS#1 1.5 parameters" > https://github.com/mozilla/pkipolicy/issues/38
In general I support them, but I'm afraid that the PSS specification is not detailed enough. I'd say there are 3 different places that the RSA-PSS parameters can be: 1. In the signature (certificate, CRL, S/MIME or CMS, etc.) 2. in the public key info structure of CA certificate 3. in the public key info structure of EE certificate Presence of parameters in 1 is mandatory. Presence of parameters in 2 is recommended (SHOULD in RFC 5756) and optional (MAY in RFC 5756) in 3. Given the interactions between TLS and certificates, I'd say we should suggest _against_ inclusion of them in 3. Thus the valid value would also be "absent". Second possible problem stems from the fact that saltLen is differently interpreted in signature (1) and in public key info (2, 3). In case of signature, it's the literal value. But in case of public key info it's the _minimum_ size of salt allowed. I don't think we gain anything from rejecting bigger salts, they are limited by key size anyway. To oversimplify a bit, we should be lenient for signatures made by end-user software and strict for signatures made by CA software. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
