Re: [TLS] Certificate keyUsage enforcement [whose duty, client's or server's?]

[Viktor Dukhovni <[e-mail]>]

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.