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
