Canonical JSON is often used to imply a security property: two JSON blobs with identical contents are expected to have identical canonical JSON forms (and thus identical hashed values).
However, unicode normalization allows multiple representations of "the same" string, which defeats this security property. Depending on your implementation language and use, a string with precomposed accepts could compare equal to a string with separated accents, even though the canonical JSON or hash differed. In an extreme case (with a weak hash function, say MD5), this can be used to break security by re-encoding all strings in multiple variants until a collision is found. This is just a slight variant on the fact that JSON allows multiple ways to encode a character using escape sequences. You've already taken the trouble to disambiguate this case; security-conscious applications should take care to perform unicode normalization as well, for the same reason. Similarly, if you don't offer a verifier to ensure that the input is in "canonical JSON" format, then an attacker can try to create collisions by violating the rules of canonical JSON format, whether by using different escape sequences, adding whitespace, etc. This can be used to make JSON which is "the same" appear "different", violating the intent of the canonicalization. Any security application of canonical JSON will require a strict mode for JSON.parse() as well as a strict mode for JSON.stringify(). --scott On Fri, Mar 16, 2018 at 4:48 AM, Anders Rundgren < [email protected]> wrote: > On 2018-03-16 08:52, C. Scott Ananian wrote: > >> See http://wiki.laptop.org/go/Canonical_JSON -- you should probably at >> least >> mention unicode normalization of strings. >> > > Yes, I could add that unicode normalization of strings is out of scope for > this specification. > > > You probably should also specify a validator: it doesn't matter if you >> emit canonical JSON if you can tweak the hash of the value by feeding >> non-canonical JSON as an input. >> > > Pardon me, but I don't understand what you are writing here. > > Hash functions only "raison d'être" are providing collision safe checksums. > > thanx, > Anders > > > --scott >> >> On Fri, Mar 16, 2018 at 3:16 AM, Anders Rundgren < >> [email protected] <mailto:[email protected]>> >> wrote: >> >> Dear List, >> >> Here is a proposal that I would be very happy getting feedback on >> since it builds on ES but is not (at all) limited to ES. >> >> The request is for a complement to the ES "JSON" object called >> canonicalize() which would have identical parameters to the existing >> stringify() method. >> >> The JSON canonicalization scheme (including ES code for emulating >> it), is described in: >> https://cyberphone.github.io/doc/security/draft-rundgren-jso >> n-canonicalization-scheme.html <https://cyberphone.github.io/ >> doc/security/draft-rundgren-json-canonicalization-scheme.html> >> >> Current workspace: https://github.com/cyberphone/ >> json-canonicalization <https://github.com/cyberphone >> /json-canonicalization> >> >> Thanx, >> Anders Rundgren >> _______________________________________________ >> es-discuss mailing list >> [email protected] <mailto:[email protected]> >> https://mail.mozilla.org/listinfo/es-discuss < >> https://mail.mozilla.org/listinfo/es-discuss> >> >> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
