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

Mike Jones <> Tue, 16 July 2013 23:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 281E121F9D66 for <>; Tue, 16 Jul 2013 16:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.715
X-Spam-Status: No, score=-3.715 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SvqXg1506S8W for <>; Tue, 16 Jul 2013 16:45:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7E4D321F9DDE for <>; Tue, 16 Jul 2013 16:45:47 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.717.3; Tue, 16 Jul 2013 23:30:41 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Tue, 16 Jul 2013 23:30:41 +0000
Received: from ([]) by ([]) with mapi id 14.03.0136.001; Tue, 16 Jul 2013 23:30:36 +0000
From: Mike Jones <>
To: Richard Barnes <>, "Matt Miller (mamille2)" <>
Thread-Topic: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?
Thread-Index: Ac6Bwa7E5l6r/DDHRwe+2UU0iYcgFQA1v0SA///D1wD///0PMA==
Date: Tue, 16 Jul 2013 23:30:35 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436B6C8153TK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704005)(199002)(189002)(24454002)(377454003)(81542001)(15202345003)(74876001)(56776001)(44976005)(551544002)(76482001)(4396001)(74706001)(6806004)(80022001)(66066001)(512954002)(53806001)(74662001)(81342001)(46102001)(63696002)(54316002)(47736001)(50986001)(20776003)(55846006)(79102001)(71186001)(77096001)(74366001)(56816003)(49866001)(47976001)(76786001)(16406001)(77982001)(59766001)(83072001)(16236675002)(65816001)(69226001)(19300405004)(51856001)(74502001)(33656001)(76796001)(47446002)(54356001)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB037;; CLIP:; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 09090B6B69
Cc: "Manger, James H" <>, "" <>
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: Tue, 16 Jul 2013 23:45:55 -0000

If we move "s" and "c" to being header parameters from the JWK, would we still need the JWK with "kty":"PBKDF2"?  All that would be left would be the "hint" JWK parameter.

                                                                -- Mike

From: [] On Behalf Of Richard Barnes
Sent: Tuesday, July 16, 2013 4:17 PM
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<>