“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] 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
