On Tue, Jan 12, 2016 at 3:53 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > On Tue, Jan 12, 2016 at 01:07:16PM -0800, Fabrice Gautier wrote: > >> In practice, what is a common behavior for Servers in the case where >> the client sends an incompatible cert ? Treat it as if there was an >> empty cert or an invalid cert ? Fail the handshake ? > > With TLS 1.0/1.1, in which the server cannot indicate support for > a list signature algorithms, the logical conclusion is that the > client MUST NOT use a public key algorithm that is different from > the agreed cipher-suite. It can accomplish this by only advertising > cipher suites compatible with the client certificate it will (can > be tricky if it has more than one).
> With TLS 1.0/1.1 there is no reason to expect that the server will > understand signatures made with a public key algorithm other than > the one used in the the server certificate (which agrees with the > ciphersuite in the server HELLO). Hum, the client certificate type would theoretically defined by the "certificate_types" list in the CertificateRequest message, not the cipher suite. So you can have RSA client cert with EC ciphersuites and server certs and vice-versa, even in TLS 1.0/1.1 > With TLS 1.2, where the server does send a supported_signature_algorithms > list, clients that use signatures other than those listed should > expect to run into servers that reject this with a fatal alert. > The server's TLS stack (not its X.509 chain verification code) has > to check the signature in the client's "Certifice Verify" message. Which does raise another interesting question when certificate_types and supported_signature_algorithms conflicts. > The server's list of CA's on the other hand is largely a hint, and > clients often just ignore it entirely. If the server can verify > the certificate, it generally does not matter whether the CA was > listed in the certificate request message or not. For many servers > client certificates are optional anyway, or they verify them without > reference to any particular PKI. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
