Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"

On Tue, Sep 12, 2017 at 8:42 AM, Dr Stephen Henson <
lists@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
>