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

To add to what Brian and Ben said (listen to their advice), the CA/Browser Forum have also adopted a very narrow profile of PSS if you need further support for this view.

(BTW, I would would change a tiny thing in the TLS text: "the length of the digest algorithm" is generally understood to be the "natural" size of the algorithm's output.  If you look at SHA-2, it's not the block size, which is one measure of the "length" of the digest.  For SHA-2 it's 224, 256, 384, or 512 bits as appropriate.  And with the digest potentially being an XOF, like SHAKE, you have to be careful to avoid saying "output length" as that concept is not always directly applicable to an XOF.)

On Fri, May 28, 2021, at 09:23, Benjamin Kaduk wrote:
> On Thu, May 27, 2021 at 04:15:32PM -0700, Brian Smith wrote:
> > Russ Housley <housley@vigilsec.com> 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
> 
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
> 