Re: [Json] The names within an object SHOULD be unique.

[Stefan Drees <[e-mail]>]

On 2013-06-07 17:19, Stephen Dolan wrote:
> On Jun 7, 2013, at 5:22 AM, Stefan Drees ... wrote:
>>
>> Which b.t.w. I would certainly rewrite as:
>>
>> NEW
>> """
>> Generators SHOULD NOT duplicate names in objects. Parsers MUST be
>> prepared to either accept duplicate names in objects or reject the
>> complete JSON text containing these, as a generator might not avoid nor
>> detect such duplication.
>> """

Please note: The above proposal has already been split and updated upon 
request of "Vinny A" as the spec separates Parser and Generator sections.

> Regarding duplicate keys, the issue was raised before that having
> multiple valid interpretations of an input leads to security problems.
> Consider this document:
>
>      {"command": "no-op", "user": "untrustworthy-person", "command":
> "launch-missiles"}
>
> if submitted to a system which separates authorization from execution,
> where both use JSON implementations which differ in their
> interpretation of duplicate keys, this could end badly.
>
> There are some JSON implementations which preserve duplicate keys, and
> many which don't. However, I know of no implementation which
> interprets {"a":2, "a":1} as {"a":2} - the implementations I've seen
> keep either all or just the last entry. Codifying this behaviour in
> the RFC would help to prevent the security issue described above, so
> how about some text along the lines of:
>
>      If an object contains several key-value entries with the same key,
> a JSON parser MAY ignore all but the last of these entries. A JSON
> parser MUST NOT ignore the last such entry. ...

I do think, that forcing the consumer to "keep" the last parsed 
(whatever this means from the perspective of the source of the message) 
name as "the one" is **not** "good", nor "more secure" nor "doesn't 
break anything in the wild".

A "source of the message" shall indicate, that this is not a format 
concern, but one of the sender and receivers rules.
Say e.g. a program running on node A has a list of names and these have 
values attached. The names are not unique (thus a list ;-) if this 
program decides to send this information through a JSON data 
interchange, when selecting the JSON type object, it does so knowingly, 
that the order of members in a JSON object is undefined, so there is IMO 
no principal security dilemma in ordering, but in ambiguity of a message 
that would have better been build with a unique set of names from the start.

As has been noted in many differnt mails already here on this list, we 
have no time-machine and somehow have to deal with that :-)

All the best,
Stefan.