IETF Logo Mail Archive

Re: [Json] Canonicalization

"Manger, James H" <James.H.Manger@team.telstra.com> Wed, 20 February 2013 03:49 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4A021F880B for <json@ietfa.amsl.com>; Tue, 19 Feb 2013 19:49:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level:
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQ3fiZt6hMcJ for <json@ietfa.amsl.com>; Tue, 19 Feb 2013 19:49:45 -0800 (PST)
Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id DE70C21F86C1 for <json@ietf.org>; Tue, 19 Feb 2013 19:49:44 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.84,699,1355058000"; d="scan'208,217"; a="119085965"
Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 20 Feb 2013 14:49:44 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6991"; a="113056484"
Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcdvi.tcif.telstra.com.au with ESMTP; 20 Feb 2013 14:49:43 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Wed, 20 Feb 2013 14:49:43 +1100
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "json@ietf.org" <json@ietf.org>
Date: Wed, 20 Feb 2013 14:49:42 +1100
Thread-Topic: [Json] Canonicalization
Thread-Index: Ac4PGOx5tPNV0qKyTuSar4EaUQ612wAAOEBQ
Message-ID: <255B9BB34FB7D647A506DC292726F6E115076344B3@WSMSG3153V.srv.dir.telstra.com>
References: <BF7E36B9C495A6468E8EC573603ED9411513E818@xmb-aln-x11.cisco.com> <A723FC6ECC552A4D8C8249D9E07425A70F897263@xmb-rcd-x10.cisco.com> <255B9BB34FB7D647A506DC292726F6E11507579808@WSMSG3153V.srv.dir.telstra.com> <1F2DF9AD-EE7A-4CC6-BBA6-AF07D02347F9@vpnc.org> <CAK3OfOhkSdi_4kuM3SG2N=bcfAwE-3E9+_SWW8ULSfedO8HAkQ@mail.gmail.com> <2510D743-1CCE-42D0-9067-836F03BDD606@vpnc.org> <CALcybBDfyDGh-Gt9v-94OBM7XFzzSwywZJW_fECuig6hrN0cCw@mail.gmail.com> <1361323974.9790.41.camel@pbryan-wsl.internal.salesforce.com> <CALcybBAkJg1JyMwPc-xsCv_GvROPE696-4ak8YqaO2vXcQ+QHA@mail.gmail.com> <CALcybBAyc1CcaH1_yyg8AQ9=SM6Tn7+1mbtQL+b9910ojuvbqQ@mail.gmail.com> <CAK3OfOjo36iw5cpwowKRUWOgXd9L-M6bOX4qc8_hrdscbAQbiQ@mail.gmail.com> <CALcybBB2KowXG+vYeJHjDUOqdZMPy0mQOpxHf8ioe3eWAVb0uw@mail.gmail.com> <CAK3OfOjz1TPbhFggz5ADh-4eEQC1iDVAbRYWWfpU7US79ao-3w@mail.gmail.com> <CAHBU6ivcdo7HB6qoD5WfW4NN8-nc0aKj6quqWsuNQH7N=7jnJA@mail.gmail.com>
In-Reply-To: <CAHBU6ivcdo7HB6qoD5WfW4NN8-nc0aKj6quqWsuNQH7N=7jnJA@mail.gmail.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E115076344B3WSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: Re: [Json] Canonicalization
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Feb 2013 03:49:46 -0000

> OK, this discussion has convinced me that there’s no real need for this group to proactively take up JSON c14n.  If at some future point there’s a strong demonstrated real (not hypothetical) use case, it’s a fairly tractable problem.  But for now, it’s unnecessary work.

There is interest in JSON canonicalization, despite the trepidation: draft-staykov-hu-json-canonical-form; this email discussion; http://wiki.laptop.org/go/Canonical_JSON; discussions in JOSE WG; http://stackoverflow.com/questions/4670494/how-to-cryptographically-hash-a-json-object; a couple of github projects; bencode.

Add to that the fact that it was felt necessary to define c14n for XML and ASN.1 BER (DER and CER).

C14n has caused lots of pain so a JSON c14n spec should have a big warning up front to use c14n sparingly, only where other protocol choices are worse.

Various JSON c14n proposals so far agree on the basics (sort objects keys, no extra white space, 1 form for numbers), but skimp on some fine details (which chars to escape, escape as \uxxxx or \x, floating point numbers). A spec to fix those details for interoperability seems like a good thing to do at the IETF; now.

draft-staykov-hu-json-canonical-form is 4 pages (including boilerplate, examples, everything). It needs a few more to nail down the details.

I recommend adding JSON c14n to the charter.

--
James Manger

From: json-bounces@ietf.org [mailto:json-bounces@ietf.org] On Behalf Of Tim Bray
Sent: Wednesday, 20 February 2013 2:18 PM
To: Nico Williams
Cc: Francis Galiegue; Paul Hoffman; Paul C. Bryan; json@ietf.org
Subject: Re: [Json] Canonicalization

OK, this discussion has convinced me that there’s no real need for this group to proactively take up JSON c14n.  If at some future point there’s a strong demonstrated real (not hypothetical) use case, it’s a fairly tractable problem.  But for now, it’s unnecessary work.
-T

v2.23.0 | Report a Bug | By Email