Re: [jose] Performance of Canonical JSON

Jim Schaad <> Sun, 09 December 2018 21:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5674B128CF3 for <>; Sun, 9 Dec 2018 13:46:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8GhD1pQbI0EZ for <>; Sun, 9 Dec 2018 13:46:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5A3C128CE4 for <>; Sun, 9 Dec 2018 13:46:19 -0800 (PST)
Received: from Jude ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 9 Dec 2018 13:41:14 -0800
From: Jim Schaad <>
To: 'Bret Jordan' <>, 'Anders Rundgren' <>
CC: <>
References: <> <>
In-Reply-To: <>
Date: Sun, 9 Dec 2018 13:46:09 -0800
Message-ID: <01ae01d49008$9a81e850$cf85b8f0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AF_01D48FC5.8C5F92B0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQDz4ccxT8I6pmSOce5DyMsUul9lHQLq8Z/RpyD0UuA=
Content-Language: en-us
X-Originating-IP: []
Archived-At: <>
Subject: Re: [jose] Performance of Canonical JSON
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 09 Dec 2018 21:46:22 -0000

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





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


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



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



jose mailing list <>