Re: [Json] [jose] EcmaScript V6 - Defined Property Order

"Manger, James" <James.H.Manger@team.telstra.com> Sun, 25 October 2015 23:10 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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2210A1B3346 for <json@ietfa.amsl.com>; Sun, 25 Oct 2015 16:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.902
X-Spam-Level:
X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no
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 VkI_ehryMKXv for <json@ietfa.amsl.com>; Sun, 25 Oct 2015 16:10:45 -0700 (PDT)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 223F71B3344 for <json@ietf.org>; Sun, 25 Oct 2015 16:10:44 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.20,198,1444654800"; d="scan'208";a="34669436"
Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 26 Oct 2015 10:10:41 +1100
X-IronPort-AV: E=McAfee;i="5700,7163,7965"; a="331556597"
Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipccvi.tcif.telstra.com.au with ESMTP; 26 Oct 2015 10:10:41 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Mon, 26 Oct 2015 10:10:40 +1100
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>, "json@ietf.org" <json@ietf.org>
Date: Mon, 26 Oct 2015 10:10:37 +1100
Thread-Topic: [jose] EcmaScript V6 - Defined Property Order
Thread-Index: AdEPOmjXLZmwIwhmQxSI92S/9J0VkwANwI1w
Message-ID: <255B9BB34FB7D647A506DC292726F6E13BB107BC65@WSMSG3153V.srv.dir.telstra.com>
References: <562C9C1F.6020507@gmail.com> <562CF614.4020200@gmail.com>
In-Reply-To: <562CF614.4020200@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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/PWTz63VyaL8LALFcXQrPum0D23U>
Subject: Re: [Json] [jose] EcmaScript V6 - Defined Property Order
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Sun, 25 Oct 2015 23:10:47 -0000

Hi Anders,

I agree that the EcmaScript string format for numbers is a better basis for a canonical JSON format than, say, normalized scientific notation - particularly for the dominant case of integers less than 2^64. However, EcmaScript's ToString(number) doesn't quite give a canonical form. 7.1.12.1 step 5 says "the least significant digit of s is not necessarily uniquely determined by these criteria". EcmaScript guarantees that ToNumber(ToString(x)) gives the same number x, but that is not quite what we need for signing. We need ToString(ToNumber(s)) to give the same string. I guess you could sign the 8 bytes of a 64-bit float, instead of the JSON decimal digits.

James Manger

-----Original Message-----
From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders Rundgren
Sent: Monday, 26 October 2015 2:33 AM
To: jose@ietf.org; json@ietf.org
Subject: Re: [jose] EcmaScript V6 - Defined Property Order

Since the ES6 Number type is 64-bit IEEE, there's no need to worry about number canonicalization either if you base the signature system on ES6 which seems like a pretty safe bet.

http://www.ecma-international.org/ecma-262/6.0/index.html#sec-tostring-applied-to-the-number-type

That is, AFAICT, clear-text in-object JSON signatures are already compatible with ES6 (and I must drop my "number preservation" stuff...).

Folks working with constrained devices will probably settle for CBOR.

On 2015-10-25 10:08, Anders Rundgren wrote:
> http://www.ecma-international.org/ecma-262/6.0/index.html#sec-ordinary-object-internal-methods-and-internal-slots-ownpropertykeys
>
> I can't say I'm able "deciphering" the ES6 specification but it seems that the largest base of JSON parsers (the browsers), now are compliant with in-object JSON clear-text signature schemes of the kind I have proposed (pushing maybe...), albeit with some (IMO for practical purposes insignificant) limitations:
>
> - Integer property names doesn't work.
> - Numeric values would have to be normalized.
>
> Java, Python, and C# already manages this as well.
>
> Yay!
>
> Anders
>

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose