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

["Manger, James H" <[e-mail]>]

JSON parsers that accept duplicate names, but ignore all but the last, are too common to believe JOSE will not be implemented using those parsers. See "[Json] Call for real-world examples of how parsers deal with duplicate keys" http://www.ietf.org/mail-archive/web/json/current/msg00471.html.

I suspect the best we can do is say:

  A creator of a JOSE message MUST NOT put duplicate names in any JSON object in a JOSE header.
  To prevent attacks where a JOSE message is interpreted as different valid messages by different recipients, each recipient MUST either reject messages with duplicate names or accept only the last name.

Plus agitate in the JSON group to add related text to the next version of the JSON spec.


--
James Manger


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Jim Schaad
> Sent: Thursday, 27 June 2013 1:18 PM
> To: 'Mike Jones'; [e-mail]
> Cc: [e-mail]
> Subject: Re: [jose] #27: member names MUST be unique needs additional
> text
> 
> 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.
> > >