Re: [jose] Performance of Canonical JSON

Anders Rundgren <anders.rundgren.net@gmail.com> Sun, 09 December 2018 20:41 UTC

Return-Path: <anders.rundgren.net@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 AA6001288EB for <jose@ietfa.amsl.com>; Sun, 9 Dec 2018 12:41:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 XeW5N-K0gat5 for <jose@ietfa.amsl.com>; Sun, 9 Dec 2018 12:41:44 -0800 (PST)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 43C2312008A for <jose@ietf.org>; Sun, 9 Dec 2018 12:41:44 -0800 (PST)
Received: by mail-wr1-x42c.google.com with SMTP id z5so8462736wrt.11 for <jose@ietf.org>; Sun, 09 Dec 2018 12:41:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3DG7pioVEboiZ76iEZsOQylrA4a7+nZB/o7yF4PMVyo=; b=NeVUAyXBBbUvCz7vRVWYP83PAuH1XH+4Gd8+y+ZhgqVT84BgTJ2CTHb8gx2hkDFHkE ARVnoS5T28qgm3sX3Wwx4ud5L0whr4UjE5JW/8I37RTspMKRIKWtqXwKS1i58Ng+MqhJ 5wpZWGO/khk2yIZXGET5MoLwd8F9E3glmhSgBoSyFbJdFBIch7+xx2CxKQmKaax6eEUd Qb2TSqoq0s34OUPYofC/TR8X93BD7cmItKybDZ9qEafNNhndhBpYVYC3I+kREuWjD0mi DggCMISygCEMB29jOlm3RyUCuqTxVl7tx4qb5JknzyyELzJRL5C0PPgWM9DUZTDtF/DX OkLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3DG7pioVEboiZ76iEZsOQylrA4a7+nZB/o7yF4PMVyo=; b=Au1ILOwmJDtlPrPYxfisDwM40TFegj3pNJ8H/L3YorNahByfhXQcH4YjpECS+s80Ya nf8pGqURTbXeso0sTrwJRHp4RqcVEf2cWji7eWAWUTwi2u/2vHNJmPDvp92yj3qEHdAD kbwdd3Rt1+oUvkF5DYWiDGEt5LHgiL7ySCDoZgoqJ5dG+TrHMJJCiP/EfOqrdWvzJa5V DkCmgZ0sj36LbLh5/SdGHRhNTrxQfAVBswnqwmdaRa1b5stxl3bEt6kCjnCC+qHn06SR CQLVqiSWZR1oLDgeafAKnBVOOOqpJRbIRAAQ1LyEkT5OFCIkIon8OIl8p0haPLDWXmwH zycQ==
X-Gm-Message-State: AA+aEWZyKMlbYni98deedX4zkSQ9Cq0+WzsXGBD8XPcFe/OhW4px6T05 zBfDQebggO56sXGSuwe7D8eB9g6e
X-Google-Smtp-Source: AFSGD/VzK01nNs7U1Z91cgup5pzF1or0qP3SjEqVYYk/xENWoPijJzQBrquMgPIGMklkMyf3m1+GhQ==
X-Received: by 2002:adf:b716:: with SMTP id l22mr8222545wre.186.1544388101815; Sun, 09 Dec 2018 12:41:41 -0800 (PST)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id j33sm19819999wre.91.2018.12.09.12.41.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Dec 2018 12:41:40 -0800 (PST)
To: Tim Bray <tbray@textuality.com>, Carsten Bormann <cabo@tzi.org>
Cc: Bret Jordan <jordan.ietf@gmail.com>, jose <jose@ietf.org>
References: <3466a48c-115d-3810-4c94-0e213ba407fd@gmail.com> <3386D76C-D8FA-43CA-9B4A-B171C6B61267@gmail.com> <2121e4c8-2abd-4478-98b6-a2b3a7029bbc@gmail.com> <CAHBU6ivMa_hwdFudzywKbGK2AP1-O+1+r=eG0o9gtqmEVEkzXw@mail.gmail.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <0b0caf7d-02ba-84b7-9304-4ca9537a5188@gmail.com>
Date: Sun, 9 Dec 2018 21:41:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <CAHBU6ivMa_hwdFudzywKbGK2AP1-O+1+r=eG0o9gtqmEVEkzXw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/Er5yEg3KmxI2d9RTBYOB00l88mY>
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: Sun, 09 Dec 2018 20:41:47 -0000

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 <anders.rundgren.net@gmail.com <mailto: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> <mailto: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> <mailto:jose@ietf.org <mailto:jose@ietf.org>>
>      >> https://www.ietf.org/mailman/listinfo/jose
> 
>     _______________________________________________
>     jose mailing list
>     jose@ietf.org <mailto:jose@ietf.org>
>     https://www.ietf.org/mailman/listinfo/jose
> 
> 
> 
> -- 
> - Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)