Subject: [Json-canon] Proposed Charter

From: Bret Jordan <[email-masked]>
Date: Thu, 24 Jan 2019 19:56:48 +0100

All,

Here is a proposed charter for this WG.  Please send any comments on this charter to this email list. 

### BEGIN

JavaScript Object Notation (JSON) is a text format for the serialization of structured data described in RFC 8259. The JSON format is often used for serializing and transmitting structured data over a network connection. With the increased usage of JSON in protocols in the IETF and elsewhere, there is now a need to define a canonical representation of JSON objects to enable comparison operations and security services on plain text JSON. 

Different proposals for providing such security services have already been defined and implemented. The goal of the Working Group is to define and standardize a mechanism for creating a canonical representation of plain text JSON objects.

This group is chartered to work on the following deliverable:

- A Standards Track document specifying a canonical representation of JSON data.

In order to promote interoperability and ease of implementation, the current proposal builds on I-JSON (RFC 7493), the serialization methods for JSON primitives defined by EcmaScript version 6, and a platform-independent method for sorting object properties.  By doing that, JSON parsers will not need modifications, enabling the described mechanism to ultimately be reduced to an option in JSON serializers.

The proposed work-item is tentatively named JSON Canonicalization Scheme (JCS)

### END

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 24 Jan 2019 22:48:06 +0100

https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-03

Abstract:
    Cryptographic operations like hashing and signing requires that the
    original data does not change during serialization or parsing.  By
    applying the rules defined by the JSON Canonicalization Scheme (JCS),
    data provided in JSON [RFC8259] format can be exchanged "as is",
    while still being usable by secure cryptographic operations.  JCS
    achieves this by building on the serialization formats for JSON
    primitives as defined by ECMAScript [ES6], constraining JSON data to
    the I-JSON [RFC7493] subset, and through a platform independent
    property sorting scheme.

    The intended audiences of this document are JSON tool vendors, as
    well as designers of JSON based cryptographic solutions.

Enjoy!

Anders for the team

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Jan 2019 13:55:10 -0800

Will the Working Group limit itself to canonicalising the data model that's described by JSON's native data types (object, array, number, string, boolean, null), or will it attempt to canonicalise subtypes -- for example, inside strings (whether they be key or value)?

I'd be much more comfortable if this were addressed explicitly in the charter.

Cheers,

> On 24 Jan 2019, at 10:56 am, Bret Jordan <[email-masked]> wrote:
> 
> All,
> 
> -- 
> json-canon mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json-canon

--
Mark Nottingham   https://www.mnot.net/

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 24 Jan 2019 23:06:19 +0100

> Will the Working Group limit itself to canonicalising the data model that's described by JSON's native data types (object, array, number, string, boolean, null), or will it attempt to canonicalise…

It is possible that I misunderstand your question but the charter talks about using

"...the serialization methods for JSON primitives defined by EcmaScript version 6"

which means that strings and numbers are normalized (null and boolean already have a fixed form).

Is this the explanation you miss?

thanx,
Anders

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Jan 2019 14:14:38 -0800

I saw that, but it wasn't clear whether that was a starting point, or a limit.

Cheers,

> On 24 Jan 2019, at 2:06 pm, Anders Rundgren <[email-masked]> wrote:
>

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 24 Jan 2019 23:40:08 +0100

> I saw that, but it wasn't clear whether that was a starting point, or a limit.

It is the current proposal/definition.  It limits the JSON Number type to IEEE-754 double precision (=strict I-JSON).

https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-03#section-3.2.2.3

Do you think this should be in the charter?

thanx,
Anders

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Jan 2019 14:42:23 -0800

I'm primarily concerned that people will want to invite new subtypes, e.g. "base64'd binary in a string." A good charter would make that clearly in or out of scope.

Cheers,

> On 24 Jan 2019, at 2:40 pm, Anders Rundgren <[email-masked]> wrote:
>

---

From: Allan Thomson <[email-masked]>
Date: Thu, 24 Jan 2019 22:46:44 +0000

Currently, many *do* define base64 binary as strings in JSON and this effort would be more useful to them if it included them.

I'm not sure why we would want to be so prescriptive or restrictive on every last data type. It seems like if a reasonable use case requires a data type being included then having to redo the charter just to include it seems cumbersome.

Allan

On 1/24/19, 2:42 PM, "json-canon on behalf of Mark Nottingham" <[email-masked] on behalf of [email-masked]> wrote:

    Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Jan 2019 14:49:06 -0800

I wasn't suggesting that every possible data type be in the charter; it just seems good to set expectations about whether they're allowed at *all* (and if they are, perhaps some sort of general parameters for what's in-scope).

> On 24 Jan 2019, at 2:46 pm, Allan Thomson <[email-masked]> wrote:
>

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 24 Jan 2019 23:53:15 +0100

> I'm primarily concerned that people will want to invite new subtypes, e.g. "base64'd binary in a string." A good charter would make that clearly in or out of scope.

Aah, is that what you meant!  Well, interpretation of data in strings is for sure out of scope.  We'll find some way to express this.  Thanx.

As Allan Thomson just mentioned, people indeed encode a lot of things inside of strings and this works just fine, the canonicalizer only see a string.

thanx,
Anders

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 25 Jan 2019 00:15:06 +0100

> I wasn't suggesting that every possible data type be in the charter; it just seems good to set expectations about whether they're allowed at *all* (and if they are, perhaps some sort of general par…

For the primary application of this spec, "hashable JSON", there is no need to bother about anything but the core primitives.

For sub-type strings like a hypothetical BigNumber, a comparison between "3e+500" and "3.0e+500" wont work as expected.

Thanx, this will obviously be needed in the charter as well as in an updated draft!

Anders