On Monday, 24 July 2017 15:09:48 CEST Benjamin Kaduk wrote: > On 07/24/2017 05:49 AM, Hubert Kario wrote: > > On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote: > >> 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 > > I pasted that into https://github.com/tlswg/tls13-spec/issues/1062 but I > don't have high hopes that it won't just get closed with no action. > > >> 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). > > To clarify, you are arguing that P-384 should also be listed as MTI?
no, I'm arguing either for dropping the curve from signature algorithms, or to bind RSA key sizes to hashes too -- 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
