Re: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?

"Manger, James H" <James.H.Manger@team.telstra.com> Wed, 17 July 2013 04:17 UTC

Return-Path: <James.H.Manger@team.telstra.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 3A75B21F842A for <jose@ietfa.amsl.com>; Tue, 16 Jul 2013 21:17:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.915
X-Spam-Level:
X-Spam-Status: No, score=-0.915 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994]
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 pOT1K2+WeLbP for <jose@ietfa.amsl.com>; Tue, 16 Jul 2013 21:17:47 -0700 (PDT)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8C021F868C for <jose@ietf.org>; Tue, 16 Jul 2013 21:17:40 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.89,682,1367935200"; d="scan'208,217"; a="146600084"
Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 17 Jul 2013 14:17:38 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,7138"; a="144151316"
Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipccvi.tcif.telstra.com.au with ESMTP; 17 Jul 2013 14:17:38 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Wed, 17 Jul 2013 14:17:30 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Mike Jones <Michael.Jones@microsoft.com>, Richard Barnes <rlb@ipv.sx>, "Matt Miller (mamille2)" <mamille2@cisco.com>, "jose@ietf.org" <jose@ietf.org>
Date: Wed, 17 Jul 2013 14:17:29 +1000
Thread-Topic: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?
Thread-Index: Ac6Bwa7E5l6r/DDHRwe+2UU0iYcgFQA1v0SA///D1wCAABSpgP///k2w///VMfA=
Message-ID: <255B9BB34FB7D647A506DC292726F6E1151C85C47D@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E1151C7C31BF@WSMSG3153V.srv.dir.telstra.com> <BF7E36B9C495A6468E8EC573603ED941152C0944@xmb-aln-x11.cisco.com> <CAL02cgQF1O67LMivM+tzuAb-6BawPDL1m0mPC7+s=FzN7zrjwg@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1151C7C3EB0@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436B6C867A@TK5EX14MBXC283.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436B6C867A@TK5EX14MBXC283.redmond.corp.microsoft.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1151C85C47DWSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: Re: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?
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: Wed, 17 Jul 2013 04:17:53 -0000

·          “exp” was changed to “xpo” then to “e” due to potential clashes between very different contexts.

·         “iv” was defined (draft-04) for use with some “enc” values, and now is defined for use with some “alg” values instead.

·         “alg”, “enc”, (and “int” and “mac” and “kdf” in drafts) have been required to identify the context for algorithm ids, but there is no corresponding indication of the context for any parameters associated with those algorithm ids (s, c, iv, tag, apv etc).

·         “kid” sometimes identifies the sender’s key and sometimes the recipient’s key, which isn’t going to be pretty when an alg involves keys from both parties (and there are plenty of such algs).

·         A whole bunch of key-related fields that made sense in JWS (referring to the sender’s key) were switched around in JWE (referring to the recipient’s key) were they are almost pointless but can no longer be used if the sender of a JWE does have a key that needs referencing.

·         The sender’s public key can be held in “jwk”, except in a JWE where a new name is needed: “epk”.

A registry has not prevented the mess. Being drafts has allowed us to create & modify the mess so it can still work. ;-(

We have a strange situation today where a fields such as "kid", "x5t", "x5u", and "x5c" are defined for use in a JWK; there is a field in JWE & JWS to hold a JWK; but JWE & JWS also define top-level use of these fields. Are both of the following ok, equivalent, interoperable?

  { "alg":"xxx", "jwk":{"kid":"123", "x5u":"https://x.y.x/"}}

  { "alg":"xxx", "kid":"123", "x5u":"https://x.y.x/"}


--
James Manger

From: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Wednesday, 17 July 2013 10:38 AM
To: Manger, James H; Richard Barnes; Matt Miller (mamille2); jose@ietf.org
Subject: RE: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?

The registry is there exactly to prevent such messes.  They have a good track record of preventing them to date. ;-)

                                                                -- Mike

From: jose-bounces@ietf.org<mailto:jose-bounces@ietf.org> [mailto:jose-bounces@ietf.org] On Behalf Of Manger, James H
Sent: Tuesday, July 16, 2013 5:31 PM
To: Richard Barnes; Matt Miller (mamille2); jose@ietf.org<mailto:jose@ietf.org>
Subject: Re: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?

“s” and “c” at the top level (not under “jwk”) would at least be more consistent with other parts of JOSE and the design philosophy of “keep it flat”. I would actually prefer sticking “s” and “c” into a sub-object, but it only makes sense if other fields are moved there as well. What if a key wrapping algorithm and a content encryption algorithm both need a salt? What if a sender key and recipient key have the same sort of parameter (such as a “kid”)? The “simplicity” of a flat structure quickly becomes a mess.

--
James Manger