On 18/02/2017 10:01, Martin Thomson wrote: > On 18 February 2017 at 13:31, Dr Stephen Henson > <li...@drh-consultancy.co.uk> wrote: >> could a TLS 1.2 server legally present a certificate containing an >> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client >> present >> a certificate contain an RSASSA-PSS key? > > NSS, when configured to do so, will do just that. I wouldn't > recommend it right now, but it is legal. Actually, if you offer > support for validating PSS and end up negotiating 1.2, then you should > be prepared to receive PSS signatures. It's a wee gotcha in the 1.3 > spec. > >
The reason I wasn't sure about this is that for TLS 1.2 the server certificate key algorithm is associated with a ciphersuite. So for example the "RSA" in TLS_DH_RSA_WITH_AES_256_CBC_SHA256 would previously refer to the OID rsaEncryption (1 2 840 113549 1 1 1) if PSS is included in signature algorithms it could also refer to id-RSASSA-PSS. Similarly for client certificates there is the ClientCertificateType rsa_sign though RFC5246 just says "a certificate containing an RSA key". I'd be curious to know what other implementations do. I suggest we make this possibility clear in the spec, along with the salt length in certificate signatures previously discussed. Otherwise it isn't inconceivable that some will reject id-RSASSA-PSS keys in end entity certificates in TLS 1.2. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shen...@drh-consultancy.co.uk, PGP key: via homepage. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
