Re: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?

[Mike Jones <[e-mail]>]

Draft 14 uses the parameter names "p2s" and "p2c", as suggested below.

                                                            -- Mike

From: Richard Barnes [mailto:[e-mail]]
Sent: Friday, July 19, 2013 9:56 AM
To: Mike Jones
Cc: Matt Miller (mamille2); [e-mail]<mailto:[e-mail]>
Subject: Re: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?

If we can spare one more octet, how about "salt" and "iter"?  Otherwise, I would be fine keeping "s" and "c", or maybe "p2s" and "p2c" to indicate their use with PBKDF2.

On Thu, Jul 18, 2013 at 2:39 PM, Mike Jones <[e-mail]<mailto:[e-mail]>> wrote:
Wearing my editor's hat, it seems like the direction from the working group is to make the salt and iteration count be explicit header parameter values and to drop the "kty":"PBKDF2".  Any disagreement, or shall I do that in the next drafts?

FYI, I was thinking that I'd use "slt" and "itc" for the parameter names.

                                -- Mike

-----Original Message-----
From: Matt Miller (mamille2) [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, July 16, 2013 6:52 PM
To: Manger, James H
Cc: Richard Barnes; Mike Jones; [e-mail]<mailto:[e-mail]>
Subject: Re: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?

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 < [e-mail]<mailto:[e-mail]> >
Cisco Systems, Inc.

On Jul 16, 2013, at 6:08 PM, "Manger, James H" <[e-mail]<mailto:[e-mail]>>
 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:[e-mail]<mailto:[e-mail]>]
> Sent: Wednesday, 17 July 2013 9:37 AM
> To: Mike Jones
> Cc: Matt Miller (mamille2); Manger, James H; [e-mail]<mailto:[e-mail]>
> 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 <[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>> 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.

_______________________________________________
jose mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/jose