On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote: > 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.
true; that disjoint between "stuff that TLS library is supposed to do" and "stuff that PKI library is supposed to do" could be spelled out more explicitly in the RFC though > 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)? Yes, there are servers that have P-384 keys. Not sure if they have a dual stack (but that is unlikely as only about 30% of servers with ECDSA certs have also RSA cert). On Friday, 21 July 2017 17:00:55 CEST Ilari Liusvaara wrote: > Actually, P-256+SHA512 is allowed with a caveat, even if the > certificate is not self-signed. And with the same caveat, server can > send a certificate signed with P-256+SHA3-512, despite TLS > codepoint for it having never existed (not many clients can validate it > through). the reverse is true too - if your TLS library supports some combinations, the PKIX library MUST support them -- 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
