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: [email protected] [mailto:[email protected]] On Behalf Of Richard
Barnes
Sent: Tuesday, July 16, 2013 4:17 PM
To: Matt Miller (mamille2)
Cc: Manger, James H; [email protected]
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:
{
"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)
<[email protected]<mailto:[email protected]>> 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"
<[email protected]<mailto:[email protected]>> 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 < [email protected]<mailto:[email protected]> >
Cisco Systems, Inc.
_______________________________________________
jose mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
