Subject: [dispatch] PING. Re: JSON Canonicalization Standard

From: Anders Rundgren <[email-masked]>
Date: Sun, 2 Sep 2018 21:35:19 +0200

On 2018-08-11 07:47, Anders Rundgren wrote:
> Hi Dispatchers,
> 
> I'm currently trying to develop a JSON Canonicalization Standard as an individual effort: https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01
> I have been asked by the individual submission editor to get feedback from the SEC and ART directors but they in turn have directed me to the DISPATCH forum, and here I am :-)
> 
> There are efforts creating an alternative to JOSE JWS since there are JSON-based protocols not benefiting from being cast into a form converting signed JSON messages into something completely alien to their unsigned counterpart.  However, after a number of iterations and vendor feedback, I have come to the conclusion that the "Missing Link" is not necessary a new signature format but a way to canonicalize [*] JSON data.
> 
> The scheme is currently implemented in Java, C#/.NET, Python3 and EcmaScript V6 (https://www.npmjs.com/package/canonicalize).
> 
> Related: https://github.com/cyberphone/jws-jcs#combining-detached-jws-with-jcs-json-canonicalization-scheme
> If you want to test the jws-jcs signature scheme, an on-line demo is currently available at: https://mobilepki.org/jws-jcs/home
> 
> What do you think?
> 
> Sincerely,
> Anders Rundgren
> 
> *] The goal is rather creating a "hashable" JSON representation but since the described scheme does not change data, these terms are effectively interchangeable.
>

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 5 Sep 2018 07:31:30 +0200

Apparently my message was too complex and required the reader to follow links so here is short version:

Assume that you have a JSON object like:
  {
    "statement": "Hello signed world!",
    "otherProperties": [2e+3, true]
  }

Signing using JOSE/JWS you would get:
eyJhbGciOiJIUzI1NiIsImtpZCI6Im15a2V5In0.eyJvdGhlclByb3BlcnRpZXMiOlsyMDAwLHRydWVdLCJzdG
F0ZW1lbnQiOiJIZWxsbyBzaWduZWQgd29ybGQhIn0.FcE8h0GXJaOZ4Th3fNDBgcBE5HfEplOnS8GGtoSLU1K

That is, something entirely different.

Using unmodified JOSE/JWS + JCS (the specification I'm talking about) you would rather get:
  {
    "statement": "Hello signed world!",
    "otherProperties": [2e+3, true],
    "signature": "eyJhbGciOiJIUzI1NiIsImtpZCI6Im15a2V5In0..5HfEplOnS8GGtoSLU1KFcE8h0GXJaOZ4Th3fNDBgcBE"
  }

JCS is quite similar to its XML counterpart, albeit much simpler. Signed XML data never needed to be Base64 encoded.

Anders
I-D: https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01
More on the JWS+JCS combo: https://github.com/cyberphone/jws-jcs#combining-detached-jws-with-jcs-json-canonicalization-scheme
On-line testing: https://mobilepki.org/jws-jcs/home

---

From: Larry Masinter <[email-masked]>
Date: Wed, 5 Sep 2018 16:07:18 -0700

A canonicalization of a space should apply to all valid values, and
shouldn't map two semantically different values to the same canonical form.

JSON intentionally allows large integers and floating point numbers outside
of IEEE range of capabilities (1e400, 99999999999999999999).
 
While some implementations will coerce values and round off, I think a good
canonicalization should leave these values intact, if you're want a JSON
canonicalization rather than an "ES6 value serialization" canonicalization
(a strict subset).

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 6 Sep 2018 07:56:43 +0200

> shouldn't map two semantically different values to the same canonical form.

I don't understand what you are referring to here since white space is
insignificant in JSON.

> canonicalization rather than an "ES6 value serialization" canonicalization

The rationale for the IEEE-754 double precision/ES6 restriction used in the I-D
is that this is (AFAIK) the de-facto scheme for current IETF standards defining
JSON objects including such that use big numbers like RSA parameters.

Another reason for taking this route is that using the full JSON Number
notation would require the canonicalizer to work on the text level only
since it is incompatible with most current JSON Parsers (all that do not
use an unlimited BigNumber as underlying JSON Number type).

The JCS scheme is designed to ultimately be integrated in JSON serializers
(only) as an output option.

Although it is considerably easier defining a free-standing canonicalizer
scheme like https://gibson042.github.io/canonicaljson-spec/ it might end-up
getting limited industry support.  The JOSE folks slashed an earlier effort of
mine requiring requiring JSON text preservation. In particular, dealing with
active intermediaries was considered a showstopper.

Anders
I-D: https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01
JWS+JCS combo: https://github.com/cyberphone/jws-jcs#combining-detached-jws-with-jcs-json-canonicalization-scheme
On-line testing: https://mobilepki.org/jws-jcs/home
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>