Re: [jose] Canonical JSON form

Anders Rundgren <anders.rundgren.net@gmail.com> Mon, 22 October 2018 05:04 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 5555C130DC0 for <jose@ietfa.amsl.com>; Sun, 21 Oct 2018 22:04:24 -0700 (PDT)
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 wIhlBxWx_Wli for <jose@ietfa.amsl.com>; Sun, 21 Oct 2018 22:04:21 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 4FC2112F1AC for <jose@ietf.org>; Sun, 21 Oct 2018 22:04:21 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id u1-v6so7541985wrn.0 for <jose@ietf.org>; Sun, 21 Oct 2018 22:04:21 -0700 (PDT)
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=rUu5LMyaO35rFOUX67XvfpdujRv4ofsZzBWQrdOR9JM=; b=Z37t15Cnd7LAtgEe7pFc73jJOTowGo046g5qRY82LkFBzRfbL25KKqANuRWoWzPapD RhX7vmiX5nqQM9PeUiQSiI/FaohETZ4JLOCyg1lpzBZaj0GmVs2MEFCHR2LBlPDqHXIh bwlybLVZuSKsF6ThU8+BSeIEIsKMQWMC2qRCTLOqXITeiPIMV90ENnGy/f/qJ8N8uFF2 XmZbNmX3KlqoUz0+7dRXoYDlMcvv14AvrChZI0OpBWRprSSglkuEkDu3t90iRb6PfCIG KvyLznCzdcmyxFV9rm0fu4V0v/LpGkF7QNOHUz3+iOjb3FA3VMTjbWMVqKbVxLA9xTa/ 5JOQ==
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=rUu5LMyaO35rFOUX67XvfpdujRv4ofsZzBWQrdOR9JM=; b=TgbBaE+WCQkPjD4WiuEmo5j+qydWxvbOggGa9Pg4CN00jw9v7HmASrbxKIaocuXAMx /bCqpvdRG0m9wyJSiZ4WzyQJK5v3KdHJvw16LIsIXdmkywkWepzz1oPP7qPYrIwt2aEe RnmRk/0KxPcIvpvMWpNKQ9Mbi5rb39iGbDTN6bJvD8NbEEDOXgrksagLZOTeHizEW5ZA +UE+W2vlNHPuI7wfI36XlKuZXooHMX+aVav7+ybBiJxYcyLJxO8mVTCwxtowrcRxd6/R GS2P5fATSDTWmlbAMK+H0dQMd5G/47RJqqSGd5WzHxegVWSW2FpdMqUU1cIpHbh/+4Sl LZaA==
X-Gm-Message-State: AGRZ1gJlRgrBaB0VyZRt4RAlyOVfyIOMjQrhe/q5qFzIWrfqTh5ioK5T yKoU+eZh9XVIc3/UlKvIvevRF/7y
X-Google-Smtp-Source: AJdET5cVHGniaLvNj06Jqhg4yxyKCy0b7E2nxeft1jZESPhLB6NK8wELl638S/xVlRPf/F9yXg5ckA==
X-Received: by 2002:adf:e74c:: with SMTP id c12-v6mr6277935wrn.182.1540184659666; Sun, 21 Oct 2018 22:04:19 -0700 (PDT)
Received: from [192.168.10.182] (217.17.136.77.rev.sfr.net. [77.136.17.217]) by smtp.googlemail.com with ESMTPSA id y41-v6sm21482141wrd.25.2018.10.21.22.04.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Oct 2018 22:04:18 -0700 (PDT)
To: David Waite <david@alkaline-solutions.com>
Cc: Bret Jordan <jordan.ietf@gmail.com>, Carsten Bormann <cabo@tzi.org>, "Manger, James" <James.H.Manger@team.telstra.com>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, jose@ietf.org, Phil Hunt <phil.hunt@oracle.com>
References: <12DD2F97-80C3-4606-9C6B-03F7A4BF19DE@gmail.com> <00ad01d460f4$69ae8a00$3d0b9e00$@augustcellars.com> <8436AEE7-B25A-4538-B8F6-16D558D9A504@gmail.com> <MEAPR01MB35428606C09BF315DE04CC79E5E10@MEAPR01MB3542.ausprd01.prod.outlook.com> <CAHbuEH6DCD7Zc+PK3TnCBkKv1esnROwyCcDb8ZR+TKwgQQ+yXQ@mail.gmail.com> <0E6BD488-74D5-4640-BC31-5E45B0531AFC@gmail.com> <CAHbuEH5oH-Km6uAjrSr0pEHswFBLuDpfVweQ+gpj472yk+8iTQ@mail.gmail.com> <073CB50F-8D91-4EF6-90BE-FC897D557AA6@oracle.com> <A37D69B1-6B77-4E11-8BB9-A0209C77752C@tzi.org> <45bf6c0f-e510-4afc-4277-bdd486a8ce8c@gmail.com> <213796DB-D875-46B0-9F3C-1A56F9E154BA@gmail.com> <ff1dcd4e-2bf4-b85b-dde3-2cc8fe29fb17@gmail.com> <447AB837-7208-4A96-91CC-89D30A2734FA@gmail.com> <24cc6bb7-ea40-1a9c-8847-8d6c74131587@gmail.com> <92B9F9AF-BBCA-472D-9155-935F695CE7CE@gmail.com> <3b6a338b-5588-deb2-9a9c-23e0cc24a2f1@gmail.com> <FE6C1732-D16A-4D97-99F4-1350AF23A748@alkaline-solutions.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <eeffdd73-f866-6df7-fc18-25508be6d66c@gmail.com>
Date: Mon, 22 Oct 2018 07:04:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <FE6C1732-D16A-4D97-99F4-1350AF23A748@alkaline-solutions.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/9yh42dB_UfA3iMb9hm_PQPHEfVs>
Subject: Re: [jose] Canonical JSON form
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, 22 Oct 2018 05:04:24 -0000

Dear David et al,
I believe we all know IETF's position on this topic by now.

Anyway, there is considerable interest maintaining the core quality of text based messages (human readability) also for signed data, leading to various quests for alternative solutions.

To give some kind of perspective on the complexity, my C#/.NET implementation [1] weighs in at 30 Kb of executable code.

It took 3 complete revisions and five calendar years to get to this point but it was (hopefully) worth it :-)

Thanks,
Anders
1] https://github.com/cyberphone/json-canonicalization/tree/master/dotnet

On 2018-10-22 04:47, David Waite wrote:
> 
> 
>> On Oct 19, 2018, at 10:55 PM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>>
>> There is also a (very active) W3C community group working with a similar concept so clear-text signatures based on JSON canonicalization will probably reach the market regardless of IETF's position on the matter: https://w3c-dvcg.github.io/ld-signatures/
>>
> 
> This document is not on a standards track. The group which published this it is not a standards group. So this isn’t currently on track to reach the market as a IETF or W3 standard.
> 
> It also is based on RDF canonicalization; it canonicalized a specific format expressed in JSON, not arbitrary JSON.
> 
> That isn't to say that there couldn’t be multiple canonicalization formats supported, possibly built as filters so you could combine them together, such as existed with XML-DSIG. Then you have a compatibility matrix to deal with.
> 
> This still doesn’t solve the problem that many internal representations of JSON will not preserve the full data set you are representing in your canonical form.
> 
>  From my development experience with XML-DSIG, this is most commonly that tools will discard information they do not understand, such as properties which aren’t part of the public schema. For developers who do not understand the additional restrictions a cleartext signature is placing on them, this causes issues that only come up late in broad interoperability testing, that can only be resolved through per-vendor workarounds or reimplementation to use different tools. This actually occurred multiple times across different implementations, sometimes when leveraging libraries that did claim to preserve the full information set of the XML document.
> 
>> The 1 million of random and "edge" JSON Numbers used for testing the devised JSON canonicalization scheme, uncovered flaws in other systems as well...
>> https://github.com/dotnet/coreclr/issues/17467
> 
> This yet another case against canonical JSON, is it not? Or rather, how are people expected to deal with intermittent interoperability failures until a new language runtime release which revises the numerical print and parse functions comes out?
> 
> -DW