On 2015-10-26 00:10, Manger, James wrote:
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.

Hi James,
Thanx for pointing out this, it is apparently always a very good idea testing 
concepts with other knowledgeable people before you actually start building 
something :-)

I guess the ES committee wasn't entirely happy about having to adjust their 
spec. due to improper reliance on JavaScript property order by parts of the 
development community.  But they probably did the right thing.

I'm thinking in a similar way.  Why let an edge-case spoil all the fun?  Maybe the ES6 
vendors implement the same broken ToString algorithm or the improved version mentioned as 
a note after the section you referred to?  I won't research this issue now because I 
consider Ecma the sole "owner" of this problem :-)

So this is my (latest) suggestion for an upgraded in-object JSON clear-text 
signature specification:

    "Due to limitations in the EcmaScript V6 [ECMA-262] specification regarding
     the ToString(number) method, it is for interoperability reasons RECOMMENDED
     to utilize a maximum of 18 digits of precision for non-integer Numbers."

It sure isn't pretty but since "business messaging" can't even use JSON/ES 
numbers for expressing monetary amounts, it is hardly a show-stopper.

Anders Rundgren



James Manger

-----Original Message-----
From: jose [mailto:[email protected]] On Behalf Of Anders Rundgren
Sent: Monday, 26 October 2015 2:33 AM
To: [email protected]; [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to