Subject: Re: [Json-canon] JSON Subtype handling. Re: Review of draft-rundgren-json-canonicalization-scheme-03

From: Jim Schaad <[email-masked]>
Date: Fri, 8 Feb 2019 21:10:48 -0800

Anders,

Two items.  First note that I changed the address of the IETF mailing list as the "-request" should be omitted.  This sends mail to the administrator not to the list.

Second.  I like the text that you have placed in Appendix E as it seems to do a good job of both describing the problem and providing a solution.  The problem is that it provides two different solutions and the reference from section 3.1 does not state which of the two methods to use.  I think you probably want to state - "Use Appendix E.2 for creation of new items, but use Appendix E.1 when parsing and checking an existing JSON serialization."

Jim

> -----Original Message-----
> From: Anders Rundgren <[email-masked]>
> Sent: Friday, February 8, 2019 8:54 PM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]; json-canon-
> [email-masked]; Mark Nottingham <[email-masked]>; Samuel Erdtman
> <[email-masked]>; Bret Jordan <[email-masked]>
> Subject: JSON Subtype handling. Re: Review of draft-rundgren-json-
> canonicalization-scheme-03
> 
> On 2019-01-26 03:10, Jim Schaad wrote:
> > Here are a set of comments on the current version of the draft.
> 
> Thank you very much for these insightful comments!
> 
> Since the comments were many I take the liberty splitting the responses in
> separate threads.
> 
> Handling of subtypes in JSON strings was clearly missing in the 03 draft.
> The 04 draft adds the following to section 3.1 "Creation of Input Data":
> 
>      Note: parsed String data MUST NOT be altered during subsequent
>      serializations.  For more information see Appendix E
> 
> The added Appendix E (https://tools.ietf.org/html/draft-rundgren-json-
> canonicalization-scheme-04#appendix-E)
> contains a pretty extensive description of how this must be dealt with.
> 
> A side-effect of this is that the updated draft now makes a distinction
> between "Hashable" JSON and "true" canonicalization ("Comparable" JSON).
> The latter is a more demanding deployment option.
> 
> Cheers,
> Anders

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 9 Feb 2019 07:10:20 +0100

> Two items.  First note that I changed the address of the IETF mailing list as the "-request" should be omitted.  This sends mail to the administrator not to the list.

Sorry, it was just a carbon copy of the original list of recipients..

> Second.  I like the text that you have placed in Appendix E as it seems to do a good job of both describing the problem and providing a solution.

Thanx!

> The problem is that it provides two different solutions and the reference from section 3.1 does not state which of the two methods to use.  I think you probably want to state - "Use Appendix E.2 for creation of new items, but use Appendix E.1 when parsing and checking an existing JSON serialization."

I believe this rather highlights a somewhat less clear part of the 04 draft: The distinction between "Hashable" and "Comparable" JSON.

Only "Comparable" JSON actually requires Appendix E.2 measures to function while "Hashable" JSON works with both.

These are effectively forming two levels of canonicalization:
- Hashable: JSON native level canonicalization only
- Comparable: Full canonicalization including custom data types

Anders

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 9 Feb 2019 08:05:31 +0100

All,
This is an open question.
Ideally you want a design to cover as many use-cases as possible, right?
Sometimes that ambition turns out to be counterproductive making your most important use-cases suffer.

When I in retrospect look at
https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-04
I begin to wonder if "Comparable" JSON (in the draft named "true" canonicalization) shouldn't be a "Feature at Risk" as the W3C folks call this.

Why is that?  Well, to begin with "Comparable" JSON leaves a lot of thorny decisions to some other document or entity to worry about:
https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-04#appendix-E.2

In addition, having actually built a few test systems comparing JSON data, I note that the possibility for creating 100% stable input data is unlikely to be particularly common. Time stamps, transaction IDs and last but not least crypto, makes this requirement rather hard to achieve in practice.

That is, "Comparable" JSON appears to be a difficult edge case and IMHO [probably] not worth dealing with. The 80/20 rule is pretty much a fact.

This seems like an ideal topic for the BoF session we have requested :-)

WDYT?

Anders

---

From: Bret Jordan <[email-masked]>
Date: Tue, 12 Feb 2019 07:55:22 -0700

I would rather focus on the key deliverable and punt on this for a future version. 

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."

> On Feb 9, 2019, at 12:05 AM, Anders Rundgren <[email-masked]> wrote:
> 
> All,

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 12 Feb 2019 18:02:15 +0100

> I begin to wonder if "Comparable" JSON (in the draft named "true" canonicalization) shouldn't be a "Feature at Risk" as the W3C folks call this.

Well, first of all, there is no “feature” here — the current draft just points out that deterministic encoding (“canonicalization”) reaches up to the application using JSON wherever that does its own encoding work.

That is a fact that is good to know, but nothing is contributed to interoperability by this document.

To do so, one would need a way to describe elements of the application data model and constrain the application data encoding decisions made on the way to the JSON data model.  We don’t have a good way to do this at the moment (even if the document misleadingly mentions the “schema” word).

Actually, the document about deterministic encoding of JSON (your “Hashable” thing — I still have no idea where these confused terms came from) could be stating this fact, if only as a matter of delineating what is *not* being defined in that document.

The document currently does not say how it was intended to be developed further.  As it stands, it is indeed of little use.  Collecting a set of preferred application-data-model to JSON-data-model encoding decisions, however, might be a useful undertaking, somewhat unrelated to the constraints on serializing the JSON data model that the other document wants to define, and probably on a much longer time scale.

Grüße, Carsten

---

From: Bret Jordan <[email-masked]>
Date: Wed, 13 Feb 2019 14:21:51 -0700

I am not sure I understand what you are proposing or what changes you would like.   I personally think that JCS should focus on a very limited and narrow set of use cases.  We should address how to represent JSON in a canonical form, period.  What people do with it beyond that is out-of-scope.

Thanks,
Bret

> On Feb 12, 2019, at 10:02 AM, Carsten Bormann <[email-masked]> wrote:
>

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 14 Feb 2019 07:03:31 +0100

Carsten,

Starting in another end...

As you probably know REST is a established way of architecting Web applications.  A fly in the soup is that there is no standard for creating signed REST requests.

Instead proprietary signature schemes based on detached clear text JSON data and HTTP bindings have become the norm while the JOSE WG has been concluded.  It has been claimed that the "right" solution (encoding and embedding the request data to be signed in the signature container itself) eventually will win.  However, I haven't seen this happening.  Maybe somebody can provide a link to such an activity?

In addition to be useful in entirely different contexts, JCS may function as a building block for future work in the REST space since it offers advantages over detached formats and HTTP bindings.

"Hashable" is a term I got from a related discussion on the ES-mozilla list.  In a JCS context "Hashable" means that a producer of (I-)JSON data can calculate a hash or signature over the data to be sent while the consumer of that data can use the hash or signature to verify the correctness of the received data. "Hashable" is obviously a lower form of canonicalization than required for comparing JSON data from arbitrary sources.

Regarding interoperability: With the (recently added...) constraint that the parsing of a JSON String followed by a serialization MUST return the same string you have together with the core JCS algorithm all the interoperability needed for supporting cryptographic methods.

Anders

---

From: Jim Schaad <[email-masked]>
Date: Sun, 17 Feb 2019 21:56:24 -0800

+1

What I care about here is JSON – there are a limited number of data types for JSON.  I don’t care about trying to shove other JavaScript types or C++ types into JSON strings.

Jim

From: json-canon <[email-masked]> On Behalf Of Bret Jordan
Sent: Wednesday, February 13, 2019 1:22 PM
To: Carsten Bormann <[email-masked]>
Cc: Samuel Erdtman <[email-masked]>; [email-masked]; Anders Rundgren <[email-masked]>
Subject: Re: [Json-canon] Dropping "Comparable" JSON

Thanks,

Bret

On Feb 12, 2019, at 10:02 AM, Carsten Bormann <[email-masked] <mailto:[email-masked]> > wrote:

On Feb 9, 2019, at 08:05, Anders Rundgren <[email-masked] <mailto:[email-masked]> > wrote:

Grüße, Carsten

---

From: Bret Jordan <[email-masked]>
Date: Mon, 18 Feb 2019 11:11:05 -0700

I fully agree Jim

Thanks,
Bret

> On Feb 17, 2019, at 10:56 PM, Jim Schaad <[email-masked]> wrote:
> 
> +1
>  
>> On Feb 12, 2019, at 10:02 AM, Carsten Bormann <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> On Feb 9, 2019, at 08:05, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>