Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873F821F9B0E for ; Wed, 26 Jun 2013 22:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyqoJcXsNBZg for ; Wed, 26 Jun 2013 22:23:46 -0700 (PDT) Received: from mail-vb0-f42.google.com (mail-vb0-f42.google.com [209.85.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4459621F9BF2 for ; Wed, 26 Jun 2013 22:23:46 -0700 (PDT) Received: by mail-vb0-f42.google.com with SMTP id i3so257328vbh.15 for ; Wed, 26 Jun 2013 22:23:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=OcTG+YKucbchd8Uh+rTW1kXKyCmGjUGOt/X8HaCJmDc=; b=KFQbEyuN3gTzIHho6iBukudNLWwhw+2Fm9uDODgxAXVsRKzm0/XuT0m2iCHwLMPunw nf2nLf+2jj+G4r05PfBcMR3c7g708N352Fub+RVFh8ZjqSGAeoJQtI0xPoBKS4SQ6OCe tkuVNxjWnsqtmcx7PJ0LKpH3W2w2OLJf5jzHqH6WFrLEYdarewiOM5iwWKIz7UUDlCks En4IUB+mJSRnnbllTUz4pwuk5C0S22s25cAJhFAB4DruipHg4nLevcEfxLQaWbJlrAxe p8oniz+dOAlmb0cryya7HuPemoY82SitK9M8K6GVn8eQpegQO5rh4t2bGKqsAzigzl60 LkIA== MIME-Version: 1.0 X-Received: by 10.220.91.75 with SMTP id l11mr2883278vcm.82.1372310625624; Wed, 26 Jun 2013 22:23:45 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Wed, 26 Jun 2013 22:23:45 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436789D4EA@TK5EX14MBXC283.redmond.corp.microsoft.com> 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> Date: Wed, 26 Jun 2013 22:23:45 -0700 Message-ID: From: Tim Bray To: Mike Jones Content-Type: multipart/alternative; boundary=047d7b3440885cb06704e01bf78b X-Gm-Message-State: ALoCoQkY74U5Omt3FKGCxJwVPiGMNGxuFVxJd64bYeXNBQ2O/hDGulJieQ5PncUMOWi0zGM3ndQ7 Cc: Jim Schaad , "jose@ietf.org" , "draft-ietf-jose-json-web-signature@tools.ietf.org" Subject: Re: [jose] #27: member names MUST be unique needs additional text X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 05:23:51 -0000 --047d7b3440885cb06704e01bf78b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think it=E2=80=99s a nice clean minimal solution to say that producers MU= ST NOT generate dupes, end of story. I don=E2=80=99t think saying anything beyond= that adds value. -T On Wed, Jun 26, 2013 at 9:07 PM, Mike Jones wr= ote: > 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. > > 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 no= t > sure what the point of it is. > > -- Mike > > 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? > > -----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 tex= t > > I would strongly encourage everyone in the JOSE list to join the JSON lis= t > 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 no= w > 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 w= e > from that? > > > -----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 reject= s > 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 ar= e > 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 reject= s > 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 > > > > > > > > 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: > > > > > > jose > > > > > > _______________________________________________ > > > jose mailing list > > > jose@ietf.org > > > https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --047d7b3440885cb06704e01bf78b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think it=E2=80=99s a nice clean minimal solution to say = that producers MUST NOT generate dupes, end of story.=C2=A0 I don=E2=80=99t= think saying anything beyond that adds value. -T


On Wed, Jun 26, 2013 at 9:07 PM, Mike Jones <Michael.Jones@mic= rosoft.com> wrote:
The alternative is to say that producers MUST NOT produce JSON with duplica= te member names and that consumers are strongly RECOMMENDED to reject input= with duplicate member names and leave it at that.

I understand not wanting to require customer parsers if the underlying plat= form parsers are deficient. =C2=A0But I really hope that the JSON WG will h= ave more sense than to allow the current madness to continue. =C2=A0As I un= derstood it, the primary motivation for the JSON WG in the first place was = to change the SHOULD to a MUST. =C2=A0If they don't do that, I'm re= ally not sure what the point of it is.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

P.S. =C2=A0I am a subscriber to the JSON mailing list, but unfortunately, t= he volume got so high a few weeks ago that trying to keep up with it became= an impediment to getting real work done. =C2=A0At that point I created a r= ule to file those messages into a folder, which I only rarely look at. =C2= =A0Has that situation improved?

-----Original Message-----
From: Jim Schaad [mailto:ietf@aug= ustcellars.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<= br>
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 i= ndependent parser. =C2=A0And in fact what you have stated is that there is = now a requirement that a JOSE library supply a JSON parser. =C2=A0Is that r= eally what we want to say? =C2=A0How far from creating a set of generator a= nd parser requirements that are non standard and requiring a parser/generat= or are we from that?

> -----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<= br> > 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". =C2= =A0In 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 rejec= ts it.
>
> This parser could either just be a validator, returning TRUE or FALSE<= br> > 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. =C2=A0I suspect peo= ple would
> be more likely to do the former than the latter, but both approaches a= re equivalent.
>
> BTW, if it's your sense that there's a problem occurring in th= e JSON
> working group with respect to enabling strict JSON parsing, we
> probably need to become active there. =C2=A0For 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, w= hich rejects these unnecessarily lax inputs.
> Then JOSE implementations could use that.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike
>
> -----Original Message-----
> From: Jim Schaad [mailto:iet= f@augustcellars.com]
> Sent: Wednesday, June 26, 2013 11:30 AM
> To: 'jose issue tracker';
> d= raft-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<= br> > text
>
> <no hat>
>
> I consider myself to be reasonably competent in both English and
> Technical English. =C2=A0I have no idea what I am supposed to be doing= to
> deal with the text below. =C2=A0Does this mean that I need to write an=
> independent parser? =C2=A0What about cases where it is coming in on a<= br> > stream and I don't get to see the data before the parse occurs? = =C2=A0How
> are they interpreted differently? =C2=A0What exactly is this supposed = to be
> addressing. =C2=A0Much 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@micr= osoft.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 michae= l.jones@microsoft.com):
> >
> > =C2=A0The JWS draft currently says:
> >
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Header Parameter Names with= in the JWS Header MUST be unique;
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0JWSs with duplicate Header Para= meter Names MUST be rejected.
> >
> > =C2=A0How about changing this to:
> >
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Header Parameter Names with= in the JWS Header MUST be unique;
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0JWSs with duplicate Header Para= meter Names MUST be rejected.
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This is necessary to prevent at= tacks in which the same JWS
> > might =C2=A0be interpreted
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in different ways by different = implementations and to
> > prevent
> attackers
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0from hiding extra content in du= plicate member values.
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If the platform s JSON parser d= oes not reject input with
> > duplicate member names,
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the input will first need to be= separately parsed to reject
> > these =C2=A0invalid inputs
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0before using the platform s par= ser.
> >
> > --
> > -------------------------+---------------------------------------= ---
> > -------------------------+--
> > -------------------------+--
> > -------------------------+---
> > =C2=A0Reporter: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = | =C2=A0 =C2=A0 =C2=A0 Owner: =C2=A0draft-ietf-jose-json-web-
> > =C2=A0 ietf@augustcella= rs.com | =C2=A0signature@to= ols.ietf.org
> > =C2=A0 =C2=A0 =C2=A0Type: =C2=A0defect =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0Status: =C2=A0new
> > =C2=A0Priority: =C2=A0major =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 M= ilestone:
> > Component: =C2=A0json-web- =C2=A0 =C2=A0| =C2=A0 =C2=A0 Version:<= br> > > =C2=A0 signature =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0Resolution:
> > =C2=A0Severity: =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |
> > =C2=A0Keywords: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = |
> > -------------------------+---------------------------------------= ---
> > -------------------------+--
> > -------------------------= +--
> > -------------------------+---
> >
> > 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


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--047d7b3440885cb06704e01bf78b--