I think the basic concept is fine, but I would rather not add any more human-facing fields. It has too much potential to open the Pandora's box that is localization and internationalization. Hint is something one human enters directly (I assume), so said human could communicate it to other humans.
I do understand your concerns with "password" (or "pwd" to continue our exuberant use of three-letter fields), but that seems like a more general issue to discuss. - m&m Matt Miller < [email protected] > Cisco Systems, Inc. On Jul 16, 2013, at 6:08 PM, "Manger, James H" <[email protected]> wrote: > "kty":"PBKDF2" feels unnecessary, though "kty":"password" would be useful. A > key set could have an entry like the following: > > { > "kty":"password", > "alg":" PBES2-HS256+A128KW", > "c-min":2000, > "prompt":"Payment approval PIN", > "hint":"last 4 digits of \u03C0" > } > > The entry could also have a "password" field holding the actual password. > Mind you, I think mixing public (eg kty, alg) and sensitive (eg hint, > password) fields side-by-side in a JSON object is a design guaranteed to lead > to security breaches from poor handling. > > -- > James Manger > > From: Richard Barnes [mailto:[email protected]] > Sent: Wednesday, 17 July 2013 9:37 AM > To: Mike Jones > Cc: Matt Miller (mamille2); Manger, James H; [email protected] > Subject: Re: [jose] PBES2-HS256+A128KW: where do salt and iteration count go? > > I was thinking that the "jwk" would be unnecessary. We could have "hint" at > the top level, or just use "kid" for that purpose. > > --Richard > > On Tue, Jul 16, 2013 at 7:30 PM, Mike Jones > <[email protected]<mailto:[email protected]>> wrote: > 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
