Re: [lamps] RFC 5480 clarification for KeyUsages: keyEncipherment and dataEncipherment

Jim Schaad <ietf@augustcellars.com> Sun, 24 March 2019 07:49 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F65A127971 for <spasm@ietfa.amsl.com>; Sun, 24 Mar 2019 00:49:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_IeontACaLY for <spasm@ietfa.amsl.com>; Sun, 24 Mar 2019 00:49:19 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABEA612787D for <spasm@ietf.org>; Sun, 24 Mar 2019 00:49:18 -0700 (PDT)
Received: from Jude (62.168.35.67) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 24 Mar 2019 00:49:04 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Russ Housley' <housley@vigilsec.com>, 'Sean Turner' <sean@sn3rd.com>
CC: spasm@ietf.org
References: <74609304-E99C-419F-AE9A-00CFDD825927@sn3rd.com> <61B1FE9F-4647-4AE5-BBB0-703B276E51A0@vigilsec.com>
In-Reply-To: <61B1FE9F-4647-4AE5-BBB0-703B276E51A0@vigilsec.com>
Date: Sun, 24 Mar 2019 08:48:59 +0100
Message-ID: <02b201d4e216$0cdb6610$26923230$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQG5tk+Xjinf0WHcLNIu68NSvCL2qwIn7dcRpj9/UIA=
Content-Language: en-us
X-Originating-IP: [62.168.35.67]
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/32KJmCburr6tWciJHTjfv5piRxI>
Subject: Re: [lamps] RFC 5480 clarification for KeyUsages: keyEncipherment and dataEncipherment
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Mar 2019 07:49:21 -0000


> -----Original Message-----
> From: Spasm <spasm-bounces@ietf.org> On Behalf Of Russ Housley
> Sent: Sunday, March 24, 2019 7:33 AM
> To: Sean Turner <sean@sn3rd.com>
> Cc: spasm@ietf.org
> Subject: Re: [lamps] RFC 5480 clarification for KeyUsages: keyEncipherment
> and dataEncipherment
> 
> Sean:
> >
> > RFC 5480 enumerates the KeyUsage values that are included for an EC key:
> > https://tools.ietf.org/html/rfc5480#section-3
> > But, we neglected to mention keyEncipherment and dataEncipherment.
> Does that mean these values MAY be included, MUST NOT be included, or
> something else?  And, is this worth spinning a short draft to clarify RFC
5480?
> 
> My understanding is that the algorithms in RFC 5480 are key agreement and
> digital signature algorithms, so neither keyEncipherment and
> dataEncipherment are appropriate.  I read it as these bits MUST NOT be
set.

My reading is that if nothing is said, then nothing is said.  I would agree
that these bits make no sense in general, but this is a public key so there
may be an algorithm which uses the EC key and does keyEncipherment.  In this
case it would be appropriate to have them set.  Think of an algorithm
identifier which is KeyAgree+KDF+KeyWrap as a single OID.  These two bits
however were created for algorithms which the IETF has never looked at
using.

Jim

> 
> Russ
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm