The registry is there exactly to prevent such messes. They have a good track
record of preventing them to date. ;-)
-- Mike
From: [email protected] [mailto:[email protected]] On Behalf Of Manger,
James H
Sent: Tuesday, July 16, 2013 5:31 PM
To: Richard Barnes; Matt Miller (mamille2); [email protected]
Subject: Re: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?
“s” and “c” at the top level (not under “jwk”) would at least be more
consistent with other parts of JOSE and the design philosophy of “keep it
flat”. I would actually prefer sticking “s” and “c” into a sub-object, but it
only makes sense if other fields are moved there as well. What if a key
wrapping algorithm and a content encryption algorithm both need a salt? What if
a sender key and recipient key have the same sort of parameter (such as a
“kid”)? The “simplicity” of a flat structure quickly becomes a mess.
--
James Manger
From: Richard Barnes [mailto:[email protected]]
Sent: Wednesday, 17 July 2013 9:17 AM
To: Matt Miller (mamille2)
Cc: Manger, James H; [email protected]<mailto:[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
