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
