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

From: Mike Jones <[email-masked]>
Date: Wed, 28 Aug 2013 19:40:22 +0000

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-masked]] 
Sent: Wednesday, August 28, 2013 12:36 PM
To: [email-masked]; Mike Jones
Cc: [email-masked]
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-masked]):

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".

-- 
-------------------------+----------------------------------------------
-------------------------+---
 Reporter:               |       Owner:  draft-ietf-jose-json-web-
  [email-masked] |  [email-masked]
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  json-web-    |     Version:
  key                    |  Resolution:
 Severity:  -            |
 Keywords:               |
-------------------------+----------------------------------------------
-------------------------+---

Ticket URL: <http://tools.ietf.org/wg/jose/trac/ticket/82#comment:1>
jose <http://tools.ietf.org/jose/>

---

From: Justin Richer <[email-masked]>
Date: Wed, 28 Aug 2013 15:53:15 -0400

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

---

From: Edmund Jay <[email-masked]>
Date: Wed, 28 Aug 2013 15:02:31 -0700 (PDT)

+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-masked]>
To: Mike Jones <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
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

> I therefore recommend that this suggestion be resolved as "wontfix".

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: Brian Campbell <[email-masked]>
Date: Thu, 29 Aug 2013 11:06:02 -0600

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 <[email-masked]> 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.
>
> 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".
>
> 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.
>
>> 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
>>
>> 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.
>>

---

From: Tim Bray <[email-masked]>
Date: Fri, 30 Aug 2013 10:54:24 -0700

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 <[email-masked]
> wrote:

> a
> the

---

From: Matias Woloski <[email-masked]>
Date: Fri, 30 Aug 2013 14:55:32 -0300

+1 agree with all the points exposed already

On Fri, Aug 30, 2013 at 2:54 PM, Tim Bray <[email-masked]> wrote:

> On Thu, Aug 29, 2013 at 10:06 AM, Brian Campbell <
> [email-masked]> wrote:
>

---

From: Naveen Agarwal <[email-masked]>
Date: Fri, 30 Aug 2013 16:01:13 -0700

+1 Agree with Mike and Justin's comments.

On Wed, Aug 28, 2013 at 12:53 PM, Justin Richer <[email-masked]> wrote:

> latter is actually more robust against different key types since it
> enforces a per-type evaluation of what's "public" and what's "private".
>
>> working group’s attention for discussion.  My personal view is stated in
>> the issue tracker comment below.
>>
>>                                 -- Mike
>>
>> From: jose issue tracker [mailto:[email-masked].**ietf.org<[email-masked]>
>> ]
>> To: draft-ietf-jose-json-web-key@**tools.ietf.org<[email-masked]>;
>> Mike Jones
>> Cc: [email-masked]
> ______________________________**_________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/jose<https://www.ietf.org/mailman/listinfo/jose>
>