Re: [TLS] Server behavior when client certificate does not match the request ?

On Tue, Jan 12, 2016 at 3:53 PM, Viktor Dukhovni <ietf-dane@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