On Thu, Feb 9, 2023 at 1:54 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> On 09/02/2023 10:24, Michael Paquier wrote:
> > It seems so wrong to me that we would just silently disable this
> > feature because RSA-PSS does not give you an algo type to do the
> > computation work. I'll try to look at bit at the OpenSSL code base
> > and see if we could not extract the algo information in this case.
+1. I'm still coming up to speed on RSA-PSS and the conversation at
https://github.com/openssl/openssl/issues/15477
but it makes me really uncomfortable to fail open rather than shut in
this case, as part of a backport.
> > Unfortunately, RFC 5929 is very clear:
> > "if the certificate's signatureAlgorithm uses no hash functions or
> > uses multiple hash functions, then this channel binding type's
> > channel bindings are undefined at this time (updates to is channel
> > binding type may occur to address this issue if it ever arises)."
> >
> > I understand from this sentence that if a certificate has no hash
> > functions, then there's nothing you can do about it.
But we also don't have to proceed as if everything is okay.
> > So as much as I'd like to be aggressive and potentially enforce the
> > use of SHA256 to compute the certificate hash, what you are doing is
> > RFC-compliant.
>
> Yeah, it seems silly to use anything else than SHA-256, given that
> SCRAM-SHA-256 is totally dependent on the security of SHA-256 anyway.
How will this evolve when SCRAM-SHA-512 is implemented? Do you plan to
upgrade the undef-hash in that case to SHA-512?
Knee-jerk reaction: this departure feels unnecessary since Gunnar's
certificate does in fact contain a hash algorithm...
--Jacob
