Peter, 

I think your code did exactly right. The standard requires honoring KeyUsage..

Maybe if more implementations were diligent with this, the cert zoo we're 
observing would've been less wild...

Regards,
Uri

Sent from my iPhone

> On Nov 7, 2018, at 21:21, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote:
> 
> Viktor Dukhovni <ietf-d...@dukhovni.org> writes:
> 
>>> On Wed, Nov 07, 2018 at 03:48:26PM +0100, Martin Rex wrote:
>>> There is *ZERO* security problem associated with TLS client allowing
>>> a TLS server to do this, but it makes it harder to catch defective
>>> CA software and bogus CA issuing practices when clients do not complain
>>> here
>> 
>> The interoperability issues I'm seeing are with self-signed certificates used
>> in opportunistic TLS and DANE in SMTP.  The CA is some end-user, who "does 
>> not
>> know any better", and the question is how pedantic should the client's TLS
>> stack be in such a case.
> 
> My code, by default, strictly enforces keyUsage [0], so I end up seeing all
> the broken certs out there, and it's complete chaos, (DH) keyAgreement set for
> RSA certs, every possible key usage (includings ones the algorithm isn't
> capable of) set, things like email encryption and SSL server set for CA certs
> (extKeyUsage), keyEncipherment for signing keys, digitalSignature for
> encryption keys, it's the Rule 34 of PKI (if you can think of it, someone's
> put it in an extension).  This includes CA-issued certs, not self-signed ones.
> I think a significant chunk of TLS PKI only works because implementations
> don't strictly enforce keyUsage.
> 
> Peter.
> 
> [0] Which probably wasn't the best default setting.  If you think the public
>    web PKI has broken certs, you should see what turns up in the SCADA 
>    world...
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to