On Wednesday, 13 September 2017 16:35:25 CEST Blumenthal, Uri - 0553 - MITLL wrote: > > > 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 > > I’m sure some apps follow, and some don’t. I’m simply saying that it makes > sense for TLS to pick a sensible default (like the above) and stick with > it. Other apps may do what they think is best.
hmm, thing is, that while certificates with subjectPublicKeyInfo of rsa-pss are still pink unicorns in production deployments, certificates with signatureAlgorithm of rsa-pss are fairly common in Microsoft shops - it is the default signature method for MS AD for good few years now. I do not know what hashes, how consistent with MGF1 and what salts sizes do MS CAs select for those signatures. I'm quite sure that people will want to use those existing CA certificates and intermediate CA certificates on new servers that will be deploying TLS 1.3... > As for above, in view of the following discussion I think it would be better > to replace “Signature Algorithm” above with > “subjectPublicKeyInfo.algorithm.parameters.hashAlgorithm”. I still think > that only the necessary minimum of parameters should be passed explicitly. And I would agree, if we didn't have PKCS#11 tokens. If you work on pure- software implementation it will be much easier to have EE that cannot have limitations specified in subjectPublicKeyInfo. But as soon as you have to work with any kind of hardware implementations of RSA, that assumption goes out the window. Because even if your HSM does do all combinations, different one may not. > > 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 > Seriously? iOS 6? Why not iOS 5 or 4? I think I still have an iOS 5 device > somewhere. ;-) my point is that if a client from a major technological company, largely focused on security, can make such decisions, I don't see why other developers couldn't follow the same logic that makes them do what Apple did. > > > 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* > > You’re probably right. But for my benefit, could you please outline the > scenario how this would/could be used? To make sure I completely understand > the use case? The use case may be of a limited client that implements only one hash algorithm and because it's low power, doesn't have a software fallback - allowing SHA256 only, everywhere (both on TLS level and on certificate signature level). That client can then, exactly as the standard prescribes, advertise support only for signature schemes that support sha256: * rsa_pkcs1_sha256 * rsa_pss_sha256 * ecdsa_secp256r1_sha256 Server side can be limited by policy, to have just sha384 signing in rsa with big key sizes (e.g. because some part of the web site is considered 'Top secret' and need to use keys more resistant to quantum computers) but also have P-256 ECDSA certificate for the public part of the web site as a fallback. That server policy can be encoded in the subjectPublicKeyInfo. In such situation we want the server to sign Certificate Verify with the ECDSA key - ecdsa_secp256r1_sha256 - even if the client advertises preference for RSA and server wants to respect it. Situation with two RSA keys with different limitations is not much different. We still want to pick a certificate that can be used to make a signature that client claims it will be able to verify - rsa_pss_sha256. -- 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
