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

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.

Russ

> On May 26, 2021, at 4:45 PM, Justin Richer <jricher@mit.edu> wrote:
> 
> Hi everyone,
> 
> I’m one of the editors of the HTTP Message Signatures spec, and I’ve got a question that I was told this list might be a good place to find an answer for. The latest draft of the spec is here if you want to follow along:
> 
> https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html>
> 
> For some background, this spec defines methods for normalizing and signing HTTP messages (both request and response), along with ways to attach the results of that signature to the HTTP message. This is a draft of the HTTP WG. While applications can profile this with any algorithm that can take in the input string and output the byte array signature, we are defining a handful of general-use signature algorithm methods that can be signaled explicitly.
> 
> One of the methods we’re defining uses RSA PSS with SHA512 for a hash. What we’ve discovered in implementation is that it seems like there might be a couple other parameters that also need to be specified, specifically the “salt length”. I had been using one library that defaults this to 20, another library defaults it to (I think?) 32, and another library seems to vary it based on the SHA hash size. Is there a best practice here, or a way to determine what the correct salt length is? I couldn’t find anything in RFC8017 that suggests an appropriate value, so if I’m just missing it please point me to it. 
> 
> The current text from the signatures spec is the following, and I’d plan to just add “the salt length (sLen) value is (XX)” in both the sign and verify sections below:
> 
> To sign using this algorithm, the signer applies the RSASSA-PSS-SIGN (K, M) function [RFC8017 <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html#RFC8017>] with the signer's private signing key (K) and the signature input string (M) (Section 2.5 <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html#create-sig-input>). The hash SHA-512 [RFC6234 <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html#RFC6234>] is applied to the signature input string to create the digest content to which the digital signature is applied. The resulting signed content byte array (S) is the HTTP message signature output used in Section 3.1 <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html#sign>.
> 
> To verify using this algorithm, the verifier applies the RSASSA-PSS-VERIFY ((n, e), M, S) function [RFC8017 <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html#RFC8017>] using the public key portion of the verification key material ((n, e)) and the signature input string (M) re-created as described in Section 3.2 <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html#verify>. The hash function SHA-512 [RFC6234 <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html#RFC6234>] is applied to the signature input string to create the digest content to which the verification function is applied. The verifier extracts the HTTP message signature to be verified (S) as described in Section 3.2 <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html#verify>. The results of the verification function are compared to the http message signature to determine if the signature presented is valid.
> 
> Thank you so much for your help, and please be sure to CC me on replies as I am not subscribed to this list. 
>  — Justin
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg