Added flexibility for RSA PSS salt length

[gilles-peskine-arm]

RSASSA-PSS as specified by RFC 8017 (PKCS#1 v.2.2) §9.1 allows any salt length from 0 to the maximum length that is not occupied by fixed octets or by the hash, i.e 0 to emLen - hLen - 2 where emLen is the modulus length and hLen is the hash length.

Potentially, when signing, an application may want to request any valid salt length. The salt is supposed to be a random octet string of the requested length. When verifying, an application may want to allow any set of valid salt lengths. The salt is contained in the signature and only its length is supposed to be (optionally) validated.

The PSA API supports two PSS mechanisms:

• PSA_ALG_RSA_PSS (since 1.0): enforce a specific salt length which is generally the hash length (see the spec for details).
• PSA_ALG_RSA_PSS_ANY_SALT: identical to PSA_ALG_RSA_PSS when signing, but allows any salt length (i.e. maximally permissive) when verifying.

This leaves some use cases uncovered. In particular:

• For a deterministic signature, you need either an empty salt, or a pseudorandomly generated salt (for which there is no popular standard that I know of). Depending on the scheme, verification may or may not require a specific salt value (it depends if the pseudorandom sequence is based on the private key or only on the public key).

• TPM LIbrary specification 2.0, §11.2.1.2:

  The salt size is always the largest salt value that will fit into the available space.

• (Please add to this list if you know of popular requirements for other PSS salt lengths.)

I'm recording this here so that we have a space to discuss the requirement. At the moment, I am not aware of a PSA API user that needs more than what we have now, although the TPM use case is likely to come up soonish. I'm recording this now from the point of view of Mbed TLS, where we're preparing a new release which will hide the internal interface with flexible salt length selection and only expose the PSA API.