Re: [CFRG] RSA PSS Salt Length for HTTP Message Signatures

[Benjamin Kaduk <[e-mail]>]

On Thu, May 27, 2021 at 04:15:32PM -0700, Brian Smith wrote:
> Russ Housley <[e-mail]> wrote:
> 
> > RFC 4055 has this recommendation:
> >
> >          The saltLength field is the octet length of the salt.  For a
> >          given hashAlgorithm, the recommended value of saltLength is the
> >          number of octets in the hash value.
> >
> 
> I recommend that you follow the example of TLS 1.3 [1], which is compatible
> with that recommendation in RFC 4055:
> 
>       RSASSA-PSS [RFC8017
> <https://datatracker.ietf.org/doc/html/rfc8017>] with mask generation
> function 1.  The digest
>       used in the mask generation function and the digest being signed
>       are both the corresponding hash algorithm as defined in [SHS
> <https://datatracker.ietf.org/doc/html/rfc8446#ref-SHS>].
>       The length of the Salt MUST be equal to the length of the digest
>       algorithm.  If the public key is carried in an X.509 certificate,
>       it MUST use the RSASSA-PSS OID [RFC5756
> <https://datatracker.ietf.org/doc/html/rfc5756>]. [...] The algorithm
> 
>       parameters MUST be DER encoded.  If the corresponding public key's
> 
>       parameters are present, then the parameters in the signature MUST
> 
>       be identical to those in the public key.
> 
> 
> Some crypto libraries (e.g. mine) only support this exact form of PSS
> signatures, both generating and verifying. I am not sure if the rationale
> for TLS 1.3's strictness is given anywhere, but it underwent significant
> discussion before the above strict form was agreed upon.
> 
> [1] https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3

The sentiment that comes through in the TLS list archives is that PSS has a
lot of parameters and that means places for implementations to mess up if
they're allowed to vary freely.  If you nail down as part of the protocol
that there is only one way to do things, correct (and testable)
implementation is much easier.

-Ben