On Fri, Mar 16, 2018 at 9:42 PM, Anders Rundgren < [email protected]> wrote:
> Scott A: > https://en.wikipedia.org/wiki/Security_level > "For example, SHA-256 offers 128-bit collision resistance" > That is, the claims that there are cryptographic issues w.r.t. to Unicode > Normalization are (fortunately) incorrect. > Well, if you actually do normalize Unicode, signatures would indeed break, > so you don't. > > Richard G: > Is the [highly involuntary] "inspiration" to the JSON.canonicalize() > proposal: > https://www.ietf.org/mail-archive/web/json/current/msg04257.html > Why not fork your go library? Then there would be three implementations! > > Mike S: > Wants to build a 2000+ line standalone JSON canonicalizer working on > string data. > That's great but I think that it will be a hard sell getting these guys > accept the Pull Request: > https://developers.google.com/v8/ > JSON.canonicalize(JSON.parse("json string data to be canonicalized")) > would IMHO do the same job. > My (working) code example was only provided to show the principle as well > as being able to test/verify. > I don't know where you get the 2000+ line number. https://gist.github.com/mikesamuel/20710f94a53e440691f04bf79bc3d756 comes in at 80 lines. That's roughly twice as long as your demonstrably broken example code, but far shorter than the number you provided. If you're being hyperbolic, please stop. If that was a genuine guesstimate, but you just happened to be off by a factor of 25, then I have less confidence that you can weigh the design complexity tradeoffs when comparing your's to other proposals. > On my part I added canonicalization to my ES6.JSON compliant Java-based > JSON tools. A single line did 99% of the job: > https://github.com/cyberphone/openkeystore/blob/jose-compati > ble/library/src/org/webpki/json/JSONObjectWriter.java#L928 for (String property : canonicalized ? new TreeSet<String>(object.properties.keySet()) > : object.properties.keySet()) { > > > Other mentioned issues like HTML safety, embedded nulls etc. would apply > to JSON.stringify() as well. > JSON.canonicalize() would inherit all the features (and weaknesses) of > JSON.stringify(). > Please, when you attribute a summary to me, don't ignore the summary that I myself wrote of my arguments. You're ignoring the context. JSON.canonicalize is not generally useful because it undoes safety precautions. That tied into one argument of mine that you left out: JSON.canonicalize is not generally useful. It should probably not be used as a wire or storage format, and is entirely unsuitable for embedding into other commonly used web application languages. You also make no mention of backwards compatibility concerns when this depends on things like toJSON, which is hugely important when dealing with long lived hashes. When I see that you've summarized my own thoughts incorrectly, even though I provided you with a summary of my own arguments, I lose confidence that you've correctly summarized other's positions.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
