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

[Dick Hardt <[e-mail]>]

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

On Mar 25, 2013, at 3:56 PM, Dick Hardt <[e-mail]> wrote:

> 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 <[e-mail]> 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 [mailto:[e-mail]] 
>> Sent: Monday, March 25, 2013 3:43 PM
>> To: Mike Jones
>> Cc: Richard Barnes; Brian Campbell; [e-mail]; Jim Schaad; [e-mail]
>> Subject: Re: [jose] #15: Broken examples in JWE / JWS
>>  
>> 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 <[e-mail]> wrote:
>> 
>> 
>> If you already know that something is going on out of band, the indication in the JOSE object would be unnecessary.
>>  
>>                                                                 -- Mike
>>  
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Richard Barnes
>> Sent: Monday, March 25, 2013 2:31 PM
>> To: Brian Campbell
>> Cc: [e-mail]; Jim Schaad; [e-mail]
>> Subject: Re: [jose] #15: Broken examples in JWE / JWS
>>  
>> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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:[e-mail]] 
>> Sent: Friday, March 22, 2013 4:09 PM
>> To: Jim Schaad
>> Cc: [e-mail]; [e-mail]
>> 
>> 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 */
>> }
>>  
>> 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 <[e-mail]> wrote:
>> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
>> > jose issue tracker
>> > Sent: Friday, March 22, 2013 2:37 PM
>> > To: [e-mail];
>> [e-mail]
>> > Cc: [e-mail]
>> > Subject: Re: [jose] #15: Broken examples in JWE / JWS
>> >
>> > #15: Broken examples in JWE / JWS
>> >
>> >
>> > Comment (by [e-mail]):
>> >
>> >  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.
>> >
>> > --
>> > -------------------------+----------------------------------------------
>> > -------------------------+---
>> >  Reporter:  [e-mail]   |       Owner:  draft-ietf-jose-json-web-
>> >      Type:  defect       |  [e-mail]
>> >  Priority:  minor        |      Status:  new
>> > Component:  json-web-    |   Milestone:
>> >   encryption             |     Version:
>> >  Severity:  -            |  Resolution:
>> >  Keywords:               |
>> > -------------------------+----------------------------------------------
>> > -------------------------+---
>> >
>> > Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/15#comment:1>
>> > jose <http://tools.ietf.org/jose/>
>> >
>> > _______________________________________________
>> > jose mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/jose
>> 
>>  
>>  
>> 
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
>> 
>>  
>>  
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
>