Re: [jose] 192 bit AES keys

Richard Barnes <rlb@ipv.sx> Fri, 19 July 2013 17:26 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 7BA3511E8147 for <jose@ietfa.amsl.com>; Fri, 19 Jul 2013 10:26:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.064
X-Spam-Level:
X-Spam-Status: No, score=-3.064 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 Md78dEcG7x8H for <jose@ietfa.amsl.com>; Fri, 19 Jul 2013 10:25:46 -0700 (PDT)
Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by ietfa.amsl.com (Postfix) with ESMTP id 98AE611E80FD for <jose@ietf.org>; Fri, 19 Jul 2013 10:25:43 -0700 (PDT)
Received: by mail-ob0-f174.google.com with SMTP id wd20so5672157obb.19 for <jose@ietf.org>; Fri, 19 Jul 2013 10:25:42 -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=UkOOTQi3uHnjHYAeft55RgMS20eUEwJ1sFQ6iLFvtyY=; b=JhpLJ+A4UqR+yLPFFnYNRNchR/8+STrRO47FQ+fgwAKKGYCg3YF15fhf2DWu54OGRg gBgJQUSml+2z3ciu87BFXToDcCJy0tzSrf/xGaLWQ2YtUlmESWMjYkYAysICzKBSnfbK dKS6Z8MJvus4EliYUEkhw5p41HKpSPVIkt1gIT1C3g/2cGlVD3Hv2i2jHHfBQrE3zT2L 6LJNhszenV7sN7+30m+9QxnTWlFkUV4E+qEP8HLyu/bPoiEwRMKdpOFXO45kywYBRL28 6CmqYhLM30IhHW7UihbAgfGuGVxycms7wxoN+g3tvZvHRoIm3wJr0Eu0hr16Je2tpUBh jBWQ==
MIME-Version: 1.0
X-Received: by 10.60.124.228 with SMTP id ml4mr18646682oeb.47.1374254742780; Fri, 19 Jul 2013 10:25:42 -0700 (PDT)
Received: by 10.60.26.135 with HTTP; Fri, 19 Jul 2013 10:25:42 -0700 (PDT)
X-Originating-IP: [192.1.51.54]
In-Reply-To: <CFB27D5A-1EE5-42DC-B873-859FEA94CF48@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>
Date: Fri, 19 Jul 2013 13:25:42 -0400
Message-ID: <CAL02cgR2ruVU-x7vbsNaL8KBVr79Nbg7Je3FkAHrB4N7QV-3ZQ@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary=047d7b3a9286c64fcd04e1e09d4f
X-Gm-Message-State: ALoCoQkNBAVg5yS4h8Qex1VENOqXOGlYQfNpQqRbsphe8Km8f704rI2RXerI8L2KnfZzlysCemV5
Cc: Jim Schaad <ietf@augustcellars.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 17:26:08 -0000

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****
>
>
>