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).
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.
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
