Re: [jose] #27: member names MUST be unique needs additional text

["Jim Schaad" <[e-mail]>]

I would strongly encourage everyone in the JOSE list to join the JSON list and read what was is there and participate.

That being said there are situations where you might not be able to do an independent parser.  And in fact what you have stated is that there is now a requirement that a JOSE library supply a JSON parser.  Is that really what we want to say?  How far from creating a set of generator and parser requirements that are non standard and requiring a parser/generator are we from that?

> -----Original Message-----
> From: Mike Jones [mailto:[e-mail]]
> Sent: Wednesday, June 26, 2013 12:30 PM
> To: Jim Schaad; [e-mail]
> Cc: [e-mail]
> Subject: RE: [jose] #27: member names MUST be unique needs additional text
> 
> The operable sentence in my suggested text below is this one: "If the
> platform's JSON parser does not reject input with duplicate member names,
> the input will first need to be separately parsed to reject these invalid inputs
> before using the platform's parser".  In other words, if the JSON parser in the
> development platform you are using does not reject inputs with duplicate
> member names, you will need to write a separate JSON parser that detects
> this invalid input and rejects it.
> 
> This parser could either just be a validator, returning TRUE or FALSE for
> whether the JSON is valid for JOSE - in which case you'd then pass any inputs
> validating as TRUE to the platform's JSON parser, or it could be a replacement
> parser, in which case your code would not use the development platform's
> JSON parser at all.  I suspect people would be more likely to do the former
> than the latter, but both approaches are equivalent.
> 
> BTW, if it's your sense that there's a problem occurring in the JSON working
> group with respect to enabling strict JSON parsing, we probably need to
> become active there.  For instance, even if the spec allows duplicate member
> names like the ECMA spec does, the RFC could recommend or require that
> parsers support a "strict" mode, which rejects these unnecessarily lax inputs.
> Then JOSE implementations could use that.
> 
> 				-- Mike
> 
> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: Wednesday, June 26, 2013 11:30 AM
> To: 'jose issue tracker'; [e-mail];
> Mike Jones
> Cc: [e-mail]
> Subject: RE: [jose] #27: member names MUST be unique needs additional text
> 
> <no hat>
> 
> I consider myself to be reasonably competent in both English and Technical
> English.  I have no idea what I am supposed to be doing to deal with the text
> below.  Does this mean that I need to write an independent parser?  What
> about cases where it is coming in on a stream and I don't get to see the data
> before the parse occurs?  How are they interpreted differently?  What
> exactly is this supposed to be addressing.  Much of this could be skipped
> when we said don't do it.  Since this is no longer a viable statement due to the
> state of parsers, we need to be more explicit and say what is going on.
> 
> No I don't consider the suggested text to be adequate.
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of jose issue tracker
> > Sent: Tuesday, June 25, 2013 5:41 PM
> > To: [e-mail];
> > [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [jose] #27: member names MUST be unique needs additional
> > text
> >
> > #27: member names MUST be unique needs additional text
> >
> >
> > Comment (by [e-mail]):
> >
> >  The JWS draft currently says:
> >
> >          The Header Parameter Names within the JWS Header MUST be unique;
> >          JWSs with duplicate Header Parameter Names MUST be rejected.
> >
> >  How about changing this to:
> >
> >          The Header Parameter Names within the JWS Header MUST be unique;
> >          JWSs with duplicate Header Parameter Names MUST be rejected.
> >          This is necessary to prevent attacks in which the same JWS
> > might  be interpreted
> >          in different ways by different implementations and to prevent
> attackers
> >          from hiding extra content in duplicate member values.
> >          If the platform s JSON parser does not reject input with
> > duplicate member names,
> >          the input will first need to be separately parsed to reject
> > these  invalid inputs
> >          before using the platform s parser.
> >
> > --
> > -------------------------+--------------------------------------------
> > -------------------------+--
> > -------------------------+---
> >  Reporter:               |       Owner:  draft-ietf-jose-json-web-
> >   [e-mail] |  [e-mail]
> >      Type:  defect       |      Status:  new
> >  Priority:  major        |   Milestone:
> > Component:  json-web-    |     Version:
> >   signature              |  Resolution:
> >  Severity:  -            |
> >  Keywords:               |
> > -------------------------+--------------------------------------------
> > -------------------------+--
> > -------------------------+---
> >
> > Ticket URL:
> > <http://trac.tools.ietf.org/wg/jose/trac/ticket/27#comment:1>
> > jose <http://tools.ietf.org/jose/>
> >
> > _______________________________________________
> > jose mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/jose