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

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
>