Re: [jose] FOR WG DISCUSSION: #82 part A - Possibly changing representation of private JWK fields

+1 Agree with Mike and Justin's comments.

On Wed, Aug 28, 2013 at 12:53 PM, Justin Richer <jricher@mitre.org> wrote:

> 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:trac+jose@trac.tools.**ietf.org<trac%2Bjose@trac.tools.ietf.org>
>> ]
>> Sent: Wednesday, August 28, 2013 12:36 PM
>> To: draft-ietf-jose-json-web-key@**tools.ietf.org<draft-ietf-jose-json-web-key@tools.ietf.org>;
>> Mike Jones
>> Cc: jose@ietf.org
>> 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 michael.jones@microsoft.com):
>>
>> 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
> jose@ietf.org
> https://www.ietf.org/mailman/**listinfo/jose<https://www.ietf.org/mailman/listinfo/jose>
>