Re: [jose] #27: member names MUST be unique needs additional text
Tim Bray <tbray@textuality.com> Thu, 27 June 2013 05:23 UTC
Return-Path: <tbray@textuality.com>
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 <jose@ietfa.amsl.com>; 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 <jose@ietfa.amsl.com>; 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 <jose@ietf.org>; Wed, 26 Jun 2013 22:23:46 -0700 (PDT)
Received: by mail-vb0-f42.google.com with SMTP id i3so257328vbh.15 for <jose@ietf.org>; 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: <CAHBU6ivNow2xhDvRj7gG2gmHQ+C-ejEHCQubK=LwUtrXxdW6MA@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary="047d7b3440885cb06704e01bf78b"
X-Gm-Message-State: ALoCoQkY74U5Omt3FKGCxJwVPiGMNGxuFVxJd64bYeXNBQ2O/hDGulJieQ5PncUMOWi0zGM3ndQ7
Cc: Jim Schaad <ietf@augustcellars.com>, "jose@ietf.org" <jose@ietf.org>, "draft-ietf-jose-json-web-signature@tools.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 <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2013 05:23:51 -0000
I think it’s a nice clean minimal solution to say that producers MUST NOT generate dupes, end of story. I don’t think saying anything beyond that adds value. -T On Wed, Jun 26, 2013 at 9:07 PM, Mike Jones <Michael.Jones@microsoft.com>wrote: > 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 not > 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 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: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 > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >
- [jose] #27: member names MUST be unique needs add… jose issue tracker
- Re: [jose] #27: member names MUST be unique needs… jose issue tracker
- Re: [jose] #27: member names MUST be unique needs… Jim Schaad
- Re: [jose] #27: member names MUST be unique needs… Mike Jones
- Re: [jose] #27: member names MUST be unique needs… Jim Schaad
- Re: [jose] #27: member names MUST be unique needs… Mike Jones
- Re: [jose] #27: member names MUST be unique needs… Tim Bray
- Re: [jose] #27: member names MUST be unique needs… Manger, James H
- Re: [jose] #27: member names MUST be unique needs… Manger, James H
- Re: [jose] #27: member names MUST be unique needs… Tim Bray
- Re: [jose] #27: member names MUST be unique needs… Manger, James H
- Re: [jose] #27: member names MUST be unique needs… Carsten Bormann
- Re: [jose] #27: member names MUST be unique needs… Manger, James H
- Re: [jose] #27: member names MUST be unique needs… Tim Bray
- Re: [jose] #27: member names MUST be unique needs… John Bradley
- Re: [jose] #27: member names MUST be unique needs… Mike Jones
- Re: [jose] #27: member names MUST be unique needs… Jim Schaad
- Re: [jose] #27: member names MUST be unique needs… Jim Schaad
- Re: [jose] #27: member names MUST be unique needs… Jim Schaad
- Re: [jose] #27: member names MUST be unique needs… Richard Barnes
- Re: [jose] #27: member names MUST be unique needs… Richard Barnes
- Re: [jose] #27: member names MUST be unique needs… Mike Jones
- Re: [jose] #27: member names MUST be unique needs… Mike Jones
- Re: [jose] #27: member names MUST be unique needs… Richard Barnes
- Re: [jose] #27: member names MUST be unique needs… Mike Jones
- Re: [jose] #27: member names MUST be unique needs… jose issue tracker