TLSv12 Client Certificate Selection Behavior !!

[Viktor Dukhovni]

> On Jun 11, 2019, at 1:02 PM, Michael Wojcik <Michael.Wojcik at microfocus.com> wrote:
> 
> And, of course, there are no doubt still people out there running internal CAs that generate X.509v1 certs, which won't have any extensions at all. No KU, no EKU, no SAN, no SKID/AKID ... Presumably a check for proper KU on the client certificate would be bypassed if the client cert is v1 - but then using a v1 certificate is another violation of RFC 5246 (7.4.2) that OpenSSL probably should not enforce.

Yes, v1 certs would get a free ride.  The reason to enforce KU
in client certs would be that client certs are not infrequently
(though not always) optional, and it can be better to not send
any client cert, than to send one the server will reject.

RSA client certs without digital signature in KU are increasingly
not interoperable as more server implementations are checking the
keyUsage these days.  So at some point it makes sense to consider
not offering such (client) certs to the peer server.

But at the end of the day, the user should not have configured
such a client cert in the first place, so it may also make sense
to just leave the responsibility with the user.

-- 
	Viktor.