On Tue, Jan 12, 2016 at 1:07 PM, Fabrice Gautier <fabrice.gaut...@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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
