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

[Justin Richer <[e-mail]>]

On May 28, 2021, at 9:05 AM, Salz, Rich <[e-mail]> wrote:
> 
> Perhaps reconsider PSS.  https://www.metzdowd.com/pipermail/cryptography/2019-November/035449.html is excellent reading.
> 

I appreciate the reference, thank you for that. It’s enlightening, but something to note: We aren’t :just: defining RSA-PSS, we’re also defining a flavor of RSA 1.5, a flavor of HMAC, and a flavor of ECDSA, each with fixed parameters including sizes and curves and the like. Which means that our own version of PSS is going to be a very strict and narrow selection tied to a single identifier, and if there’s enough of a draw from any community to define another set of parameters, it can be registered with a new label. The intent is to have zero variability here, which is why I’m reaching out to this group to help nail some of that down as best we can.

On top of that, the algorithm selection happens up at the application layer here, since this is all on top of HTTP. That means that if the two sides have their own way of figuring out which algorithm and parameters to use and they are configured with those, then they can just do that and it doesn’t affect the spec. There’s no expectation of interoperability or runtime negotiation if you’re doing a point solution like that, but for a lot of developers out there the point solution is safer and we can avoid the JOSE “alg: none” problem as a consequence. There are already communities that have their own underlying crypto systems and key management at the application level and they want to keep using that, and we want them to be able to do that using this spec right out of the box. We’re trying to be very careful in enumerating these requirements and expectations in the spec itself, including being much clearer about algorithm and key resolution strategies.

 — Justin