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

Justin Richer <> Thu, 27 May 2021 19:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1DB193A0818 for <>; Thu, 27 May 2021 12:08:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.096
X-Spam-Status: No, score=-4.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W3d1v4NTyWmh for <>; Thu, 27 May 2021 12:08:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC9943A07D4 for <>; Thu, 27 May 2021 12:08:10 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 14RJ842t023359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 May 2021 15:08:05 -0400
From: Justin Richer <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0B94B25D-7871-4688-9628-12EDE13190A5"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Thu, 27 May 2021 15:08:04 -0400
In-Reply-To: <>
Cc: Russ Housley <>, IRTF CFRG <>
To: John Mattsson <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [CFRG] RSA PSS Salt Length for HTTP Message Signatures
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 May 2021 19:08:17 -0000

Thank you for this follow up. When I was just updating my test vector implementation I saw this as another optional parameter alongside the salt length and so I was about to ask if this was important to specify. I see here that it is. :)

I will swing back around to this list once I have a PR on the HTTP document for feedback on the details of the specification text across the different algorithm types.

Thank you all again, this has been very helpful.
 — Justin

> On May 27, 2021, at 1:10 PM, John Mattsson <> wrote:
> Don't forget to specify the mask generation function (MGF). That is another important input. RSA-PSS use two different hash functions that can be different. I have seen implementations of RSA-PSS with SHA2 that only support MGF‐1 with SHA‐1.
> Modern standards like CAB Forum Baseline Requirement, JOSE, and COSE, RFC 8692 require use of the same hash algorith for both. CAB Forum Baseline Requirement calls it:
> "RSASSA‐PSS with SHA‐512, MGF‐1 with SHA‐512, and a salt length of 64 bytes"
> Cheers,
> John
> From: CFRG <> on behalf of Justin Richer <>
> Date: Thursday, 27 May 2021 at 18:14
> To: Russ Housley <>
> Cc: IRTF CFRG <>
> Subject: Re: [CFRG] RSA PSS Salt Length for HTTP Message Signatures
> Thank you! That is clear guidance and we can use that to set a known value since we are fixing the hash size, in this specific case. 
>  — Justin
> On May 26, 2021, at 5:38 PM, Russ Housley < <>> 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.
> Russ
> On May 26, 2021, at 4:45 PM, Justin Richer < <>> 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:
> <>
> 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 <>] with the signer's private signing key (K) and the signature input string (M) (Section 2.5 <>). The hash SHA-512 [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 <>.
> To verify using this algorithm, the verifier applies the RSASSA-PSS-VERIFY ((n, e), M, S) function [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 <>. The hash function SHA-512 [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 <>. 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
> <>
> <>