Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"

[Hubert Kario <[e-mail]>]

On Tuesday, 12 September 2017 19:36:04 CEST Blumenthal, Uri - 0553 - MITLL 
wrote:
> >  > . . .
> >   > 
> >     > This could get pretty messy: it requires a logic not used in any
> >     > other
> >     > algorithm. I'd be more than happy to have an outright prohibition on
> >     > EE PSS
> >     > key parameter restrictions in TLS 1.3 so implementers don't have to
> >     > bother
> >     > with this.
> > what about hardware tokens that support only specific hashes or
> > signatures? (I've seen ones that can do only RSA with SHA256 and SHA-1,
> > but
> > not SHA-384 or SHA-512) Isn't it basically the same code path (though the
> > limitation does come from slightly different place).
> 
> I think that the requirement of having the same hash everywhere in this
> certificate takes care of this problem.
> 
> If I’m missing the actual problem you’re pointing at – please outline the
> use case where it might manifest, and let’s take it from there.

What Stephen is pointing at, is a server certificate (End Entity certificate) 
when using RSA-PSS public key id in the X.509 certificate can have RSA-PSS 
parameters in the public key id or can have them omitted. When the parameters 
are omitted, it means that that key can be used for signing with any hash 
(SHA-1, SHA-256, SHA-384, SHA3-256, etc.) but must be used with rsa-pss 
padding scheme. When the parameters are present the hash is set in stone and 
that key can then be used to sign with one hash and one hash only - the hash 
that is specified in certificate (and rsa-pss padding).

Now, if the certificate specifies in parameters SHA384 hash and client 
advertises support only for SHA256 with RSA-PSS, the server should switch to 
(e.g.) ECDSA certificate that does not have that limitation and continue 
connection instead of aborting the connection (very bad) or sending 
certificate which most likely will be rejected by client as not 
understandable/unverifiable (bad).

What I've added is that that limitation may not come from the certificate but 
may come from the cryptographic module (software or hardware) that implements 
rsa-pss with just one or two hashes, irrespective of rsa-pss parameters in the 
certificate public key id.

So, I'm not sure what hash you are suggesting should be "the same everywhere".
I'm quite sure you're not suggesting that we should limit TLS 1.3 to SHA256 
only (no SHA384 or SHA512), are you?
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic