Re: [jose] Canonical JSON form

Bret Jordan <> Fri, 12 October 2018 15:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42FEF130E22 for <>; Fri, 12 Oct 2018 08:21:00 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 tz6R-4noyQIs for <>; Fri, 12 Oct 2018 08:20:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC36A130DCB for <>; Fri, 12 Oct 2018 08:20:56 -0700 (PDT)
Received: by with SMTP id u88-v6so5068378ybi.0 for <>; Fri, 12 Oct 2018 08:20:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=l36UpJazaMV3ENpKOLD4FKK5kldqic/fto4seR0uJaI=; b=fXzKZcmLaz6BxDOfzkc+bPfujrz4bzcE013ZdIDk2jxHll1SpGQqbNEBVh8umxS+QU yQs0MhKGm7QJ20DZRRLgQ4173M03vPnABBTRU0fVDBtzScFSZ9/ze41Fr1fc67RKAxrc YzyJGSP/i8xk9VBXgTuRIFYUpARaaKexfl9YmiCNvylqfPGEliDbUp3pwe0mwEzqDVf6 u3oTksYAO7lmC+cf1eS2OiUP8bqLcwsefaaB0btti0trSZ07V79jqumars6G678lQSmP U+BrrckG64OqultMQZF69Bpab/m4LjSmB4BXCkGGnVu5UrFpmEP08Nt9dBkSH2ruLlFf U+7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=l36UpJazaMV3ENpKOLD4FKK5kldqic/fto4seR0uJaI=; b=Q32kr1LGkt1ickBA35ghAxLprMLr/fvXnC6+LysQsEc6BJ0dg7lsIUPCDiVLL+ztDh Ka4wJDu3jAFcqcuyJ792Lw3GJW9rsjEcqQQiBg1Nw7Z7YpA0bdF63wam+/ZRqJefWd6o yclRVVvDgsLrliVN1oM1G0JwRpKjA+z+t1uB0zEYP+2Nq3KU5ZReljjm/MCBJuxJdBWz 3HX10XvDnEkivlbzBOPs+w8j4S9Krn2T4PWkNEB9bEdwdsiZgrSD7ekBvdNgF2IlCTzW dYTr+jT5rH/wi0qarysGO+8+vbCAmzaFCt2Lx3TDsAvqk9JrFw4pBbjSqqXCs6LeTjmv b7hw==
X-Gm-Message-State: ABuFfojUoeoVNEkIJ9BWulkZ0nx9gM1JNvv0q6XIuRnaMR3sx2DFilBN I4eSK/LGP0NlpG0ZKN0F9PI=
X-Google-Smtp-Source: ACcGV61Ewz2cVVemJtuGgZOWKbPU9+lDbDGGg0P6SZ01RiYTjarcbiI7vGF37lgfPeYOnR8tCQK/jg==
X-Received: by 2002:a25:2c4c:: with SMTP id s73-v6mr3439903ybs.378.1539357656159; Fri, 12 Oct 2018 08:20:56 -0700 (PDT)
Received: from ?IPv6:2605:a601:3260:266:a165:a6bc:f6cb:dbc6? ([2605:a601:3260:266:a165:a6bc:f6cb:dbc6]) by with ESMTPSA id p185-v6sm353935ywc.14.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Oct 2018 08:20:54 -0700 (PDT)
From: Bret Jordan <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_904146E0-7798-4643-95ED-5EBF67837507"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 12 Oct 2018 09:20:19 -0600
In-Reply-To: <>
Cc: Carsten Bormann <>, Phil Hunt <>, Kathleen Moriarty <>, "Manger, James" <>,
To: Anders Rundgren <>
References: <> <> <> <> <00ad01d460f4$69ae8a00$3d0b9e00$> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [jose] Canonical JSON form
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: Fri, 12 Oct 2018 15:21:01 -0000

Please correct me if I am wrong…. The way I understand the problem is as follows:

1) If you verified the JSON string at consumption time, before it has been unmarshal-ed, then all you need to do is decide how to handle white space and carriage returns.  You could basically regex remove all white space and CR / CRLF and have a workable solution.

2) Where this breaks down is, when a tool unmarshals the data into a map or struct, then you have no guarantee that you would recreate the keys in the same order (a struct may force it to the order of the struct definition). So you have no way of being able to verify the hash after it has been unmarshal-ed.  Further, if you recreate the JSON and send it back out, the next person that gets the data might have a hash that can not be verified in option 1 above.

3) Another problem once you have unmarshal-ed the data is what do you do with JSON numbers.  Some programming languages store them as a float, some as who-knows-what.  So you would need a way to ensure that the number was always stored in the same way, especially for strongly typed systems (is this architecture dependent too?). So the options here are, if the ontology / semantics of the JSON data were well defined in schema (a meaning it was standardized and documented), then the code could know what it should do and interoperability tests could be made to ensure that it worked.

What am I not understanding here?  And what am I missing?

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 Oct 12, 2018, at 12:38 AM, Anders Rundgren <> wrote:
> On 2018-10-11 22:05, Bret Jordan wrote:
>> Anders,
>> I really like what you have done with this.  I am trying to figure out if it will work 100% for my needs, or if it will need some tweaking.  If it does work, then I think we should really try and figure out how we get your work standardized.
> Thanx Bret!
> The I-D provides quite a lot of features including an extension option that can be used for adding possibly missing functionality.
> There is one thing that is good to know for anyone thinking about standardizing Canonical JSON and that's the fact that canonicalization also can be performed on the text level as described by:
> This has the advantage that it is very simple and supports the entire JSON RFC without restrictions.
> So why didn't I took this [superficially obvious] route? There are several reasons for that:
> A downside of source level canonicalization is that it doesn't integrate with JSON parsers and serializers. was explicitly designed to eventually be an option of a standard JSON serializer as it already is in my Java reference implementation.
> Another issue is that it is unclear what the value is with using the JSON "Number" format outside of the IEEE range.  In fact, it excludes parsers like JavaScript's JSON.parse() unless JavaScaript would be updated to always use a "BigNumber" as fundamental numeric type.
> Regards,
> Anders