Subject: [jose] #15: Broken examples in JWE / JWS

From: "jose issue tracker" <[email-masked]>
Date: Fri, 22 Mar 2013 21:09:18 -0000

#15: Broken examples in JWE / JWS

 The examples in JWE and JWS are broken.  They don't tell the recipient
 what key to use when processing the object.  Suggest resolving this by
 adding a "kid" field to both object.

 JWE
 OLD: {"alg":"RSA1_5","enc":"A128CBC+HS256"}
 NEW: {"alg":"RSA1_5","enc":"A128CBC+HS256","kid":"1"}

 JWS
 OLD: {"typ":"JWT","alg":"HS256"}
 NEW: {"typ":"JWT","alg":"HS256","kid":"1"}

 More generally, the protocol format should make these types of objects
 illegal, since they don't have enough information to be used by a
 recipient (without pre-negotiation).

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

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

---

From: "jose issue tracker" <[email-masked]>
Date: Fri, 22 Mar 2013 21:36:58 -0000

Comment (by [email-masked]):

 I think this is not an issue. The examples are NOT broken and they do not
 need a fix.
 I suggest to close this ticket.
 The draft should definitely not make these illegal. These objects are
 perfect examples for a valid JWS/JWE.

 Severity:  -            |  Resolution:
 Keywords:               |

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

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 22 Mar 2013 15:13:59 -0700

My inclination is that this response is correct.  

What make you think that the key or key reference is required and cannot be
implied?

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> jose issue tracker
> Sent: Friday, March 22, 2013 2:37 PM
> To: [email-masked];
[email-masked]
> Cc: [email-masked]
> Subject: Re: [jose] #15: Broken examples in JWE / JWS
> 
perfect
> examples for a valid JWS/JWE.
> 
> --
> -------------------------+----------------------------------------------
> -------------------------+---
> -------------------------+----------------------------------------------
> -------------------------+---
> 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Fri, 22 Mar 2013 19:08:32 -0400

I admit that they are not broken according to the current spec.  However, I
have a lot of trouble figuring out how I would write code to process them.

If "kid" or "jwk" MUST be present to indicate what key I should use, then I
can have deterministic code:
if (/* recognized "kid" or "jwk" value */) {
    /* use it */
} else {
    /* FAIL.  can't process this object */
}

As the spec stands, I have no idea what to put in that "else" clause.  I'm
clearly not supposed to fail, because the parameters are optional.  But
what else?
if (/* recognized "kid" or "jwk" value */) {
    /* use it */
} else {
    /* insert special magic here */
}

This is actually what SPI is supposed to clear up.  SPI would provide an
explicit third branch for the special magic to live in.
if (/* recognized "kid" or "jwk" value */) {
    /* use it */
} else if (/* recognized SPI value */) {
    /* process using stored parameters */
} else {
    /* FAIL.  can't process this object */
}

But without the concept of SPI, the spec is broken because of the
non-determinism noted above.

--Richard

On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad <[email-masked]> wrote:

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

---

From: "jose issue tracker" <[email-masked]>
Date: Fri, 22 Mar 2013 23:20:35 -0000

Comment (by [email-masked]):

 Speaking as an individual, I'm not adverse to adding the use of the "kid"
 parameter to one or more of the examples, but it shouldn't be in all of
 them, as in many use cases, the key to be used is communicated by other
 means than the "kid" (including by using some of the other header
 parameters also defined by the specifications).

 I'll also point out that the working group has already determined that the
 "kid" parameter is adequately defined, so that aspect of this issue has
 already been considered and is closed.  See "CLOSED: Is KID sufficently
 defined" at http://www.ietf.org/mail-
 archive/web/jose/current/msg01218.html.

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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 22 Mar 2013 20:47:53 -0400

The question isn't whether the semantic of "kid" is sufficiently defined.
 The question is when it should be required.  I'm not even saying that
"kid" should be required in all cases -- just that the recipient should
have clear instructions about what to do in all cases.

--Richard

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 22 Mar 2013 18:15:40 -0700

This may or may not be a flaw in the specification.  However the item you
created in the tracker does not reflect what you have put here.  I think you
would be better served by saying that there is a flaw in the specifications
in that there should be a MUST that some type of key or key reference is
required in a JWS or JWE.

I would note that your example code should be more complex in that it does
not deal with jku or any of the x* methods of referencing keys.

Jim

From: Richard Barnes [mailto:[email-masked]] 
Sent: Friday, March 22, 2013 4:09 PM
To: Jim Schaad
Cc: [email-masked]; [email-masked]
Subject: Re: [jose] #15: Broken examples in JWE / JWS

    /* use it */

} else {

}

As the spec stands, I have no idea what to put in that "else" clause.  I'm
clearly not supposed to fail, because the parameters are optional.  But what
else?

    /* use it */

} else {

}

    /* use it */

} else {

}

--Richard

Jim

[email-masked]
perfect

---

From: "jose issue tracker" <[email-masked]>
Date: Sat, 23 Mar 2013 01:37:08 -0000

#15: At least one key indicator should be mandatory

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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 22 Mar 2013 21:37:48 -0400

I've renamed the issue to try to clarify.

You're right that there are alternative ways to locate a key.  But a JOSE
object needs to contain at least one of them, or else the /* special magic
*/ clause applies.

--Richard

On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad <[email-masked]> wrote:

> created in the tracker does not reflect what you have put here.  I think
> you would be better served by saying that there is a flaw in the
> specifications in that there should be a MUST that some type of key or key
> reference is required in a JWS or JWE.****
>
> ** **
>
> not deal with jku or any of the x* methods of referencing keys.****
>
> ** **
>
> Jim****
>
> ** **
>
> ** **
>
> *From:* Richard Barnes [mailto:[email-masked]]
> *Sent:* Friday, March 22, 2013 4:09 PM
> *To:* Jim Schaad
> *Cc:* [email-masked]; [email-masked]
>
> *Subject:* Re: [jose] #15: Broken examples in JWE / JWS****
>
> ** **
>
> I admit that they are not broken according to the current spec.  However,
> I have a lot of trouble figuring out how I would write code to process them.
> ****
>
> ** **
>
> If "kid" or "jwk" MUST be present to indicate what key I should use, then
> I can have deterministic code:****
>
> if (/* recognized "kid" or "jwk" value */) { ****
>
>     /* use it */****
>
> } else {****
>
>     /* FAIL.  can't process this object */****
>
> }****
>
> ** **
>
> what else?****
> if (/* recognized "kid" or "jwk" value */) { ****
>
>     /* use it */****
>
> } else {****
>
>     /* insert special magic here */****
>
> }****
>
> ** **
>
> explicit third branch for the special magic to live in.****
>
> if (/* recognized "kid" or "jwk" value */) { ****
>
>     /* use it */****
>
> } else if (/* recognized SPI value */) {****
>
>     /* process using stored parameters */****
>
> } else {****
>
>     /* FAIL.  can't process this object */****
>
> }****
>
> ** **
>
> non-determinism noted above.****
>
> ** **
>
> --Richard****
>
> ** **
>
> ** **
>
> ** **
>
> On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad <[email-masked]>
> wrote:****
>
> Jim****
> ****
> > -------------------------+---****
>
> ****
> > -------------------------+---****
>
> >
> > https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>

---

From: "jose issue tracker" <[email-masked]>
Date: Sat, 23 Mar 2013 06:35:10 -0000

Example for JWE: An Email to Stan <<attached Finally.doc.jwe>>

   Dear Stan,
     please use SuperJWE and the password agreed upon earlier to decrypt
 Finally.doc.jwe.
   best
   the real slim shady

 -----

 Example for JWS:
   base64url({"alg":"HS256"}).base64url({"X": "containing key
 info"}).sigb64

 -----

 Java Example JWS/JWE "jwt received through an SSL connection":
 {{{
 final String ALLOWED_ALG = JsonCryptoLib.HS256;
 SSLSession sslSession = connection.getSession();
 byte[] key = getKey(sslSession);
 JsonCryptoLib jsonCryptoLib = JsonCryptoLib.getInstance(ALLOWED_ALG);
 byte[] payload = jsonCryptoLib.parse(jwt, key);
 // the "magic" is in getKey which uses context information to determine
 the key
 //
 http://docs.oracle.com/javase/1.5.0/docs/api/javax/net/ssl/SSLSession.html#getPeerCertificateChain%28%29
 // maybe it is timebased too
 }}}

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

---

From: Brian Campbell <[email-masked]>
Date: Mon, 25 Mar 2013 06:15:52 -0600

/* special magic */ is just some out of band agreement on the key to use
or how to infer it. Which isn't really special or magic. But probably
pretty common.

On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes <[email-masked]> wrote:

> On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad <[email-masked]>wrote:
>
>> I would note that your example code should be more complex in that it
>> does not deal with jku or any of the x* methods of referencing keys.****
>>
>> ** **
>>
>> Jim****
>>
>> ** **
>>
>> ** **
>>
>> As the spec stands, I have no idea what to put in that "else" clause.
>>  I'm clearly not supposed to fail, because the parameters are optional.
>>  But what else?****
>>
>> > Ticket URL: <
>> http://trac.tools.ietf.org/wg/jose/trac/ticket/15#comment:1>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 25 Mar 2013 17:30:44 -0400

I realize that's the common case.  But the spec doesn't say that.

All I'm saying is, the spec should REQUIRE that a sender include either a
key indicator, or an indication that something is going on out of band.

--Richard

On Mon, Mar 25, 2013 at 8:15 AM, Brian Campbell
<[email-masked]>wrote:

>>> This may or may not be a flaw in the specification.  However the item
>>> you created in the tracker does not reflect what you have put here.  I
>>> think you would be better served by saying that there is a flaw in the
>>> I admit that they are not broken according to the current spec.
>>>  However, I have a lot of trouble figuring out how I would write code to
>>> process them.****
>>>
>>> ** **
>>>
>>> If "kid" or "jwk" MUST be present to indicate what key I should use,
>>> then I can have deterministic code:****
>>>

---

From: Mike Jones <[email-masked]>
Date: Mon, 25 Mar 2013 21:54:52 +0000

If you already know that something is going on out of band, the indication in the JOSE object would be unnecessary.

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Monday, March 25, 2013 2:31 PM
To: Brian Campbell
Cc: [email-masked]; Jim Schaad; [email-masked]
Subject: Re: [jose] #15: Broken examples in JWE / JWS

All I'm saying is, the spec should REQUIRE that a sender include either a key indicator, or an indication that something is going on out of band.

--Richard

On Mon, Mar 25, 2013 at 8:15 AM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
/* special magic */ is just some out of band agreement on the key to use or how to infer it. Which isn't really special or magic. But probably pretty common.

On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
I've renamed the issue to try to clarify.

You're right that there are alternative ways to locate a key.  But a JOSE object needs to contain at least one of them, or else the /* special magic */ clause applies.

--Richard

On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
This may or may not be a flaw in the specification.  However the item you created in the tracker does not reflect what you have put here.  I think you would be better served by saying that there is a flaw in the specifications in that there should be a MUST that some type of key or key reference is required in a JWS or JWE.

I would note that your example code should be more complex in that it does not deal with jku or any of the x* methods of referencing keys.

Jim

From: Richard Barnes [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, March 22, 2013 4:09 PM
To: Jim Schaad
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

I admit that they are not broken according to the current spec.  However, I have a lot of trouble figuring out how I would write code to process them.

If "kid" or "jwk" MUST be present to indicate what key I should use, then I can have deterministic code:
if (/* recognized "kid" or "jwk" value */) {
    /* use it */
} else {
    /* FAIL.  can't process this object */
}

As the spec stands, I have no idea what to put in that "else" clause.  I'm clearly not supposed to fail, because the parameters are optional.  But what else?
if (/* recognized "kid" or "jwk" value */) {
    /* use it */
} else {
    /* insert special magic here */
}

This is actually what SPI is supposed to clear up.  SPI would provide an explicit third branch for the special magic to live in.

But without the concept of SPI, the spec is broken because of the non-determinism noted above.

--Richard

On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
My inclination is that this response is correct.

Jim

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> jose issue tracker
> To: [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> Comment (by [email-masked]<mailto:[email-masked]>):
>
perfect
>  Reporter:  [email-masked]<mailto:[email-masked]>   |       Owner:  draft-ietf-jose-json-web-
>      Type:  defect       |  [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

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

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 25 Mar 2013 14:59:24 -0700

It may need to be noted that doing /* special magic */ is not something that
a library would ever be able to do.  This implies that the application needs
to know that this is going to be the case and know how to pass in all of the
relevant keys as part of the signature/mac verification process or the
decryption process.

Jim

From: Richard Barnes [mailto:[email-masked]] 
Sent: Monday, March 25, 2013 2:31 PM
To: Brian Campbell
Cc: Jim Schaad; [email-masked];
[email-masked]
Subject: Re: [jose] #15: Broken examples in JWE / JWS

--Richard

On Mon, Mar 25, 2013 at 8:15 AM, Brian Campbell <[email-masked]>
wrote:

/* special magic */ is just some out of band agreement on the key to use or
how to infer it. Which isn't really special or magic. But probably pretty
common.

--Richard

Jim

    /* use it */

} else {

}

    /* use it */

} else {

}

    /* use it */

} else {

}

--Richard

Jim

[email-masked]
perfect

---

From: Richard Barnes <[email-masked]>
Date: Mon, 25 Mar 2013 18:05:12 -0400

IF your application is always doing something out of band, and IF every
JOSE object you ever receive uses the same out of band channel, and IF the
JOSE library can locate the pre-negotiated parameters based on something
other than the JOSE object, ....

You can see where I'm going with this.  In order for just leaving things
out to be workable, you have to bake some of that out-of-band logic into
your JOSE library.  In which case it's not really out-of-band any more, and
we should specify it.  And clearly specifying security negotiation protocol
is not in scope for this group.

If you have an explicit marking (e.g., SPI), there's a clean interface
between the stuff that only knows JOSE and stuff that does negotiation.

(BTW, +1 to what Jim said)

On Mon, Mar 25, 2013 at 5:54 PM, Mike Jones <[email-masked]>wrote:

>  If you already know that something is going on out of band, the
> indication in the JOSE object would be unnecessary.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Richard Barnes
> *Sent:* Monday, March 25, 2013 2:31 PM
> *To:* Brian Campbell
> *Cc:* [email-masked]; Jim Schaad;
> [email-masked]
>
> I realize that's the common case.  But the spec doesn't say that.  ****
>
> ** **
>
> key indicator, or an indication that something is going on out of band.***
> *
>
> ** **
>
> --Richard****
>
> ** **
>
> ** **
>
> On Mon, Mar 25, 2013 at 8:15 AM, Brian Campbell <
> [email-masked]> wrote:****
>
> pretty common.****
> On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes <[email-masked]> wrote:****
>
> I've renamed the issue to try to clarify.****
>
> ** **
>
> */ clause applies.  ****
> On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad <[email-masked]>
> wrote:****
>
> *Cc:* [email-masked]; [email-masked]***
> *
>
>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 25 Mar 2013 15:42:43 -0700

I think the example should contain the KID as one would expect that to be the common case.

On Mar 25, 2013, at 2:54 PM, Mike Jones <[email-masked]> wrote:

> On Mon, Mar 25, 2013 at 8:15 AM, Brian Campbell <[email-masked]> wrote:

---

From: Mike Jones <[email-masked]>
Date: Mon, 25 Mar 2013 22:49:10 +0000

As I'd already written, I have no problem with some of the examples containing a Key ID.  But it's also the case in many deployment environments that keys are pre-shared and known by both parties in advance of any tokens being exchanged.  This is often true when per-client symmetric keys are used with OAuth, for instance.

                                                            -- Mike

From: Dick Hardt [mailto:[email-masked]]
Sent: Monday, March 25, 2013 3:43 PM
To: Mike Jones
Cc: Richard Barnes; Brian Campbell; [email-masked]; Jim Schaad; [email-masked]
Subject: Re: [jose] #15: Broken examples in JWE / JWS

On Mar 25, 2013, at 2:54 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                                -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Richard Barnes
Sent: Monday, March 25, 2013 2:31 PM
To: Brian Campbell
Cc: [email-masked]<mailto:[email-masked]>; Jim Schaad; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] #15: Broken examples in JWE / JWS

--Richard

--Richard

Jim

--Richard

Jim

perfect

---

From: Dick Hardt <[email-masked]>
Date: Mon, 25 Mar 2013 15:56:19 -0700

I wish we would have put KID into OAuth 2.0. 

Now if someone rotates the key without deploying everywhere they are stored, then the app starts failing without a good error message. Including a key id allows the server to give a more intelligent response beside an authentication failure.

On Mar 25, 2013, at 3:49 PM, Mike Jones <[email-masked]> wrote:

> As I’d already written, I have no problem with some of the examples containing a Key ID.  But it’s also the case in many deployment environments that keys are pre-shared and known by both parties in advance of any tokens being exchanged.  This is often true when per-client symmetric keys are used with OAuth, for instance.
>  
>                                                             -- Mike
>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 25 Mar 2013 15:58:13 -0700

btw: good OAuth 2.0 implementations embed KID into the opaque token so that they can give a meaningful error message

---

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

In lots of OAuth deployments, the keys used are negotiated out of band and
 known in advance by both parties.  The same is true of many other
 deployment scenarios.  In these cases, any key indicators in the JOSE
 object itself would be redundant.

 We should not change the specifications to mandate including often
 unnecessary information.

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