On Tue, Sep 12, 2017 at 8:42 AM, Dr Stephen Henson < li...@drh-consultancy.co.uk> wrote:
> On 12/09/2017 15:10, Nikos Mavrogiannopoulos wrote: > > > > That is, because a TLS server would typically sign with whatever > > algorithm the client supports and would very rarely be interested to > > utilize the security advantages of including the parameters (which, > > advantages, are quite unclear even to a crypto expert). Otherwise, a > > certificate restricted to SHA-384 and 48-bytes of salt, will not be > > able to serve a client which only supports RSASSA-PSS with SHA-256. > > > > As such, it would make sense for TLS 1.3 to recommend no parameters for > > such RSASSA-PSS certificates, to ease their deployment. > > > > Well restrictions in CA keys would be handled by the PKI verifier: if > there is a > violation the chain should be rejected and it's a problem with the chain > itself > and an error by the CA that issued it. A different case is where the > restrictions are legal from a PKIX standpoint but not allowed by TLS 1.3, > though > again it's a CA error issuing such a chain for TLS 1.3 use. > > A restriction on the EE key isn't quite the same. There are two cases. > > One is that the parameters are not permitted by TLS 1.3 at all (e.g. MGF1 > digest > doesn't match signing digest or minimum salt length exceeds digest > length). In > this case a server should never present the chain or if it does a client > would > justifiably reject it and abort the handshake. Again this is an error by > the > issuing authority which should be corrected. > > The second case is that the parameter restriction is permitted by TLS 1.3 > and > this limits the digest which the key can sign with. Say the restriction is > SHA384 and the client only supports rsa_pss_sha256. The server might then > use to > a different PSS key (and certificate chain) that supports rsa_pss_sha256 > or fall > back to an RSA key to use rsa_pss_sha256. Again if a client sees a TLS > message > signed with parameters that violate the restrictions it could (with some > justification) abort the handshake. > > This could get pretty messy: it requires a logic not used in any other > algorithm. I'd be more than happy to have an outright prohibition on EE > PSS key > parameter restrictions in TLS 1.3 so implementers don't have to bother > with this. This sounds plausible to me. Would you be willing to send a PR? -Ekr > > Steve. > -- > Dr Stephen N. Henson. > Founder member of the OpenSSL project: http://www.openssl.org/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
