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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

    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.

Yes. And I concur with him that it is better to omit them, enforcing the default. The default being:
- Hash algorithm the same as specified in Signature Algorithm
- MGF1 hash is the same as above
- Salt length same as digest length above

    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.

Not quite. Since this key is a part of the given certificate – RSA-PSS padding scheme should be used with the same hash as “Signature Algorithm” specifies.

    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).

I think the point Stephen was making is that Signature Algorithm specifies a hash – and there’s no reason to use a different one for MGF1.
    
    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).

This is a different question. The point being addressed here is that each certificate is internally consistent, using the same hash for all the purposes within that certificate.

If the server’s certificate is signed with SHA384, so be it. There’s no reason for a client to not support SHA384 *for signature verification*, as hardware token restrictions shouldn’t apply here – it’s software-based validation.
    
    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.

The cryptographic module would perform RSA-PSS *signature* with whatever hashes it can. It won’t bother with *validation*, so this module’s limitations shouldn’t matter.
    
    So, I'm not sure what hash you are suggesting should be "the same everywhere".

Within one certificate – one hash. I.e., *no* SHA512 in Signature Algorithm, SHA384 for message hash in SHA384-RSA-PKCS-PSS, SHA256 for MGF1.

    I'm quite sure you're not suggesting that we should limit TLS 1.3 to SHA256 
    only (no SHA384 or SHA512), are you?

Oh no – I’m eccentric but not quite insane yet. ;-)