On 11/06/2019 19:21, Viktor Dukhovni wrote:
On Jun 11, 2019, at 1:02 PM, Michael Wojcik <Michael.Wojcik@xxxxxxxxxxxxxx> 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
