On Wednesday, 22 November 2017 13:15:58 CET Peter Wu wrote: > Hi Nikos, > > On Wed, Nov 22, 2017 at 09:42:04AM +0100, Nikos Mavrogiannopoulos wrote: > > On Wed, 2017-11-22 at 03:54 +0000, Peter Wu wrote: > > > Hi, > > > > > > At the moment there is still ambiguity in the requirements for PSS > > > with > > > relation to certificates. Proposal to clarify this: > > > https://github.com/tlswg/tls13-spec/pull/1098 > > > > > > > > > This PR intends to clarify the requirements for PSS support. > > > > Hi, > > > > I commented on the PR, but to provide more context. I believe RSA-PSS > > > > keys without parameters MUST be supported under TLS1.3. The reason is > > that keys explicitly marked as RSA-PSS cannot be used for RSA PKCS#1 > > 1.5 encryption, and thus they provide a way for the server to know that > > it must protect that key against (cross-protocol) attacks which utilize > > RSA ciphersuites under TLS1.2. > > > > On why you don't want mixing keys for TLS1.3 and TLS1.2 RSA > > ciphersuites, see all the bleichenbacher attack reiterations over the > > years. > > > > So what about distinguishing the RSA-PSS keys with and without > > parameters: > > > > "an RSASSA-PSS public key (OID id-RSASSA-PSS) without parameters MUST > > be supported, while an RSASSA-PSS public key (OID id-RSASSA-PSS) with > > parameters MAY be supported`." > > In my understanding, the parameters are REQUIRED (cannot be NULL), but > an "empty" DER encoding means that the default parameters are used > (SHA-1, MFG1 with SHA-1, salt length equal to SHA-1 output (20), default > trailer) per https://tools.ietf.org/html/rfc8017#page-75
No, when the parameters are completely omitted (the AlgorithmIdentifier.parameters is completely omitted in the SEQUENCE of AlgorithmIdentifier), that means that the key is unrestricted and can be used with arbitrary hashes and salt lengths (just like a rsaEncryption key). If the AlgorithmIdentifier.parameters is present but empty (empty SEQUENCE in DER), that means that all parameters are restricted and have default parameters (sha1, 20 byte salt). RFC 5756 is a bit more explicit on requirements for EE and CA certificates: When the id-RSASSA-PSS object identifier appears in the TBSCertificate subjectPublicKeyInfo algorithm field of CA certificates, then the parameters field SHOULD include the RSASSA- PSS-params structure. When the id-RSASSA-PSS object identifier appears in the TBSCertificate subjectPublicKeyInfo algorithm field of EE certificates, then the parameters field MAY include the RSASSA- PSS-params structure. The unrestricted EE keys should be supported, and I would even go as far as specifying that in TLS1.3 RSA-PSS EE certs MUST be unrestricted. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
