Re: [dispatch] PING2. Re: JSON Canonicalization Standard

Anders Rundgren <> Thu, 06 September 2018 05:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6968130E82 for <>; Wed, 5 Sep 2018 22:56:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XndpYb0H2zEa for <>; Wed, 5 Sep 2018 22:56:52 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20AEA130E9A for <>; Wed, 5 Sep 2018 22:56:52 -0700 (PDT)
Received: by with SMTP id e1-v6so886838wrt.3 for <>; Wed, 05 Sep 2018 22:56:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=k67BW4HtoUp0EjECgqMuhualdzdL2K8myi4FQ1BBx4E=; b=OeaAGUHgQjpc1Ug1rpSWSPWhfvFn4Nb8BWcyKcUig8awoB6VlqJsjYCPnr1Zg8M/2V e1Ek+zC+BD/ientZF/L1zFrufQU9gYTeLBkM3gifSny66oxcVWyfQU00zFKfQ3w7FeCG mrnPLWoXS1xzC3FR8mXWHf5ZsVBAlifbRbncSOQfFQc1STEX5EgHCMpA2NrLnZ/uX3VW 7lI9TJ7chAKV5fNrH+xhK8Zf9Ys9ha9x70zVTiRh0uUNEV3CMQLjRZOMGuJUAmdZEmGU 0aSFwP878tzihVg4t2jArurqmroUJCzSgJjo+ACc08M0VpJgDFmyODyAjf0XnHG3uTD6 7tQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=k67BW4HtoUp0EjECgqMuhualdzdL2K8myi4FQ1BBx4E=; b=S0WcPwRcnsjBrLSQHWtU00leux6cvP5ozezBNRCNmGgh/0H4ZV7fDNgCIHpkOjyHf6 Ziwo5Sx0Vxbnp2VH8H65y8wfAEzgIV8HBbxwF+Tq/Y8eXYRBgPLf++lzGlxM00N0srQA JBJCEcT8c5lr/P/dhkfvj9QYBFEwfmNEXni4WthPUwFAp84q33Dfcw9tlR4ivkegy3Cy e76EgUN5QQODBoNbIxs8BxfK/xOLS46hxW/pjuM544n5/Tvz8eiHYP97mSmOJQugkowQ jG2VUaUDjzothZNheYRu1T5Ahs8bwcm3gldk8ewZ6n2mici3+1FqGx3srWxI18yOzbrG RCjw==
X-Gm-Message-State: APzg51A9HZbVgdrvl+Bff0PB6n3ADxrrAJESye66xh9JkH2F9sDAx5FB cKX9axtmaWoMYK+dlPKSMHd1XyHi
X-Google-Smtp-Source: ANB0VdZji60SOQvHhOsMV8mksPfuVPsOTHpDs7e2j15LN+FcS5lqnPrCLHnGsamzO6DI3xXYLx44WQ==
X-Received: by 2002:adf:f8ca:: with SMTP id f10-v6mr915356wrq.237.1536213409739; Wed, 05 Sep 2018 22:56:49 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id b10-v6sm5008162wmc.28.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Sep 2018 22:56:48 -0700 (PDT)
To: Larry Masinter <>,
References: <> <> <00d601d4456d$32356960$96a03c20$>
From: Anders Rundgren <>
Message-ID: <>
Date: Thu, 06 Sep 2018 07:56:43 +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: <00d601d4456d$32356960$96a03c20$>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [dispatch] PING2. Re: JSON Canonicalization Standard
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Sep 2018 05:57:05 -0000

On 2018-09-06 01:07, Larry Masinter wrote:
> A canonicalization of a space should apply to all valid values, and
> shouldn't map two semantically different values to the same canonical form.

I don't understand what you are referring to here since white space is
insignificant in JSON.

> JSON intentionally allows large integers and floating point numbers outside
> of IEEE range of capabilities (1e400, 99999999999999999999).
> While some implementations will coerce values and round off, I think a good
> canonicalization should leave these values intact, if you're want a JSON
> canonicalization rather than an "ES6 value serialization" canonicalization
> (a strict subset).

The rationale for the IEEE-754 double precision/ES6 restriction used in the I-D
is that this is (AFAIK) the de-facto scheme for current IETF standards defining
JSON objects including such that use big numbers like RSA parameters.

Another reason for taking this route is that using the full JSON Number
notation would require the canonicalizer to work on the text level only
since it is incompatible with most current JSON Parsers (all that do not
use an unlimited BigNumber as underlying JSON Number type).

The JCS scheme is designed to ultimately be integrated in JSON serializers
(only) as an output option.

Although it is considerably easier defining a free-standing canonicalizer
scheme like it might end-up
getting limited industry support.  The JOSE folks slashed an earlier effort of
mine requiring requiring JSON text preservation. In particular, dealing with
active intermediaries was considered a showstopper.

JWS+JCS combo:
On-line testing:
> _______________________________________________
> dispatch mailing list