Re: [Json] JSON Concluded? Well, maybe not

[Anders Rundgren <[e-mail]>]

Dear Richard,

I'm in no way against an RFC for canonical JSON. On the contrary, I whish you luck with your JSON canonicalization endeavors!

There is no real disconnect, there is a difference in opinion of what is [most] important.

In my opinion a cross-platform system based on JSON messaging MUST consider the limitations in both ECMAScript JSON processing and in JSON itself.  The latter are quite severe and every now and then cause people starting new projects to "fix JSON" like: https://www.tjson.org/

Creating a signature scheme relying on ECMAScript JSON processing rules may indeed be regarded as a short-cut, but availability typically trumps perfection.

Anders

On 2018-01-03 18:25, Richard Gibson wrote:
> I'm really not sure where the disconnect between us is coming from... JSON specifies unordered keys for objects, arbitrary-precision numbers, and strings that can contain code points excluded from UTF-8. As such, ECMAScript JSON.stringify is *not* suitable for JSON canonicalization, though it may suffice for certain Javascript-centric or otherwise restricted subsets thereof as addressed by JOSE. I believe that a general solution like http://gibson042.github.io/canonicaljson-spec/ is needed to avoid this seemingly endless series of special cases [1] [2] [3] [etc] (including those that have nothing to do with cryptographic signatures or encryption), and therefore wish to work towards an RFC describing it. There's no problem if you're uninterested, or even if you believe that a general solution is unwarranted, but there _is_ a problem if you believe that JSON.stringify already provides one.
> 
> [1]: https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00
> [2]: https://tools.ietf.org/html/rfc7638#section-3.3
> [3]: https://keybase.io/docs/api/1.0/canonical_packings#json
> [etc]: http://wiki.laptop.org/go/Canonical_JSON
> 
> On Wed, Jan 3, 2018 at 2:06 AM, Anders Rundgren <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     On 2018-01-02 17:33, Richard Gibson wrote:
> 
>     <snip>
> 
>         JSON.stringify assumes information that is explicitly not conveyed by JSON (in which an object is "an unordered collection of zero or more name/value pairs") [1], and both its number serialization [2]
>         and string serialization [3] specify aspects that harm compatibility
>         (the former having arbitrary value-dependent branches, the latter being
>         capable of producing invalid UTF-8 octet sequences that represent unpaired
>         surrogate code points—unacceptable for exchange outside of a closed
>         ecosystem [4]). JSON is a general language-agnostic interchange format,
>         and ECMAScript JSON.stringify is *not* a JSON canonicalization solution.
> 
>         [1]: https://tools.ietf.org/html/rfc8259#section-1 <https://tools.ietf.org/html/rfc8259#section-1>
>         [2]: http://ecma-international.org/ecma-262/7.0/#sec-tostring-applied-to-the-number-type <http://ecma-international.org/ecma-262/7.0/#sec-tostring-applied-to-the-number-type>
>         [3]: http://ecma-international.org/ecma-262/7.0/#sec-quotejsonstring <http://ecma-international.org/ecma-262/7.0/#sec-quotejsonstring>
>         [4]: https://tools.ietf.org/html/rfc8259#section-8.1 <https://tools.ietf.org/html/rfc8259#section-8.1>
> 
> 
>     JSON is a format defined the IETF and ECMA in some kind of cooperation.
> 
>     ECMA's ECMAScript defines a set of ("fairly" easy to implement) JSON processing rules which are fully compatible [1] with the JSON format.
> 
>     The idea using ES6+ number normalization was originally proposed by an esteemed member of the now concluded JOSE WG:
>     https://www.ietf.org/mail-archive/web/jose/current/msg05323.html <https://www.ietf.org/mail-archive/web/jose/current/msg05323.html>
> 
>     Following that path, I (accidentally) discovered the "missing link", ES6+'s preservation [2] of the original property ordering which in my mind is quite logical [3] for "ordinary" JSON usage as well.
> 
>     A Java based reference implementation has been successfully tested against Chrome, Node.js, Firefox and Safari.
> 
>     Feel free taking a test ride on: https://mobilepki.org/jose-jcs/home <https://mobilepki.org/jose-jcs/home>
>     Note that it outlaws signing a JSON "Number" expressed as "1.0" since the correct (according to ES6+) representation is "1".
> 
>     Anders
> 
>     1] possibly with the exception of "unpaired surrogate code points" which I admittedly know zilch about
>     2] with properties named as integers as a for practical purposes insignificant exception
>     3] Making data come out in the order it was specified addresses human aspects like debugging and documentation of JSON data
> 
>