On Sun, Mar 18, 2018 at 2:14 AM, Anders Rundgren < [email protected]> wrote:
> Hi Guys, > > Pardon me if you think I was hyperbolic, > The discussion got derailed by the bogus claims about hash functions' > vulnerability. > I didn't say I "think" you were being hyperbolic. I asked whether you were. You asserted a number that seemed high to me. I demonstrated it was high by a factor of at least 25 by showing an implementation that used 80 lines instead of the 2000 you said was required. If you're going to put out a number as a reason to dismiss an argument, you should own it or retract it. Were you being hyperbolic? (Y/N) Your claim and my counterclaim are in no way linked to hash function vulnerability. I never weighed in on that claim and have already granted that hashable JSON is a worthwhile use case. > F.Y.I: Using ES6 serialization methods for JSON primitive types is headed > for standardization in the IETF. > https://www.ietf.org/mail-archive/web/jose/current/msg05716.html > > This effort is backed by one of the main authors behind the current > de-facto standard for Signed and Encrypted JSON, aka JOSE. > If this is in your opinion is a bad idea, now is the right time to shoot > it down :-) > Does this main author prefer your particular JSON canonicalization scheme to others? Is this an informed opinion based on flaws in the others that make them less suitable for JOSE's needs that are not present in the scheme you back? If so, please provide links to their reasoning. If not, how is their backing relevant? > This efforts also exploits the ability of JSON.parse() and > JSON.stringify() honoring object "Creation Order". > > JSON.canonicalize() would be a "Sorting" alternative to "Creation Order" > offering certain advantages with limiting deployment impact to JSON > serializers as the most important one. > > The ["completely broken"] sample code was only submitted as a > proof-of-concept. I'm sure you JS gurus can do this way better than I :-) > This is a misquote. No-one has said your sample code was completely broken. Neither your sample code nor the spec deals with toJSON. At some point you're going to have to address that if you want to keep your proposal moving forward. No amount of JS guru-ry is going to save your sample code from a specification bug. > Creating an alternative based on [1,2,3] seems like a rather daunting task. > Maybe if you spend more time laying out the criteria on which a successful proposal should be judged, we could move towards consensus on this claim. As it is, I have only your say so but I have reason to doubt your evaluation of task complexity unless you were being hyperbolic before.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
