TLSv12 Client Certificate Selection Behavior !!

[Viktor Dukhovni]

> On Jun 11, 2019, at 12:15 PM, Michael Wojcik <Michael.Wojcik at microfocus.com> wrote:
> 
>> There's an overarching OpenSSL policy that certificate checks are
>> done exclusively by the relying end (for client certs, that's the
>> server), except when certified end is trying to choose from
>> multiple certificates.
>> 
>> Thus with only one certificate available, the OpenSSL sends the
>> (untrusted, and in this case inappropriate) certificate, just in
>> case the server was somehow configured to make a special exception
>> for this particular case.
> 
> Yes. I for one would argue this existing behavior (i.e. not enforcing every mandate of every applicable standard, at every step of the way) is the Right Thing to do. While it's good that OpenSSL is increasingly providing functionality to make it easier for applications to follow the RFCs and other standards, it's also very important that applications have the flexibility to violate some aspects of those standards. That is critical for interoperability with non-standard peers, as Jakob wrote, and for testing, among other things.

That said, the intention isn't to ignore all the requirements, just
some of those that are not always a good idea to enforce, and perhaps
should never have been mandated in the first place.  Therefore, while
we leave enforcing the certificate signature algorithms to the peer,
enforcing keyUsage in client certificate selection is less obviously
counterproductive, and in fact can (as reported) avoid interop issues.

The OP did not specify which version of OpenSSL did not perform the
expected check.  I'd be open to adding such a check in master and
perhaps even 1.1.1 (as a bug fix).  A client certificate that cannot
do digital signatures is not much use.  On the other hand, applications
should not configure such certificates as client certificates, there
is not context in which they are valid.  So another potential response
is: "if it hurts, don't do that!"

-- 
	Viktor.