Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8) (Martin Rex) Wed, 07 November 2018 14:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C37B130DD1 for <>; Wed, 7 Nov 2018 06:48:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uXP05Fw1xIhF for <>; Wed, 7 Nov 2018 06:48:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D0FA7130DCA for <>; Wed, 7 Nov 2018 06:48:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 42qq6L5xkfz10QP; Wed, 7 Nov 2018 15:48:26 +0100 (CET)
X-purgate-ID: 152705::1541602106-00000213-34309069/0/0
X-purgate-size: 2094
X-purgate: clean
X-purgate: This mail is considered clean (visit for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R)
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ( []) by (Postfix) with ESMTP id 42qq6L1HfPzGqL6; Wed, 7 Nov 2018 15:48:26 +0100 (CET)
Received: by (Postfix, from userid 10159) id 207DC404C; Wed, 7 Nov 2018 15:48:26 +0100 (CET)
In-Reply-To: <m236seg80v.fsf@localhost.localdomain>
References: <> <m236seg80v.fsf@localhost.localdomain>
To: Geoffrey Keating <>
Date: Wed, 07 Nov 2018 15:48:26 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
Archived-At: <>
Subject: Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)
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 14:48:31 -0000

Geoffrey Keating <> wrote:
> Viktor Dukhovni <> writes:
>> TL;DR:  Should TLS client abort DHE-RSA handshakes with a peer
>> certificate that *only* lists:
>>             X509v3 Key Usage: 
>>                 Key Encipherment, Data Encipherment
> Yes, because in DHE-RSA, the RSA key is used for signing, and this is
> an encryption-only key.

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 -- and the TLS specification says this KeyUsage DigitalSignature
is a MUST for DHE/ECDHE key exchange:


      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].


CAs and CA software that issues certificates as TLS server certificates
(i.e. with ExtKeyUsage  id-kp-serverAuth, id-kp-clientAuth or both) and
forgets to assert DigitalSignature, prove their own royal brokenness.

Using an RSA key for PKCS#1 v1.5 signatures is *NO* security problem.

Do not get confused by the FUD and snake-oil that resulted in the
needless additional complexity of RSA-PSS in TLSv1.3, that adds ZERO
security value.

There is some security risk with using an RSA signing-only key
for PKCS#1 v1.5 encryption, i.e. the equivalent of
using a keyUsage without keyEncipherment for static-RSA key exchange