Re: [jose] 192 bit AES keys
Richard Barnes <rlb@ipv.sx> Fri, 19 July 2013 18:00 UTC
Return-Path: <rlb@ipv.sx>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053BB11E80E3 for <jose@ietfa.amsl.com>; Fri, 19 Jul 2013 11:00:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.058
X-Spam-Level:
X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ACNeJRUfifX for <jose@ietfa.amsl.com>; Fri, 19 Jul 2013 11:00:01 -0700 (PDT)
Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5F521F9929 for <jose@ietf.org>; Fri, 19 Jul 2013 11:00:01 -0700 (PDT)
Received: by mail-oa0-f43.google.com with SMTP id i7so6424369oag.2 for <jose@ietf.org>; Fri, 19 Jul 2013 11:00:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=7KiX5nKbYXf07Ty/bMTi5p0PAvqi5tb/Vd1ZQY7Jaz0=; b=g6dZ4Pt46+LYEAMpyAtjVmnBB0NiqOIIoeuD4f+YFRNRipX6WLmz7qF9uJGkEWOpDV uscMkuRo4lUHirAm/8nZd/y8W/iYjMyNezenthJQXRYB+WuJWI9Mic1mD1/YWFble0I/ FkqAyYvdCF0qo8432ou/WNialBaBx2QWIC60jPafE+/20nUkfIXrMwiWEAx1zvpwpP6m cokQOyReAMoe7cOeyxDALLWRsRyOeJ29rzpFw2hCAGvZCDADDY8XEwvZ4cdE+AXbYTjw r5VeJwf/uhsAi5OYLrXZRtU5ZAoNByW7c94ocpi7/m9Qtr5GJlXBD//lTPnsCyZGF+vY vSIQ==
MIME-Version: 1.0
X-Received: by 10.182.205.138 with SMTP id lg10mr13074403obc.6.1374256800646; Fri, 19 Jul 2013 11:00:00 -0700 (PDT)
Received: by 10.60.26.135 with HTTP; Fri, 19 Jul 2013 11:00:00 -0700 (PDT)
X-Originating-IP: [192.1.51.54]
In-Reply-To: <03a501ce84a9$0450b2a0$0cf217e0$@augustcellars.com>
References: <4E1F6AAD24975D4BA5B16804296739436B6EC698@TK5EX14MBXC284.redmond.corp.microsoft.com> <5CC365A3-7A21-40B3-B5A1-044E4B82D221@ve7jtb.com> <CAL02cgQH5czkGRn2daZh71Jci5oKFBoOfTzOfmHVD-Tah0g-sw@mail.gmail.com> <038401ce84a2$f670a970$e351fc50$@augustcellars.com> <CFB27D5A-1EE5-42DC-B873-859FEA94CF48@ve7jtb.com> <CAL02cgR2ruVU-x7vbsNaL8KBVr79Nbg7Je3FkAHrB4N7QV-3ZQ@mail.gmail.com> <03a501ce84a9$0450b2a0$0cf217e0$@augustcellars.com>
Date: Fri, 19 Jul 2013 14:00:00 -0400
Message-ID: <CAL02cgSdmbvxCsTG=26MRkb5senZM=ovQgjLRvvwp7rxo6vQNg@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Jim Schaad <ietf@augustcellars.com>
Content-Type: multipart/alternative; boundary="001a11c290b86edaef04e1e1180e"
X-Gm-Message-State: ALoCoQlzDpvaGuZUAG/GOQYML4bbk9Z+9OdSm760Sr3la+yMEx5mMHDG5Qki67EodhMnBa/P67If
Cc: John Bradley <ve7jtb@ve7jtb.com>, Mike Jones <Michael.Jones@microsoft.com>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] 192 bit AES keys
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2013 18:00:06 -0000
We could just shift the key length up in to the algorithm identifier, like with the other KDF-based algorithms ("ECDH-ES-128"). Or maybe this argues more for making dkLen explicit. On Fri, Jul 19, 2013 at 1:54 PM, Jim Schaad <ietf@augustcellars.com> wrote: > Richard,**** > > ** ** > > You still need to address the case of using ECDH-ES plus a KDF to get the > CEK directly. I.e. not using a KEK step.**** > > ** ** > > Jim**** > > ** ** > > ** ** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Friday, July 19, 2013 10:26 AM > *To:* John Bradley > *Cc:* Jim Schaad; Mike Jones; jose@ietf.org > > *Subject:* Re: [jose] 192 bit AES keys**** > > ** ** > > I wasn't saying that it should be a separate parameter. It's just not > necessary in a lot of cases. If you have a 16-octet value in > "encrypted_key", then you don't need to specify the key length; you could > just say "AES-GCM", and the implementation would know it was AES-128-GCM > based on the length of the key. Worse, as it is, there can be conflict. > What should an implementation do with "enc":"A128GCM" with a 32-octet > "encrypted_key"? Use the first 16 octets? The last? Reject?**** > > ** ** > > OTOH, for the cases where a KEK is derived, you do need to specify a key > length for the KEK. So you could either do (1) "ECDH-ES+AES-KW" with a > "dkLen" parameter (as in PKCS#5), or (2) "ECDH-ES+A128KW". If I were > designing from clean slate, I would prefer #1, but I can live with #2.**** > > ** ** > > PROPOSAL: Remove key lengths in cases where it's not required ("A*GCM", > "A*KW", "A*GCMKW"), since the length of the key will be clear from the > "encrypted_key" value (or for "dir", from provisioning). Leave them in the > "alg" values, since you need to specify key length there.**** > > ** ** > > PROS: **** > > -- Mitigate combinatorial explosion (don't need one identifier per key > type)**** > > -- Avoid conflict issues**** > > -- Save 3 octets if you don't care about being pretty ("AGCM" instead of > "A128GCM", though I would prefer "AES-GCM") **** > > -- Parallelism with the JWS algorithms (e.g., "HS256"), which don't > specify key length**** > > ** ** > > CONS: **** > > -- Requires existing implementations to support additional algorithm > identifiers (note: doesn't preclude supporting the old algorithm > identifiers!)**** > > ** ** > > ** ** > > ** ** > > ** ** > > On Fri, Jul 19, 2013 at 1:13 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:** > ** > > +1 I don't think taking the length out of the algorithm and making it a > separate parameter is a good way to go.**** > > ** ** > > On 2013-07-19, at 1:11 PM, "Jim Schaad" <ietf@augustcellars.com> wrote:*** > * > > > > **** > > We need to keep key lengths in algorithm ids for the purpose of key > derivation. Additionally there would need to be some way to signal the key > length to the system when doing key generation**** > > **** > > i.e. you would need to change**** > > jose.SetCEKAlgorithm(“AES128”) to**** > > jose.SetCEKAlgoirthm(“AES”, 128)**** > > **** > > jim**** > > **** > > **** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Friday, July 19, 2013 9:47 AM > *To:* John Bradley > *Cc:* Mike Jones; jose@ietf.org > *Subject:* Re: [jose] 192 bit AES keys**** > > **** > > Or we could just remove the key lengths from the algorithm IDs altogether > ;) They really don't add any value.**** > > **** > > On Thu, Jul 18, 2013 at 6:17 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:** > ** > > I am OK with registering the 192 bit versions. > > Sent from my iPhone**** > > > On Jul 18, 2013, at 5:17 PM, Mike Jones <Michael.Jones@microsoft.com> > wrote:**** > > Richard had previously requested that we register algorithm identifiers > for AES using 192 bit keys. As he previously pointed out, “It seems like > if we're going to support AES, then we should support AES. Every AES > library I know of supports all three key lengths, so it's not like there's > extra cost besides the registry entry.” (I’ll note that we already have > algorithm identifiers for the “mid-size” HMAC and signature functions > “HS384”, “RS384”, and “ES384”.)**** > > **** > > I heard no objections at the time. I’m therefore thinking that we should > register algorithm identifiers for these key sizes as well. Specifically, > we would add:**** > > “A192KW”, “ECDH-ES+A192KW”, “A192GCMKW”, “PBES2-HS256+A192KW”, > “A192CBC-HS384”, and “A192GCM”. Support for these algorithms would be > optional.**** > > **** > > What do people think?**** > > **** > > -- Mike**** > > **** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > > ** ** >
- [jose] 192 bit AES keys Mike Jones
- Re: [jose] 192 bit AES keys Matt Miller (mamille2)
- Re: [jose] 192 bit AES keys John Bradley
- Re: [jose] 192 bit AES keys Richard Barnes
- Re: [jose] 192 bit AES keys Jim Schaad
- Re: [jose] 192 bit AES keys Richard Barnes
- Re: [jose] 192 bit AES keys John Bradley
- Re: [jose] 192 bit AES keys Richard Barnes
- Re: [jose] 192 bit AES keys Jim Schaad
- Re: [jose] 192 bit AES keys Richard Barnes
- Re: [jose] 192 bit AES keys Mike Jones
- Re: [jose] 192 bit AES keys Richard Barnes