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. Perhaps the correct place to *enforce* any keyUsage requirement is in the TLS *server*, which should limit *itself* to the algorithms compatible with the certificate. That would be both more effective, and more interoperable. > -- and the TLS specification says this KeyUsage DigitalSignature > is a MUST for DHE/ECDHE key exchange: > > TLSv1.2: https://tools.ietf.org/html/rfc5246#page-49 > > DHE_RSA RSA public key; the certificate MUST allow the > ECDHE_RSA key to be used for signing (the > digitalSignature bit MUST be set if the key > usage extension is present) with the signature > scheme and hash algorithm that will be employed > in the server key exchange message. > Note: ECDHE_RSA is defined in [TLSECC]. What the RFC does not say is whose duty it is (if anyone's) to *enforce* the restriction. Perhaps clients should not be the ones to do so? -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
