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

"Manger, James H" <> Wed, 17 July 2013 00:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B8F3B21F9DA0 for <>; Tue, 16 Jul 2013 17:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TEAHbxqsS0MQ for <>; Tue, 16 Jul 2013 17:31:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AAB6921F9C7A for <>; Tue, 16 Jul 2013 17:31:08 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.89,680,1367935200"; d="scan'208,217"; a="139398114"
Received: from unknown (HELO ([]) by with ESMTP; 17 Jul 2013 10:31:07 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,7138"; a="94119283"
Received: from ([]) by with ESMTP; 17 Jul 2013 10:31:07 +1000
Received: from ([]) by ([]) with mapi; Wed, 17 Jul 2013 10:31:06 +1000
From: "Manger, James H" <>
To: Richard Barnes <>, "Matt Miller (mamille2)" <>, "" <>
Date: Wed, 17 Jul 2013 10:31:05 +1000
Thread-Topic: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?
Thread-Index: Ac6CepoieAU43Iq/Sn2dW9Kvhl6xQgAByrVg
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US, en-AU
Content-Language: en-US
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1151C7C3EB0WSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: Re: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Jul 2013 00:31:14 -0000

“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

From: Richard Barnes []
Sent: Wednesday, 17 July 2013 9:17 AM
To: Matt Miller (mamille2)
Cc: Manger, James H;
Subject: Re: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?

Like James, I don't think -13 (or draft-miller-jose-jwe-protected-jwk) is quite right in how the parameters are laid out.  PBES should be exactly like ECDH -- the parameters for the KEK derivation and key encryption all go in the header.  The JWE header for an ECDH-protected JWE might look like this:


So the example JWE header in draft-miller-jose-jwe-protected-jwk would be:


Similarly, if we were to, say, define an algorithm identifier "PBES2-HS256+A128GCM", the "iv" and "tag" fields would go in the header as well.


On Tue, Jul 16, 2013 at 5:52 PM, Matt Miller (mamille2) <<>> wrote:
I would like to first note that the vast majority of the password-based text came from draft-miller-jose-jwe-protected-jwk (discussed a few times on this list), and was included between the end of the JOSE virtual interim (2013-07-15T17:00Z) and the submission deadline.

On Jul 15, 2013, at 7:13 PM, "Manger, James H" <<>> wrote:

> draft-ietf-jose-json-web-algorithms-13 adds password-based encryption algorithms that involve a salt (s) and iteration count (c). I cannot quite tell how s & c are conveyed. Section 4.9.1 "PBES2-HS256+A128KW" says s & c come from the "applicable PBKDF2 JWK object".
> Is the "applicable PBKDF2 JWK object" the value of the "jwk" header parameter in a JWE message?
> Or is the "applicable PBKDF2 JWK object" part of each parties locally-configured key set (which is not part of a message, but can be referenced by a "kid" header parameter)?
The "applicable PBKDF2 JWK object" is whichever of the key-identifying fields ("jwk", "jku", or "kid") works for your application.  The intent of these algorithms is to protect private- or symmetric-key JWK objects, and to be as self-contained as possible, so the original examples used "jwk".  When this was put together, using JWK objects seemed to make the most sense and fit the syntax and semantics.

> The latter makes little sense as salt and iteration count are parameters of a particular message, not fixed for a given password.
Those are good points, and favor moving "c" and "s" from a JWK into the JWE header (as implicitly proposed elsewhere in this thread).  See above for the original rationale.

> The former is at best underspecified. "jwk" is defined as "the public key to which the JWE was encrypted" []. s & c obviously are not a public key so that definition would need to change.
> A PBKDF2 JWK object is also defined to have a 'hint' parameter ("a descriptive clue to the password"). It would be awful if 'hint's were sent in JOSE messages. JWK needs to do a much better job of separating sensitive fields (secret key, private key, password hint) from public fields. If we need text to display when prompting for a password I think we need a different field to 'hint'.
Do you have suggested changes/replacements.

> An example of PBES2-HS256+A128KW would help.
I'll let Mike Jones speak to this revision specifically.  An example does exist in the original draft-miller-jose-jwe-protected-jwk.

- m&m

Matt Miller <<> >
Cisco Systems, Inc.

jose mailing list<>