On 07/21/2017 09:34 AM, Hubert Kario wrote: > On Friday, 21 July 2017 15:38:32 CEST Benjamin Kaduk wrote: >> On 07/21/2017 08:23 AM, Hubert Kario wrote: >>> Signature Algorithms for ECDSA now define both the curve and the hash >>> >>> algorithm: >>> ecdsa_secp256r1_sha256(0x0403), >>> ecdsa_secp384r1_sha384(0x0503), >>> ecdsa_secp521r1_sha512(0x0603), >>> >>> This is in contrast to the TLS 1.2 protocol, where any hash can be used >>> with any curve. >> I assume you saw >> https://www.ietf.org/mail-archive/web/tls/current/msg23714.html which >> raised a different question in this same general area. >> >> I do not see how the response here cannot be the same as it was there: >> namely, that the current formulation is assumed to have WG consensus, >> having been through two WGLCs; there would need to be rather strong >> reasons to make changes at this stage. > MTI (section 9.1) says only that ecdsa_secp256r1_sha256 is mandatory (MUST) > and no word about any of the other two. > > given that we already have CAs that use P-384 for signatures. I'd say this is > a big conflict between theory and practice. >
I'm afraid I don't understand this remark. There is the caveat to which Ilari alludes, that the server can send whatever chain it has, if the server can't send a chain that complies with the client's signature_algorithms. Since certificate validation is assumed to be largely a function of the PKI library and not really in scope for the TLS spec itself, this is not particularly problematic. The other main usage of the signature_algorithms limits what can be used in CertificateVerify, which is directly relevant to TLS and depends on the key attested to in the certificate. Are you claiming that there are servers that only possess certificates with p384 keys (i.e., no RSA or p256 or other fallback cert)? -Ben
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
