Re: [jose] Performance of Canonical JSON

Bret Jordan <jordan.ietf@gmail.com> Mon, 10 December 2018 02:54 UTC

Return-Path: <jordan.ietf@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D54130E3C for <jose@ietfa.amsl.com>; Sun, 9 Dec 2018 18:54:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idHmCqScKpsm for <jose@ietfa.amsl.com>; Sun, 9 Dec 2018 18:54:16 -0800 (PST)
Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739C1126C01 for <jose@ietf.org>; Sun, 9 Dec 2018 18:54:16 -0800 (PST)
Received: by mail-yw1-xc29.google.com with SMTP id h32so3397302ywk.2 for <jose@ietf.org>; Sun, 09 Dec 2018 18:54:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KbiVubg8YdhkL5giV84kArqRSc3aR7c/flewP5Do/mM=; b=tjeWhd/E9jMf5TVlQkED4pF1Qb0PxZUq3pTtSNwIuckdaC0Gl/mLkA6gEblfI1lPMe zfxu7KzdYU8AW2EcnmTXz5mZEzMtkKyiCbktzhi3Tdtv9try/4tfIouK0l+xHR51KF31 cQjIHKdNibhT8Z2zmpdi5rhQIor37dK+/0aMfRQj6PSf9Ij+By0nDP/Lh5rCIitDjXJu u/QfnO9w+Y9IwtRaLpV6gY8cGdfIsk0VsrZRJpGjCVfO8NAiQdBKYNuPaH+dPanlBZeY f48gfn5Q/6jL3Ocdievax9QkfC0hfEH7g7zRD7P5WwLmRuRBibH3lxeCWOfqBEFtNiIm p4CA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KbiVubg8YdhkL5giV84kArqRSc3aR7c/flewP5Do/mM=; b=qZ7ynMmayX4iKaRFsMx1vMSg6rhGKjvYPD1UpjYtqAZgFSj6rkdFgz8QDgagpEgG1e 0AOjwdlyEKTToHEQO23qbJ0zCx+HVKIDnGs//et16+KRWFt3bkh+q78OWixPmz2JHgKo q9HbYlmLzxR3DGpGZ7SwYyDtyBI1WSDG3dX1VsfGAZX/32BwHSV2jOJ1X7/fuqNgrrTU fDYpGnxKd/kwjWXDdseKI+F9MUh/7z9VCPqWnzbr7/CM0kq0qqEQRxCjpqp4wUuuUtAB zKmcWBKbEeMkNdRQQ4bO+hGXIAzO/pROfXfNYth5Q1Uf/+l+o/JdIOqueQKVtw/pULAp Vsfg==
X-Gm-Message-State: AA+aEWbH6bCZE7d395J0wcwIsTdg3AU2X4qAS3AWjEYE8700XQYMcy1X WKOmaQH0YxemDhYem/NUAxg=
X-Google-Smtp-Source: AFSGD/VN6Jb2wKwURkzvbYyzb6M0AOYPvqHACLftEX9coIfYURajp5En/39J0T6oKgXu2zw5hvZs1w==
X-Received: by 2002:a81:a48f:: with SMTP id b137mr11074991ywh.120.1544410455667; Sun, 09 Dec 2018 18:54:15 -0800 (PST)
Received: from ?IPv6:2605:a601:a028:986:10bc:dd50:b849:41a3? ([2605:a601:a028:986:10bc:dd50:b849:41a3]) by smtp.gmail.com with ESMTPSA id v202sm3371848ywv.19.2018.12.09.18.54.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Dec 2018 18:54:14 -0800 (PST)
From: Bret Jordan <jordan.ietf@gmail.com>
Message-Id: <7BE1E32E-1BD9-49A7-9C4A-EC7285F2E79B@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F6F35C2F-E9E0-4E95-AF7D-4F841C4AE2D5"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Sun, 9 Dec 2018 19:53:42 -0700
In-Reply-To: <2121e4c8-2abd-4478-98b6-a2b3a7029bbc@gmail.com>
Cc: "jose@ietf.org" <jose@ietf.org>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
References: <3466a48c-115d-3810-4c94-0e213ba407fd@gmail.com> <3386D76C-D8FA-43CA-9B4A-B171C6B61267@gmail.com> <2121e4c8-2abd-4478-98b6-a2b3a7029bbc@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/Z0EqCNjK4Uvz-4ceOIP9728d9UU>
Subject: Re: [jose] Performance of Canonical JSON
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Dec 2018 02:54:19 -0000

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 <anders.rundgren.net@gmail.com> wrote:
> 
> On 2018-12-07 19:25, Bret Jordan wrote:
>> 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
> 
> 1] https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01
> 
> 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.
> 
> 
> 
>> 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 <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> 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 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
>>> 
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org <mailto:jose@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/jose
>