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

On Tue, Jan 12, 2016 at 1:07 PM, Fabrice Gautier <fabrice.gautier@gmail.com>
wrote:

> Hi,
>
> TLS 1.2 RFC says that a a client certificate MUST be compatible the
> parameters specified in the Certificate Request: key type,
> hash/signature algorithm and CA.
> If a client does not have such a compatible cert, it MUST send an
> empty Certificate message.
>
> 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 ?
>
> In practice, is it okay for a client to send a cert that may not be
> compatible with the CertificateRequest, knowing that the client cert
> might be selected by user action, or by an application layer above the
> TLS layer, and knowing that on the server side, the client cert
> verification might also be done a different layer, that may actually
> have a different idea of what an acceptable cert is than the TLS layer
> ?
>

Would a fair rephrase of this be "How many servers advertise some set of
requirements for CertificateRequest that is actually stricter than what they
would accept"? [0]

-Ekr

[0] The case of "I advertise requirements that are looser than I would
accept"
is, I suspect, quite common. For instance, you might advertise an empty
CA list.

> Thanks
>
> -- Fabrice
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>