Subject: [jose] #12: x5c incorrect in JWE

From: "jose issue tracker" <[email-masked]>
Date: Tue, 12 Mar 2013 21:15:50 -0000

#12: x5c incorrect in JWE

 No use case (that I'm aware of anyway) has been suggested for "x5c" in JWE
 that cannot be addressed in a more straightforward and efficient way using
 other available header parameters like "x5u", "kid", etc.

 I suggest "x5c" be removed from JWE.

 If it must stay, there are a couple of issues with its definition in
 http://tools.ietf.org/html/draft-ietf-jose-json-web-
 encryption-08#section-4.1.9 that need to be fixed.

 1) It states that "the certificate containing the public key of the entity
 that encrypted the JWE MUST be the first certificate" but for all the JWE
 algorithms currently defined that certificate would have to have the
 public key of the entity that corresponds to its private key which will be
 used to decrypt.

 2) It also states that "the recipient MUST verify the certificate chain
 according to [RFC5280] and reject..." which is really awkward because that
 certificate chain certifies the recipient (why would you validate your own
 cert chain?) not the sender.

 There was a message and subsequent shortish discussion thread on the list
 a while back about this too: http://www.ietf.org/mail-
 archive/web/jose/current/msg01438.html

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-jose-json-
  [email-masked]         |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  minor                    |  Milestone:
Component:  json-web-encryption      |    Version:
 Severity:  Submitted WG Document    |   Keywords:
-------------------------------------+-------------------------------------

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

---

From: "jose issue tracker" <[email-masked]>
Date: Wed, 13 Mar 2013 03:13:48 -0000

Comment (by [email-masked]):

 I agree that the issues reported by Brian should be corrected.  That
 doesn't constitue a case to remove the functionality entirely.

 Severity:  Submitted WG Document    |  Resolution:
 Keywords:                           |

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

---

From: "jose issue tracker" <[email-masked]>
Date: Wed, 13 Mar 2013 12:02:58 -0000

Comment (by [email-masked]):

 True, the issues alone don't constitue a case to remove the functionality.

 But what is the case to *have* the functionality?

 As written it doesn't work with the currently defined algorithms (which
 suggests that it's not being used). If those issues are fixed, it provides
 dubious value for the current algorithms but would preclude it's use for
 possible future applications where it'd be more meaningful - like for for
 the sender to provide its own cert chain for use with a ECDH-SS alg.

 Maybe I'm bike-shedding on this one a bit but it seems silly to have it as
 a reserved header that doesn't do anything useful as defined but might
 preclude something useful down the road.

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

---

From: "jose issue tracker" <[email-masked]>
Date: Sat, 30 Mar 2013 21:25:50 -0000

For generality, I'll note that if people believe that "x5c" should be
 removed from JWE, then the same logic probably suggests that "x5u", "jku"
 should be removed, as all are ways of including or referencing public key
 values corresponding to the private key used to encrypt the content.  And
 by that logic, if we don't need a way to reference or include public key
 values for JWEs, then the "x5t" and possibly "kid" parameters would then
 also be of dubious value.  At least by that reasoning, the inclusion of
 all the key reference parameters would likely stand or fall together.

Ticket URL: <https://tools.ietf.org/wg/jose/trac/ticket/12#comment:3>
jose <http://tools.ietf.org/jose/>