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]<mailto:[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]]
Sent: Tuesday, September 02, 2014 1:09 PM
To: [email protected]<mailto:[email protected]>; Mike Jones;
[email protected]<mailto:[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]<mailto:[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
