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

From: "jose issue tracker" <[email-masked]>
Date: Tue, 12 Nov 2013 02:33:29 -0000

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

Description changed by [email-masked]:

Old description:

> 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
>
> * WON'T FIX - did not receive support from the working group.
>
> B. RECOMMENDED is not a protocol requirement and thus should be
> lowercased
>
> C. cty is MUST be used
>
> * FIXED
>
> D. There are no rules specified here for how to convert a JWK to an octet
> string.  This needs to be done.
>
> Clarification on this issue - This item is addressing how to turn the
> JSON object into an octet string for the purposes of encryption.  I.e.
> Serialize as a UTF-8 String.
>
> 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.
>
> * WON'T FIX - it seems overkill but nobody seems to support only doing
> the one thing

New description:

 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

 * WON'T FIX - did not receive support from the working group.

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

 * DUP - #70

 C. cty is MUST be used

 * FIXED

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

 Clarification on this issue - This item is addressing how to turn the JSON
 object into an octet string for the purposes of encryption.  I.e.
 Serialize as a UTF-8 String.

 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.

 * WON'T FIX - it seems overkill but nobody seems to support only doing the
 one thing

--

-- 
-------------------------+-------------------------------------------------
 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://trac.tools.ietf.org/wg/jose/trac/ticket/82#comment:3>
jose <http://tools.ietf.org/jose/>