TLSv12 Client Certificate Selection Behavior !!

[Jakob Bohm]

On 11/06/2019 19:21, Viktor Dukhovni wrote:
>> 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.
>
Note that the most common variant of encrypt-only RSA client certs
is probably encrypt-only e-mail client certs with other client uses
tacked on.

Such certificates are typically paired with a "same logical
identity" sign-only e-mail/client certificate, with the key
difference being that the encrypt-only-private key is kept around
for a lot longer in order to decrypt stored e-mails that are
(wisely) stored only in their original encrypted form.

In that /specific/ case, attempting to use the encrypt-only cert
as a TLS client cert is typically some kind of logic certificate
selection error, such as a Web client blindly using the locally
stored long-term decryption key instead of the signing key stored
on a removable, but also loosable, smart card, however there may
be company-internal reasons to do so deliberately in order for
background activities to operate when the user (and smartcard) is
"away from terminal".

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded