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

+1 agree with all the points exposed already

On Fri, Aug 30, 2013 at 2:54 PM, Tim Bray <tbray@textuality.com> wrote:

> This increases complexity, will break existing implementations and does’t
> seem to actually reduce risk, in practice. +1 to wontfix
>
>
> On Thu, Aug 29, 2013 at 10:06 AM, Brian Campbell <
> bcampbell@pingidentity.com> wrote:
>
>> Concern about accidentally leakage is fair but I don't see that
>> rearranging things makes any practical difference. It would break
>> things though, which is something I'd think the WG should try to avoid
>> at this point without really compelling reasons to do so.
>>
>> On Wed, Aug 28, 2013 at 4:02 PM, Edmund Jay <ejay@mgi1.com> wrote:
>> > +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 <jricher@mitre.org>
>> > To: Mike Jones <Michael.Jones@microsoft.com>
>> > Cc: "jose@ietf.org" <jose@ietf.org>
>> > 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:trac+jose@trac.tools.ietf.org]
>> >> Sent: Wednesday, August 28, 2013 12:36 PM
>> >> To: 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
>> >
>> >
>> >
>> > _______________________________________________
>> > jose mailing list
>> > jose@ietf.org
>> > https://www.ietf.org/mailman/listinfo/jose
>> >
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>>
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>