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:

{
  "alg":"ECDH-ES+A128KW",
  "kid":"27a4c46f-6d36-4a8c-814c-c954165f6dc9",
  "epk":{...},
  "apu":"...",
  "apv":"...",
  "enc":"A128CBC+HS256",
  "cty":"application/jwk+json"
}

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

{
  "alg":"PBES2-HS256+A128KW",
  "kid":"27a4c46f-6d36-4a8c-814c-c954165f6dc9",
  "s":"2WCTcJZ1Rvd_CJuJripQ1w",
  "c":4096,
  "enc":"A128CBC+HS256",
  "cty":"application/jwk+json"
}

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.

{
  "alg":"PBES2-HS256+A128KW",
  "kid":"27a4c46f-6d36-4a8c-814c-c954165f6dc9",
  "s":"2WCTcJZ1Rvd_CJuJripQ1w",
  "c":4096,
  "iv":"lyjGhnbbzu6nEx2MkgTl2Q",
  "tag":"S7mmAbr3AeXVbsTP0M3e4w",
  "enc":"A128CBC+HS256",
  "cty":"application/jwk+json"
}

On Tue, Jul 16, 2013 at 5:52 PM, Matt Miller (mamille2)
<mamille2@cisco.com>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" <
> James.H.Manger@team.telstra.com> 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 < mamille2@cisco.com >
> Cisco Systems, Inc.
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>