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

["Matt Miller (mamille2)" <[e-mail]>]

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" <[e-mail]> 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" [http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#section-4.1.5]. 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 < [e-mail] >
Cisco Systems, Inc.