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

Viktor Dukhovni <> Wed, 07 November 2018 15:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A5BBE130DC3 for <>; Wed, 7 Nov 2018 07:44:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y7-Ua6zloMD0 for <>; Wed, 7 Nov 2018 07:44:54 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EBCD71274D0 for <>; Wed, 7 Nov 2018 07:44:53 -0800 (PST)
Received: by (Postfix, from userid 1001) id 1EAC9706DC; Wed, 7 Nov 2018 10:44:53 -0500 (EST)
Date: Wed, 07 Nov 2018 10:44:53 -0500
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <m236seg80v.fsf@localhost.localdomain> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [TLS] Certificate keyUsage enforcement [whose duty, client's or server's?]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Nov 2018 15:44:56 -0000

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:
>       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?