The approach just seems wrong. If we require that conforming implementations MUST NOT emit dupes, then authors of receiving software can just pick the best-performing parser with the nicest API, because they *all* perform correctly when there are no dupes.
Who’s going to own the responsibility for making the authoritative finding that of the many JSON parsers in the Java ecosystem, these ones, but not those ones, are usable in JOSE applications? And suppose one that has been previously OK is quietly optimized on GitHub to run 30% faster and as a side-effect silently ignores dupes? The benefit of using JSON is that there is widely deployed software to handle it. It is a known problem that sloppy spec drafting has allowed various kinds of problems to occur when dupe keys are received. “Doctor, it hurts when I do this.” “So... don’t do that.” Are we also going to specify the behavior of receiving software when the JSON has a misplaced quotation mark? A missing trailing “}”? -T On Wed, Jun 26, 2013 at 11:29 PM, Manger, James H < [email protected]> wrote: > Most JSON libraries that silently accept [sob] dupe keys at least > consistently use the last key. Allowing just that behaviour (or rejecting > dupes), while forbidding acceptance of a non-last dupe (eg first key), is > safe and allows most JSON libraries to be used. Since this accepts most > libraries I think it is practical.**** > > ** ** > > Hence I suggest:**** > > ** ** > > > A creator of a JOSE message MUST NOT put duplicate names in any JSON** > ** > > > object in a JOSE header.**** > > > To prevent attacks where a JOSE message is interpreted as different*** > * > > > valid messages by different recipients, each recipient MUST either**** > > > reject messages with duplicate names or accept only the last name.**** > > ** ** > > This isn’t “truly predictable” as a message with dupes might be accepted > or rejected. The crucial point is that if a message is accepted it is > predictable.**** > > ** ** > > --**** > > James Manger**** > > ** ** > > *From:* Tim Bray [mailto:[email protected]] > *Sent:* Thursday, 27 June 2013 4:16 PM > *To:* Manger, James H > *Cc:* Mike Jones; Jim Schaad; [email protected]; > [email protected] > > *Subject:* Re: [jose] #27: member names MUST be unique needs additional > text**** > > ** ** > > Well, you have a practical problem in that most implementers will want to > use a standard JSON library, which is good practice because it will be > well-debugged, and most libraries [sob] silently take care of dupe keys and > don’t have a way to tell the client software what happened. So if you want > truly predictable behavior, you’re forcing the use of hand-constructed JSON > parsers. And that sucks, because getting good performance in JSON parsing > is surprisingly hard, with dramatic performance differences between > implementations. So you’re forcing receiving software which wants to be > conformant to use a hand-rolled parser which will probably have lousy > performance and have other bugs which in fact may compromise security more > than dupe-key tricks could. -T**** > > ** ** > > On Wed, Jun 26, 2013 at 10:39 PM, Manger, James H < > [email protected]> wrote:**** > > > 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**** > > Clean and minimal that may be, but it ignores the security issue. We don't > want a malicious producer (who is so malicious they ignore a MUST) to > create JOSE messages that a JOSE-compliant security layer accepts as > "benign interpretation #1" so it passes the message on to the > JOSE-compliant backend app that acts on "nasty interpretation #2". > > -- > James Manger**** > > ** ** >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
