On Tuesday, 12 September 2017 20:33:21 CEST Blumenthal, Uri - 0553 - MITLL wrote: > > 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,
and I'm saying that such limitation on EE certificate won't help much if you also support hardware tokens as they can limit supported signature schemes too > 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 No problem with that being recommendation, but I've seen people claiming that some applications don't follow that salt length requirement, so I'd say it would cause unnecessary problems if it was set too strict > > 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. this is not a problem we're talking about, I don't have any kind of problem with MGF1 requirement to be the same as the signature hash > > 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. and what you're talking about is a non-issue. Binding MGF1 hash with signature hash is sensible and unlikely to cause problems. > 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. I'm talking about subjectPublicKeyInfo field, *not* about signatureAlgorithm field from RFC 3280 and there are clients that advertise only a subset of hashes: https://www.ssllabs.com/ssltest/viewClient.html? name=Safari&version=6&platform=iOS%206.0.1&key=33 > > 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. but it can't perform that signature using hash *that the client didn't advertise* > > 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. There are four places in which different hashes can be in a certificate: subjectPublicKeyInfo.algorithm.parameters.hashAlgorithm subjectPublicKeyInfo.algorithm.parameters.maskGenAlgorithm signatureAlgorithm.algorithm.parameters.hashAlgorithm signatureAlgorithm.algorithm.parameters.maskGenAlgorithm Now, because the subjectPublicKeyInfo is chosen by the person generating the key (user) and signatureAlgorithm is chosen by the CA, and it is quite common already that e.g. a P-384 CA signs with SHA384 a P-256 intermediate CA that then signs EE with a SHA-256. I really don't think that *all* hashes should be the same. How exactly using more secure parameters for longer lived keys is a bad idea? > > 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. ;-) well, we do work on ASN.1 stuff... ;) -- 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
