Re: [jose] 192 bit AES keys

"Jim Schaad" <ietf@augustcellars.com> Fri, 19 July 2013 17:55 UTC

Return-Path: <ietf@augustcellars.com>
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 58C2111E8171 for <jose@ietfa.amsl.com>; Fri, 19 Jul 2013 10:55:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.606
X-Spam-Level:
X-Spam-Status: No, score=-3.606 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, 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 eL5xcy2nJ548 for <jose@ietfa.amsl.com>; Fri, 19 Jul 2013 10:55:37 -0700 (PDT)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA1921E80DC for <jose@ietf.org>; Fri, 19 Jul 2013 10:55:32 -0700 (PDT)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id AA62538EF0; Fri, 19 Jul 2013 10:55:31 -0700 (PDT)
From: "Jim Schaad" <ietf@augustcellars.com>
To: "'Richard Barnes'" <rlb@ipv.sx>, "'John Bradley'" <ve7jtb@ve7jtb.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>
In-Reply-To: <CAL02cgR2ruVU-x7vbsNaL8KBVr79Nbg7Je3FkAHrB4N7QV-3ZQ@mail.gmail.com>
Date: Fri, 19 Jul 2013 10:54:29 -0700
Message-ID: <03a501ce84a9$0450b2a0$0cf217e0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_03A6_01CE846E.57F3AF60"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIfgk181M5vviS9HDl2ID68i5g8cgIZJIk+ApF2kPUAuHq+gwHYZ9cCA0paEymYdh6AMA==
Content-Language: en-us
Cc: 'Mike Jones' <Michael.Jones@microsoft.com>, 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 17:55:42 -0000

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 < <mailto:ve7jtb@ve7jtb.com>
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 <
<mailto:Michael.Jones@microsoft.com> 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
 <mailto:jose@ietf.org> jose@ietf.org
 <https://www.ietf.org/mailman/listinfo/jose>
https://www.ietf.org/mailman/listinfo/jose


_______________________________________________
jose mailing list
 <mailto:jose@ietf.org> jose@ietf.org
 <https://www.ietf.org/mailman/listinfo/jose>
https://www.ietf.org/mailman/listinfo/jose