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. 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-compatible/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(). thanx, Anders _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
