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

"Matt Miller (mamille2)" <> Tue, 16 July 2013 21:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19B6121F96A8 for <>; Tue, 16 Jul 2013 14:52:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w2pqFi-KFz8j for <>; Tue, 16 Jul 2013 14:52:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A8F6621F91F4 for <>; Tue, 16 Jul 2013 14:52:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=8787; q=dns/txt; s=iport; t=1374011552; x=1375221152; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jnMugwNjHF/HNYKYz6SFgDzMkx9RutouMv+uGLe/jPw=; b=bkprgZKzp2XqG+Yu8srrYHhg/4xl9m91XY+VdxZFIMM1mceeurXIoYVW vl3jG93tfVf3tbfTq4U89uNMUKkwlX5FIz//UqYRAQ8gUYM4sDuis/dsV 8N9cM6EX+/Pd1vf6c0jlQui0qggXIPlkBonSu5gP0jhohf9BANlrYeW8/ A=;
X-Files: smime.p7s : 4136
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.89,679,1367971200"; d="p7s'?scan'208"; a="235662861"
Received: from ([]) by with ESMTP; 16 Jul 2013 21:52:28 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r6GLqSFB003075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 21:52:28 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 16:52:28 -0500
From: "Matt Miller (mamille2)" <>
To: "Manger, James H" <>
Thread-Topic: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?
Thread-Index: Ac6Bwa7E5l6r/DDHRwe+2UU0iYcgFQA1v0SA
Date: Tue, 16 Jul 2013 21:52:27 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_9CD9A4F7-5FC8-41B5-807B-A133C870A224"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Cc: "" <>
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 21:52:40 -0000

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.