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

Richard Gibson <richard.gibson@gmail.com> Wed, 03 January 2018 17:25 UTC

MIME-Version: 1.0
In-Reply-To: <15337fea-5cec-0306-939b-df40b3a367d6@gmail.com>
References: <13860352-ef8e-1d4b-2eff-27e275c25e3a@gmail.com> <CALH+fvqBGu0i=LcciYgOLSwbQJXfqgcXTdd=rxvfHfqiRyBj7g@mail.gmail.com> <CAHBU6itC+XAKhc_m_ywG5O2bpky9DnmzfiNVqP3WrxLaE7uenA@mail.gmail.com> <92077f95-5dd6-3f5b-4765-d14067f698ac@dret.net> <CADEL5zshRaHtVNAtNggwHaPKP9xWeePcBZcQc1EM8SEfUu41Uw@mail.gmail.com> <CALH+fvqkBkQCiXfx1cxXaX092sbW6fgUmUizXP1f=ScMZ3bBqQ@mail.gmail.com> <cb1ce20d-67f0-f4f4-8077-57c3d3f232b7@gmail.com> <CALH+fvqpaT0b8AfPigk93Fy5hhWFthiFJSfaMmkttpMgqiMvQw@mail.gmail.com> <15337fea-5cec-0306-939b-df40b3a367d6@gmail.com>
From: Richard Gibson <richard.gibson@gmail.com>
Date: Wed, 03 Jan 2018 12:25:02 -0500
Message-ID: <CALH+fvrmLf0qwhWYn2YQx7f=jzo9O00tcJmMiGgG32wjXf9gHA@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: JSON WG <json@ietf.org>
Content-Type: multipart/alternative; boundary="001a11444aecf038100561e27e11"
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/oP3Dny4TcfUXPa1hht7l59UKI10>
Subject: Re: [Json] JSON Concluded? Well, maybe not
Precedence: list

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 <
anders.rundgren.net@gmail.com> 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
>> [2]: http://ecma-international.org/ecma-262/7.0/#sec-tostring-app
>> lied-to-the-number-type
>> [3]: http://ecma-international.org/ecma-262/7.0/#sec-quotejsonstring
>> [4]: 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
>
> 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
> 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
>

[Json] JSON Concluded? Well, maybe not Anders Rundgren
Re: [Json] JSON Concluded? Well, maybe not Richard Gibson
Re: [Json] JSON Concluded? Well, maybe not Tim Bray
Re: [Json] JSON Concluded? Well, maybe not Phillip Hallam-Baker
Re: [Json] JSON Concluded? Well, maybe not Erik Wilde
Re: [Json] JSON Concluded? Well, maybe not Anders Rundgren
Re: [Json] JSON Concluded? Well, maybe not Richard Gibson
Re: [Json] JSON Concluded? Well, maybe not Phillip Hallam-Baker
Re: [Json] JSON Concluded? Well, maybe not Anders Rundgren
Re: [Json] JSON Concluded? Well, maybe not Phillip Hallam-Baker
Re: [Json] JSON Concluded? Well, maybe not Anders Rundgren
Re: [Json] JSON Schema (Was: JSON Concluded? Well… Pete Cordell
Re: [Json] JSON Concluded? Well, maybe not Phillip Hallam-Baker
Re: [Json] JSON Concluded? Well, maybe not Anders Rundgren
Re: [Json] JSON Concluded? Well, maybe not Richard Gibson
Re: [Json] JSON Concluded? Well, maybe not Anders Rundgren
Re: [Json] JSON Concluded? Well, maybe not Richard Gibson
Re: [Json] JSON Concluded? Well, maybe not Anders Rundgren