Subject: [Json] Bug in RFC7493 (I-JSON)?

From: Anders Rundgren <[email-masked]>
Date: Sun, 6 May 2018 08:21:00 +0200

During testing of the JSON canonicalizer [1,2] I tried with an integer just above the specified limit (2**53) + 1 and to my surprise it didn't fail.
A short run with an IEEE-754/ES6 debugger seemed to confirm that +-2**53 is the actual limit for integers.

Input floating point: 9007199254740991
Output floating point: 9007199254740991
Hex value: 433fffffffffffff
Binary value: 0 10000110011 1111111111111111111111111111111111111111111111111111

Input floating point: 9007199254740992
Output floating point: 9007199254740992
Hex value: 4340000000000000
Binary value: 0 10000110100 0000000000000000000000000000000000000000000000000000

Anders

1] https://github.com/cyberphone/json-canonicalization#json-canonicalization
2] https://cyberphone.github.io/doc/security/draft-rundgren-json-canonicalization-scheme.html

---

From: Tim Bray <[email-masked]>
Date: Sat, 5 May 2018 23:34:05 -0700

So… the spec underpromises and overdelivers :)

Seriously, I wonder if this behavior is portable across IEEE 754
implementations.

On Sat, May 5, 2018 at 11:21 PM, Anders Rundgren <
[email-masked]> wrote:

> During testing of the JSON canonicalizer [1,2] I tried with an integer
> just above the specified limit (2**53) + 1 and to my surprise it didn't
> fail.
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 6 May 2018 08:52:05 +0200

> So… the spec underpromises and overdelivers :)

Indeed :-)

> 
> Seriously, I wonder if this behavior is portable across IEEE 754 implementations.

It seems so.  At least Browsers, Node.js, .NET, and Java are identical on this particular point.

Anyway, it is prerequisite for the JSON canonicalization scheme that JSON Numbers are treated identical.
I just ported 2000 lines of Java code to C# to achieve this.
It passed 100 million random and special numbers including de-normalized edge-cases like
Hex: 0000000000000001	ES6: 5e-324

Anders

> 
> On Sat, May 5, 2018 at 11:21 PM, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     1] https://github.com/cyberphone/json-canonicalization#json-canonicalization <https://github.com/cyberphone/json-canonicalization#json-canonicalization>
>     2] https://cyberphone.github.io/doc/security/draft-rundgren-json-canonicalization-scheme.html <https://cyberphone.github.io/doc/security/draft-rundgren-json-canonicalization-scheme.html>
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/json <https://www.ietf.org/mailman/listinfo/json>
> 
> 
> 
> 
> -- 
> - Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 6 May 2018 10:13:16 +0200

The question is not whether a number makes it through a round-trip (lots more do so) but whether the result of deciding is unambiguous. If you get 2**53, you don't know whether the sender sent 2**53 or 2**53+1, so you shouldn't be accepting either number as if it were unambiguous. 

Sent from mobile

> On 6. May 2018, at 08:21, Anders Rundgren <[email-masked]> wrote:
>

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 8 May 2018 07:37:03 +0200

The source of the limit probably comes from the ECMAScript which states:

       "The value of Number.MAX_SAFE_INTEGER is the largest integer n such that
        n and n + 1 are both exactly representable as a Number value"

This definition departs from other languages' way of defining MAX values for numeric data types.

That is, for storage and transmission Number.MAX_SAFE_INTEGER + 1 (2**53) is a fully valid integer.

I have updated my documents and software accordingly.

Microsoft is taking on the Number serialization issue:
https://github.com/Microsoft/ChakraCore/issues/149#issuecomment-387232702
which is great since it is a prerequisite for compliance with:
https://tools.ietf.org/id/draft-erdtman-jose-cleartext-jws-00.html

Anders
https://cyberphone.github.io/doc/security/draft-rundgren-json-canonicalization-scheme.html#json.ieee754.test