Subject: [apps-discuss] CBOR: convert CBOR bignum to base64url JSON string

From: "Manger, James H" <[email-masked]>
Date: Fri, 24 May 2013 10:33:13 +1000

A minor (non-controversial?) suggested change for draft-bormann-cbor:

Section 4.1. "Converting From CBOR to JSON" 11th dot point says:

  o  A bignum (major type 7, tag value 8 or 9) becomes a JSON number.

This might be right in theory, but I don't think it is in practice.
Presumably a bignum was used because the value (or other expected value for the same field) is too large for normal (32-bit, 64-bit) number types, which are the types many implementations use represent a JSON number. Hence they will fail with a bignum.

I suggest converting a bignum to a base64url encoding (without padding) in a JSON string. This is what you get if the positive bignum tag was ignored and you just processed the byte string that followed. For a negative bignum stick "-" before the base64url encoding.

--
James Manger

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 24 May 2013 08:15:09 +0200

> Presumably a bignum was used because the value (or other expected value for the same field) is too large for normal (32-bit, 64-bit) number types, which are the types many implementations use repre…

That is a very good point.
I haven't done a survey of JSON implementations how they handle large numbers that look like integers.
Of those for platforms that don't have bignums, I would expect many of them to create a double-precision float for large numbers.  
This doesn't fail, but loses precision.

> I suggest converting a bignum to a base64url encoding (without padding) in a JSON string. This is what you get if the positive bignum tag was ignored and you just processed the byte string that fol…

That is certainly good advice if the bignum was, say, a value from an ECDSA signature, where losing precision destroys the utility.
Less so if it was the US national debt (well, for a few more weeks, that will still fit in a 64-bit number :-).

Right now we have limited experience what people would be using bignums for in a JSON-interfacing application.
The conversion rules we set up will shape that usage, so for me the question really is what usage of bignums do we want to encourage.
(E.g., I think it would have been a mistake to put that ECDSA signature value in a bignum in the first place.  
But X9.62 did exactly this, in ASN.1, which doesn't even have unsigned numbers.)
Outside of JSON-interfacing applications, the area of application of bignums is much clearer.

BTW, the "-" convention you propose doesn't work very well with base64url.
(This is the first example I've seen in a long while where base64 would actually work better than base64url.)
But given the semantics of the byte string in CBOR, it should be a "~" anyway, and that is free in base64url.

So how would you plan to use bignums in JSON-interfacing CBOR applications?  For crypto material like ECDSA values?

Grüße, Carsten

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 24 May 2013 16:55:35 +1000

> So how would you plan to use bignums in JSON-interfacing CBOR
> applications?  For crypto material like ECDSA values?

Yes, public key crypto quantities.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 May 2013 07:59:32 -0400

On Fri, May 24, 2013 at 2:15 AM, Carsten Bormann <[email-masked]> wrote:

> > Presumably a bignum was used because the value (or other expected value
> for the same field) is too large for normal (32-bit, 64-bit) number types,
> which are the types many implementations use represent a JSON number. Hence
> they will fail with a bignum.
>
> Of those for platforms that don't have bignums, I would expect many of
> them to create a double-precision float for large numbers.

Trying to do public key crypt afterwards is not going to work very well.

Other than Mathematica, I really cant think of any platform I would expect
to be able to start reading an integer and realize that it needs to be
treated as a bignum when it goes over 64 bits.

Like many parts of the JSON syntax that is something that the specification
demands but implementations are likely to vary on.

The idea that JSON can never change by an iota seems rather silly. The
specification is not really complete. Where difficult parts come up they
are ignored and so we don't know how implementations are expected to behave
for overflow or for NaN values.

Addressing such concerns is precisely what is expected when a spec enters
IETF process.

What are JSON parsers expected to do when they come across a token litteral
they don't understand?

> > I suggest converting a bignum to a base64url encoding (without padding)
> in a JSON string. This is what you get if the positive bignum tag was
> ignored and you just processed the byte string that followed. For a
> negative bignum stick "-" before the base64url encoding.
>
> That is certainly good advice if the bignum was, say, a value from an
> ECDSA signature, where losing precision destroys the utility.

If you then try to maintain the result by adding a hundred dollars every X
milliseconds then the count is never going to increase and you will #fail.

Hey, we have just found the way to fix the national debt...

-- 
Website: http://hallambaker.com/

---

From: Nico Williams <[email-masked]>
Date: Fri, 24 May 2013 14:35:17 -0500

On Fri, May 24, 2013 at 6:59 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> specification is not really complete. Where difficult parts come up they are
> ignored and so we don't know how implementations are expected to behave for
> overflow or for NaN values.

What can't change is what existing consumers expect.  With care JSON
can be extended just fine.  At worst we might need a new MIME type.
Anyways, being able to represent more things would be nice.  It might
also be nice to be able to degrade for decoder implementations that
use NaN coding and that don't want to box things like bignums.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 May 2013 16:09:02 -0400

On Fri, May 24, 2013 at 3:35 PM, Nico Williams <[email-masked]>wrote:

> are

I think that in general we can't break anything with an update that isn't
already broken.

If you have a scientific application that is exchanging data without the
ability to recognize NaN  then it is likely going to break in horrid ways
if one came up.

Same is almost certainly true of excessively big numbers. Yes they should
work. But I am almost certain they won't.