I’m pretty sure that at some point before the end of the year the IETF will publish I-JSON (see https://datatracker.ietf.org/doc/draft-ietf-json-i-json/) which simply specifies that there MUST NOT be dupe keys. Depending on the timeframe, referring to this might be a good solution.
On Fri, Sep 12, 2014 at 8:18 AM, Mike Jones <[email protected]> wrote: > Sure. Here’s an analysis of the requirements about duplicate member > names. > > > > There could be two very different kinds of objections to the present text: > > A. People think we have the semantics for duplicate identifiers wrong. > > B. People think we should explain the current semantics for duplicate > identifiers more clearly. > > > > I sure hope that we’re dealing with B and not A. Stephen, which is the > nature of your critique of this text? > > > > If we’re in the realm of A, I think there are three possibilities for the > semantics: > > > > 1. Require producers not use duplicate members and require consumers to > reject inputs with duplicate member names. > > Pros: This is the most locked-down, consistent, and alternative. > > Cons: Real JSON parsers don’t all reject duplicate inputs. If we force > people to write custom parsers, this will result in exploitable bugs (and > some just won’t do it and won’t be conformant). > > > > 2. Require producers not to use duplicate members but allow consumers to > accept inputs with duplicate member names in the manner defined in > ECMAscript. (This is the current choice.) > > Pros: People can use all standard JSON parsers. Producers are still > required to produce well-formed data structures. > > Cons: The requirements on producers are stricter than those on consumers. > > > > 3. Allow both producers and consumers to use duplicate members, with > duplicate member names handled in the manner defined in ECMAscript. > > Pros: People can use ECMAscript parsers (which are more liberal than some > JSON parsers). The requirements on producers and consumers are the same. > > Cons: Hidden content can be inserted into duplicate member names. This > could give attackers a way to manipulate the inputs to crypto operations. > Strict JSON parsers (that reject inputs with duplicate members) can’t be > used. > > > > Practically, I think were we presently are (2) is the best compromise > between implementability, consistency, and security. The working group put > a lot of discussion into this, including changing from (1) to (2) and it’s > my sense that most agree we’ve landed in the right place. From a security > perspective, I don’t think that (3) is a viable option. > > > > If people think that the current semantics are right but are not > sufficiently clearly explained or motivated, I’d certainly welcome proposed > text to clarify the explanation. > > > > -- Mike > > > > *From:* Kathleen Moriarty [mailto:[email protected]] > *Sent:* Friday, September 12, 2014 5:00 AM > *To:* [email protected]; [email protected]; > [email protected]; [email protected]; Stephen > Kent; Mike Jones > *Subject:* JWK member names, was: [jose] SECDIR review of > draft-ietf-jose-json-web-key-31 > > > > Hi Mike, > > > > The text Steve called out below has been very problematic as you know. > Could you call out some options here as the last time this came up, we > didn't resolve it. The working group was asked for suggestions, but none > came through. If you could provide some options and then have the working > group weigh in, I think that would be good. > > > > I snipped away the rest of the review and changed the subject as not to > get in the way of the current dialog. > > > > Thanks. > > > > On Wed, Sep 10, 2014 at 8:57 PM, Mike Jones <[email protected]> > wrote: > > Hi Stephen. Thanks for your detailed and useful review. I’ve cc’ed the > working group in my reply so they’re aware of the contents of your review. > Replies are inline below… > > > > *From:* Stephen Kent [mailto:[email protected] <[email protected]>] > *Sent:* Tuesday, September 02, 2014 1:09 PM > *To:* [email protected]; Mike Jones; [email protected]; Moriarty, > Kathleen > *Subject:* SECDIR review of draft-ietf-jose-json-web-key-31 > > > > [snip] > > > > This section imposes a rather wimpy constraint on parameter names: > > > > The member names within a JWK MUST be unique; recipients MUST either > > reject JWKs with duplicate member names or use a JSON parser that > > returns only the lexically last duplicate member name, as specified > > in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]. > > > > This text says that member names MUST be unique, but if they are not, > that’s OK too; just use the last instance of a member with a duplicate > name. This seems like a terrible design principle. It imposes what appears > to be a requirement, then says how to accommodate data structures that fail > to meet the requirement. This would seem to encourage sloppy > implementations (for JWK generation). I’d like to see the rationale for > this. > > > > > > Unfortunately, the intentional laxness in the spec in this regard is a > reflection of the semantics of the actual JSON specifications and > implementations. For instance, > http://tools.ietf.org/html/rfc7159#section-4 says: > > > > An object whose names are all unique is interoperable in the sense > > that all software implementations receiving that object will agree on > > the name-value mappings. When the names within an object are not > > unique, the behavior of software that receives such an object is > > unpredictable. Many implementations report the last name/value pair > > only. Other implementations report an error or fail to parse the > > object, and some implementations report all of the name/value pairs, > > including duplicates. > > > > This topic has been heavily discussed by the working group, and while the > specs used to just say that objects with duplicate member names MUST be > rejected, working group members, including Tim Bray (the editor of the JSON > spec), prevailed on us to weaken this so that parsers that implement the > ECMAscript behavior of returning only the last member name may be legally > used. (The argument was made that there was more security downside in > effectively requiring people to write and debug their own strict parsers > than in using laxer, but well-supported and debugged parsers.) > > > > However, we also intentionally require that producers use only one > instance of each member name, so that legally produced objects will never > exercise the ambiguities that are present in real JSON parsers. That > seemed to be the most practical solution to the working group. > > > > [snip] > > Thanks again, > Stephen, > > -- Mike > > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > > > > > > -- > > > > Best regards, > > Kathleen > > > > > > -- > > > > Best regards, > > Kathleen > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > > -- - Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
