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

[Dick Hardt <[e-mail]>]

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