+1
It's apparent from the current format whether an asymmetric key is public or
private. Adding another element just causes extra checks on the format.
________________________________
From: Justin Richer <[email protected]>
To: Mike Jones <[email protected]>
Cc: "[email protected]" <[email protected]>
Sent: Wednesday, August 28, 2013 12:53 PM
Subject: Re: [jose] FOR WG DISCUSSION: #82 part A - Possibly changing
representation of private JWK fields
If the leak is going to happen, it's not going to be on part of the JWK object
or JWK set, it's going to be on the whole thing. Stuffing it into a sub-object
isn't going to make it any safer in practice. If you want to generate a public
key from a public/private pair, you could argue that it'd be simpler to have an
outbound thing filter out just the ".private" sub-object as opposed to having
something key-specific, but I think the latter is actually more robust against
different key types since it enforces a per-type evaluation of what's "public"
and what's "private".
I agree with Mike's contention regarding symmetric keys, below -- it's tricky
though. In the Nimbus-JOSE-JWT implementation of JWK we've taken the approach
of saying that the "public" version of an OctetSequenceKey is null.
Parallelism on the keying material overall is a good thing though, so I'd
prefer to leave it how it is.
-- Justin
On 08/28/2013 03:40 PM, Mike Jones wrote:
> This is a second issue in the issue tracker that I wanted to bring to the
> working group’s attention for discussion. My personal view is stated in the
> issue tracker comment below.
>
> -- Mike
>
> -----Original Message-----
> From: jose issue tracker [mailto:[email protected]]
> Sent: Wednesday, August 28, 2013 12:36 PM
> To: [email protected]; Mike Jones
> Cc: [email protected]
> Subject: Re: [jose] #82: Section 6. Encrypted JWK and Encrypted JWK Set Format
>
> #82: Section 6. Encrypted JWK and Encrypted JWK Set Format
>
> Comment (by [email protected]):
>
> This comment is about part A of this issue - the suggestion that private key
> material within a JWK be moved into a "private" element. While I understand
> the motivation for the suggestion, this doesn't seem like a necessary or
> particularly useful change. If an implementation leaks its private or shared
> key information by disclosing a JWK containing it to a party not entitled to
> have it, there's no security difference in whether that information is in a
> top-level member or a member of a "private" field. The information will have
> still been inappropriately disclosed.
>
> This suggestion is also ambiguously specified. While yes, the "d" elements
> of elliptic curve and RSA keys could be moved to be within a "private"
> structure, what would be done for the "k" element of a symmetric key? Would
> that also be moved into a "private" element? (At that point, there would be
> no symmetric key information at the top level of the JWK, which seems more
> than a little odd.)
>
> Finally, I'll note that the specs already clearly delineate public from
> private fields, through use of the Parameter Information Class value in the
> JSON Web Key Parameters registry (with values "Public" and "Private"). So
> there should be no confusion which is which.
>
> I therefore recommend that this suggestion be resolved as "wontfix".
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
