Subject: [jose] #82: Section 6. Encrypted JWK and Encrypted JWK Set Format

From: "jose issue tracker" <[email-masked]>
Date: Sun, 18 Aug 2013 19:57:02 -0000

#82: Section 6. Encrypted JWK and Encrypted JWK Set Format

 A. The existence of private material is not easily identifiable for an
 entity that does not have full and update information on a kty value.
 This means that they either need to not allow them to be processed or they
 need to not worry about the fact that information may be private.  This
 can be fixed by defining a JWK element "private" and requiring that all
 private material be placed in that object. This should be evaluated

 B. RECOMMENDED is not a protocol requirement and thus should be lowercased

 C. cty is MUST be used

 D. There are no rules specified here for how to convert a JWK to an octet
 string.  This needs to be done.

 E. The same items apply to both paragraph #1 and paragraph #2.

 F. For simplicity - is there any reason not to require the use of JWK Sets
 when doing the encrypted version.  This seems to be a complication that is
 not especially needed except to make Ryan happy.

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

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

---

From: "jose issue tracker" <[email-masked]>
Date: Wed, 28 Aug 2013 19:36:19 -0000

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

  key                    |  Resolution:
 Keywords:               |

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