Subject: [jose] Performance of Canonical JSON

From: Anders Rundgren <[email-masked]>
Date: Fri, 7 Dec 2018 18:23:21 +0100

Since XML Canonicalization has a reputation of not only being brittle but also terribly slow, I tested JCS [1] with the following JSON file:
{
   "1": {"f": {"f": "hi","F": 5} ,"\n": 56.0},
   "10": { },
   "": "empty",
   "a": { },
   "111": [ {"e": "yes","E": "no" } ],
   "A": { }
}

Expected output: {"":"empty","1":{"\n":56,"f":{"F":5,"f":"hi"}},"10":{},"111":[{"E":"no","e":"yes"}],"A":{},"a":{}}

Since JCS only is a serialization concept (parsing is unaffected), I compared the execution speed of standard serialization versus canonicalized serialization.

Using https://www.npmjs.com/package/canonicalize the performance penalty was about 2.4 compared to JSON.stringify().
Using my homegrown JSON tools written in Java having an integrated "canonicalize" serializer option the performance penalty was about 1.4

Anders

1] https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01

---

From: Bret Jordan <[email-masked]>
Date: Fri, 7 Dec 2018 10:25:24 -0800

Thanks for the test data. Are you going to request a side meeting for Prague?

Bret 

Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

> On Dec 7, 2018, at 9:23 AM, Anders Rundgren <[email-masked]> wrote:
> 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 9 Dec 2018 11:22:07 +0100

> Thanks for the test data. Are you going to request a side meeting for Prague?

That's a good question. Since few have read the existing (somewhat constrained), serialization-only proposal [1], I'm considering other alternatives [4,5]

As you know REST [2] is currently held as the only "real" way architecting Web applications.  In spite of that, there is no standard for signing REST requests but signed REST requests are still used in the wild including by Amazon [3].

A rebooted JSON WG would likely settle on a full-fledged counterpart to XML's "CN14" which I have no interest in because it presumes that the canonicalization process is schema driven for both parsing and serialization, making deployment much more complex.

Anyway, IF there actually is GENUINE interest in a BoF session in Prague, could you guys on the list indicate your interest?

Thanx,
Anders

2] https://en.wikipedia.org/wiki/Representational_state_transfer

3] https://docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html

4] https://www.rfc-editor.org/about/independent/

5] Ignoring the standards process and rather let associated applications like https://cyberphone.github.io/doc/two-visions-4-mobile-payments.pdf set a de-facto standard.

> On Dec 7, 2018, at 9:23 AM, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> [email-masked] <mailto:[email-masked]>

---

From: Tim Bray <[email-masked]>
Date: Sun, 9 Dec 2018 10:19:16 -0800

Without addressing the rest of the question, your assertion that a
hypothetical JSON working group approach to c14n would take a schema-driven
approach is unsupported by evidence and I think very unlikely.  If only
because there is no JSON schema technology that has anything like consensus
support.

On Sun, Dec 9, 2018 at 2:22 AM Anders Rundgren <
[email-masked]> wrote:

> That's a good question. Since few have read the existing (somewhat
> constrained), serialization-only proposal [1], I'm considering other
> alternatives [4,5]
>
> As you know REST [2] is currently held as the only "real" way architecting
> Web applications.  In spite of that, there is no standard for signing REST
> requests but signed REST requests are still used in the wild including by
> Amazon [3].
>
> A rebooted JSON WG would likely settle on a full-fledged counterpart to
> XML's "CN14" which I have no interest in because it presumes that the
> canonicalization process is schema driven for both parsing and
> serialization, making deployment much more complex.
>
> Anyway, IF there actually is GENUINE interest in a BoF session in Prague,
> could you guys on the list indicate your interest?
>
> Thanx,
> Anders
>
> 1]
> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01
>
> 3]
> https://docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html
>
> 5] Ignoring the standards process and rather let associated applications
> like https://cyberphone.github.io/doc/two-visions-4-mobile-payments.pdf
> set a de-facto standard.
>
>
>
> >
> > Bret
> >
> > On Dec 7, 2018, at 9:23 AM, Anders Rundgren <
> [email-masked] <mailto:[email-masked]>>
> wrote:
> >
> >> Since XML Canonicalization has a reputation of not only being brittle
> but also terribly slow, I tested JCS [1] with the following JSON file:
> >> {
> >> Expected output:
> {"":"empty","1":{"\n":56,"f":{"F":5,"f":"hi"}},"10":{},"111":[{"E":"no","e":"yes"}],"A":{},"a":{}}
> >>
> >> Since JCS only is a serialization concept (parsing is unaffected), I
> compared the execution speed of standard serialization versus canonicalized
> serialization.
> >>
> >> Using https://www.npmjs.com/package/canonicalize the performance
> penalty was about 2.4 compared to JSON.stringify().
> >> Using my homegrown JSON tools written in Java having an integrated
> "canonicalize" serializer option the performance penalty was about 1.4
> >>
> >> Anders
> >>
> >> 1]
> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01
> >>

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 9 Dec 2018 21:41:36 +0100

On 2018-12-09 19:19, Tim Bray wrote:
> Without addressing the rest of the question, your assertion that a hypothetical JSON working group approach to c14n would take a schema-driven approach is unsupported by evidence and I think very unlikely.  If only because there is no JSON schema technology that has anything like consensus support.

Schema driven should in this context be interpreted as knowing in advance what to parse which I believe is necessary if the full JSON RFC is to be supported.  Several persons have indeed indicated that they consider a canonization scheme limited to strict I-JSON as insufficient.

I don't agree with that and have no intention working with such a proposal either.

Anders

> 
> On Sun, Dec 9, 2018 at 2:22 AM Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
> 
>      > On Dec 7, 2018, at 9:23 AM, Anders Rundgren <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> - Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)

---

From: Jim Schaad <[email-masked]>
Date: Sun, 9 Dec 2018 13:46:09 -0800

A side meeting does not need any permissions from the IESG, all that is needed is to decide on a time and place and announce it to the world.  At some point the extra rooms will be opened for reservation so you can ensure that you have a room.

Do not expect the same type of turnout for a side meeting that you would get for a BOF.  I have been to side meetings with as few as five people and as many as twenty, but it is generally on the lower side. If you are going to try for a BOF, expect that the cutoff date is going to be around the first of February.  At a minimum you would need to have a good description of the problem and scope you want to cover.  You do not need to have a regular IETF goer make the request, this is open to anybody.  Instructions can be found here https://www.ietf.org/how/bofs/.

Jim

From: jose <[email-masked]> On Behalf Of Bret Jordan
Sent: Friday, December 7, 2018 10:25 AM
To: Anders Rundgren <[email-masked]>
Cc: [email-masked]
Subject: Re: [jose] Performance of Canonical JSON

Bret 

On Dec 7, 2018, at 9:23 AM, Anders Rundgren <[email-masked] <mailto:[email-masked]> > wrote:

Anders

---

From: Bret Jordan <[email-masked]>
Date: Sun, 9 Dec 2018 19:53:42 -0700

I have need of this for projects inside and outside the IETF.  So I would be highly in favor of a BOF or side meeting to work on this and talk through what is possible, what is needed, and where we go from here. 

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 Dec 9, 2018, at 3:22 AM, Anders Rundgren <[email-masked]> wrote:
>