On Tue, Jan 12, 2016 at 1:13 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
>
> 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]

Yes, that's another way to put it.

Other related questions:
"Do TLS libraries act strictly on those requirements, or do they leave
it to the application layers?"
"How do TLS libraries/server applications act when such requirements
are not respected?"


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

Right,
And I guess servers may also advertise empty hash/sig list, and empty
certificate_types list, although that would be violating the RFC.

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

Reply via email to