On Sun, Mar 18, 2018 at 12:50 PM, Anders Rundgren < [email protected]> wrote:
> On 2018-03-18 15:13, Mike Samuel wrote: > >> >> >> On Sun, Mar 18, 2018 at 2:14 AM, Anders Rundgren < >> [email protected] <mailto:[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) >> > N. > To be completely honest I have only considered fullblown serializers and > they typically come in the mentioned size. > > Your solution have existed a couple days; we may need a little bit more > time thinking about it :-) > Fair enough. > > 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. >> > > Great! So we can finally put that argument to rest. > No. I don't disagree with you, but I don't speak for whoever did. > > >> 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 < >> 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? >> > > This proposal does [currently] not rely on canonicalization but on ES6 > "predictive parsing and serialization". > > > 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? >> > > A JSON canonicalization scheme has AFAIK never been considered in the > relevant IETF groups (JOSE+JSON). > On the contrary, it has been dismissed as a daft idea. > > I haven't yet submitted my [private] I-D. I'm basically here for > collecting input and finding possible collaborators. > > >> If so, please provide links to their reasoning. >> If not, how is their backing relevant? >> > > If ES6/JSON.stringify() way of serializing JSON primitives becomes an IETF > standard with backed by Microsoft, it may have an impact on the "market". > If you can't tell us anything concrete about your backers, what they back, or why they back it, then why bring it up? > >> 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. >> > > It is possible that I don't understand what you are asking for here since > I have no experience with toJSON. > > Based on this documentation > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe > rence/Global_Objects/JSON/stringify > JSON.canonicalize() would though work out of the box (when integrated in > the JSON object NB...) since it would inherit all the functionality (and > 99% of the code) of JSON.stringify() JSON.stringify(new Date()) has specific semantics because Date.prototype.toJSON has specific semantics. As currently written, JSON.canonicalize(new Date()) === JSON.canonicalize({}) > > > 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. >> > > Since you have already slashed my proposal there is probably not so much > consensus to find... > I didn't mean to slash anything. I like parts of your proposal and dislike others. I talk more about the bits that I don't like because that's the purpose of this list. For example, I like that it treats strings as sequences of UTF-16 code units instead of trying to normalize strings that may not encode human readable text.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
