Re: TLSv12 Client Certificate Selection Behavior !!
On 11/06/2019 19:21, Viktor Dukhovni wrote: On Jun 11, 2019, at 1:02 PM, Michael Wojcik 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
Re: TLSv12 Client Certificate Selection Behavior !!
Viktor Dukhovni wrote: > 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. 802.1AR seems to discourage KU in IDevID because at most KU bits make the certificate less useable, and IDevID certificates are expected to live for decades. > 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. I would like knobs for this. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature
Re: TLSv12 Client Certificate Selection Behavior !!
> On Jun 11, 2019, at 1:02 PM, Michael Wojcik > 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.
RE: TLSv12 Client Certificate Selection Behavior !!
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Viktor Dukhovni > Sent: Tuesday, June 11, 2019 10:39 > A client certificate that cannot do digital signatures is not much use. There may be existing applications which use TLS entirely within an organization, where the server does not check KU, and the peers use certificates generated by an internal CA that doesn't set those extensions properly. In that use case, enforcing the KU requirement would break backward compatibility. Maybe that's not worth worrying about; maybe the advantages of enforcing KU on the client certificate at the client end (better diagnostics for the client application, enforce the standard even if the server doesn't) outweigh it. But I don't think it's entirely accurate to say a client certificate with incorrect/missing KU (or EKU, or other extensions) is necessarily useless. To be honest I don't have a strong feeling about this particular suggestion. If OpenSSL started requiring proper KU on client certificates, and that forced some people to fix their internal CA configurations, that's arguably a good thing; such people may well be using too-small keys and outdated algorithms too. Disruption can definitely be good in this area. Just wanted to point out that it might be possible to rely on the existing behavior. 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. -- Michael Wojcik Distinguished Engineer, Micro Focus
Re: TLSv12 Client Certificate Selection Behavior !!
> On Jun 11, 2019, at 12:15 PM, Michael Wojcik > 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.
RE: TLSv12 Client Certificate Selection Behavior !!
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Jakob Bohm via openssl-users > Sent: Tuesday, June 11, 2019 08:19 > > On 11/06/2019 12:50, Hareesh D wrote: > > > > Is this behavior valid and according to RFC ? > > 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. -- Michael Wojcik Distinguished Engineer, Micro Focus
Re: TLSv12 Client Certificate Selection Behavior !!
On 11/06/2019 12:50, Hareesh D wrote: TLSv12 client is sending RSA certificate even when it dont have digitalSignature bit in keyUsage extension. But RFC5246 sectiin-7.4.6 says its MUST condition for client to send RSA certificate with digitalSignature bit set in keyUsage extension. 1. Though server is rejecting such certificates, not sure why client sends such certificates even when there is MUST condition for this point. Should client send empty certificate list instead of sending wrong one? Client has the provision of sensing empty certificate list when it don't have a suitable certificate according to certificate request. 2. And also client is not checking the certificate_types requested in certificate_message and also server not validating if the response is according to the type requested. Consider server requesting only DSA certificate. Client sending RSA certificate and server accepting it. Is this behavior valid and according to RFC ? 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. 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
TLSv12 Client Certificate Selection Behavior !!
TLSv12 client is sending RSA certificate even when it dont have digitalSignature bit in keyUsage extension. But RFC5246 sectiin-7.4.6 says its MUST condition for client to send RSA certificate with digitalSignature bit set in keyUsage extension. 1. Though server is rejecting such certificates, not sure why client sends such certificates even when there is MUST condition for this point. Should client send empty certificate list instead of sending wrong one? Client has the provision of sensing empty certificate list when it don't have a suitable certificate according to certificate request. 2. And also client is not checking the certificate_types requested in certificate_message and also server not validating if the response is according to the type requested. Consider server requesting only DSA certificate. Client sending RSA certificate and server accepting it. Is this behavior valid and according to RFC ?
