From: "Jim Schaad" <ietf@augustcellars.com>
To: "'Mike Jones'" <Michael.Jones@microsoft.com>,
 <draft-ietf-jose-json-web-signature@tools.ietf.org>
References: <061.bb7bbe0b618ec6b74904f48bdb9bb312@trac.tools.ietf.org>
 <076.a597050ecb4fb25084cec65f7174dc7e@trac.tools.ietf.org>
 <033b01ce729b$26ff5c90$74fe15b0$@augustcellars.com>
 <4E1F6AAD24975D4BA5B16804296739436789B4CC@TK5EX14MBXC283.redmond.corp.microsoft.com>
 <03b401ce72e5$002c65f0$008531d0$@augustcellars.com>
 <4E1F6AAD24975D4BA5B16804296739436789D4EA@TK5EX14MBXC283.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436789D4EA@TK5EX14MBXC283.redmond.corp.microsoft.com>
Date: Thu, 27 Jun 2013 10:07:04 -0700
Message-ID: <04a601ce7358$bfeade80$3fc09b80$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGqOaFgm5bSrTowyJkuz8ggVcVAJQJ0/9dvAtXnsooCfmP1+wE/Pt+eAksevJyZN6A8cA==
Content-Language: en-us
Cc: jose@ietf.org
Subject: Re: [jose] #27: member names MUST be unique needs additional text
Precedence: list

When the volume is high is when one needs to keep track of the what is =
going on.  If the volume is low then you can ignore it.

There have not been any recent discussions on parsers but I don't know =
what you mean by improved so I cannot make a statement one way or the =
other on that.  I have always had the mail moved into a folder and go in =
and read it in one big shot once or twice a day unless I am currently =
involved in a discussion.  I find that technique works well.

Jim


> -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Wednesday, June 26, 2013 9:07 PM
> To: Jim Schaad; draft-ietf-jose-json-web-signature@tools.ietf.org
> Cc: jose@ietf.org
> Subject: RE: [jose] #27: member names MUST be unique needs additional =
text
>=20
> The alternative is to say that producers MUST NOT produce JSON with
> duplicate member names and that consumers are strongly RECOMMENDED to
> reject input with duplicate member names and leave it at that.
>=20
> I understand not wanting to require customer parsers if the underlying
> platform parsers are deficient.  But I really hope that the JSON WG =
will have
> more sense than to allow the current madness to continue.  As I =
understood
> it, the primary motivation for the JSON WG in the first place was to =
change the
> SHOULD to a MUST.  If they don't do that, I'm really not sure what the =
point of
> it is.
>=20
> 				-- Mike
>=20
> P.S.  I am a subscriber to the JSON mailing list, but unfortunately, =
the volume
> got so high a few weeks ago that trying to keep up with it became an
> impediment to getting real work done.  At that point I created a rule =
to file
> those messages into a folder, which I only rarely look at.  Has that =
situation
> improved?
>=20
> -----Original Message-----
> From: Jim Schaad [mailto:ietf@augustcellars.com]
> Sent: Wednesday, June 26, 2013 8:18 PM
> To: Mike Jones; draft-ietf-jose-json-web-signature@tools.ietf.org
> Cc: jose@ietf.org
> Subject: RE: [jose] #27: member names MUST be unique needs additional =
text
>=20
> I would strongly encourage everyone in the JOSE list to join the JSON =
list and
> read what was is there and participate.
>=20
> 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?
>=20
> > -----Original Message-----
> > From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> > Sent: Wednesday, June 26, 2013 12:30 PM
> > To: Jim Schaad; draft-ietf-jose-json-web-signature@tools.ietf.org
> > Cc: jose@ietf.org
> > 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:ietf@augustcellars.com]
> > Sent: Wednesday, June 26, 2013 11:30 AM
> > To: 'jose issue tracker';
> > draft-ietf-jose-json-web-signature@tools.ietf.org;
> > Mike Jones
> > Cc: jose@ietf.org
> > 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: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On =
Behalf
> > > Of jose issue tracker
> > > Sent: Tuesday, June 25, 2013 5:41 PM
> > > To: draft-ietf-jose-json-web-signature@tools.ietf.org;
> > > michael.jones@microsoft.com
> > > Cc: jose@ietf.org
> > > Subject: Re: [jose] #27: member names MUST be unique needs
> > > additional text
> > >
> > > #27: member names MUST be unique needs additional text
> > >
> > >
> > > Comment (by michael.jones@microsoft.com):
> > >
> > >  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-
> > >   ietf@augustcellars.com |  signature@tools.ietf.org
> > >      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
> > > jose@ietf.org
> > > https://www.ietf.org/mailman/listinfo/jose
>=20