Re: [Json] JSON Concluded? Well, maybe not

[Anders Rundgren <[e-mail]>]

On 2018-01-01 18:17, Phillip Hallam-Baker wrote:
> ​I can't see the need for stringify there. By which I mean, my code runs and 
> I do not use javascript or stringify anywhere.

The only "hard" requirement is that the JSON tool adheres to ECMA's ES6+ JSON processing rules.  With the exception of "Number" normalization [1] this is a trivial matter [2].

By putting your JSON data in Base64 or using special JSON dialects you can of course do things differently.

> ​Where I think folk tend to go really wrong is doing the stuff people > decided they wanted with XML Signature which was to have the following:
> 
> Unsigned object:
> 
> <object>
>     <blahdyblah/>
> </object>
> 
> Signed object:
> 
> <object>
>     <blahdyblah/>
>     <signature>
>        {path transform}
>        {etc}
>     </signature>
> </object>
> 
> And it worked exactly as well as could be expected.

The sample and its associated scheme does (by design) NOT perform any sophisticated textual processing. Maybe it only covers 80% of the "market".  Is that a showstopper?

Anders

1] https://www.ecma-international.org/ecma-262/8.0/index.html#sec-tostring-applied-to-the-number-type
2] https://docs.oracle.com/javase/8/docs/api/java/util/LinkedHashMap.html

> On Mon, Jan 1, 2018 at 1:43 AM, Anders Rundgren <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     On 2018-01-01 07:27, Phillip Hallam-Baker wrote:
> 
>         The use case that I believe gives rise to the belief canonicalization is
>         necessary is the need to sign a data object in the same JSON document.
> 
> 
>     Yes, but this is indeed only a belief.  The following in-object signature would validate in any JSON system compliant with ECMA:
> 
>     {
>        "now": "2017-04-16T11:23:06Z",
>        "escapeMe": "\u20ac$\u000F\u000aA'\u0042\u0022\u005c\\\"\/",
>        "numbers": [1e+30,4.5,6],
>        "signature": {
>          "alg": "ES256",
>          "jwk": {
>            "kty": "EC",
>            "crv": "P-256",
>            "x": "_gow8fcS3Dx9z6j57U5q8tunnRBdrgLU9A7CZTYCnqU",
>            "y": "bdfJGraBVL5aPj38TG4tHwxpU2VKwG1XBp0wQfCLOFQ"
>          },
>          "val": "OfTUed3gOO58ZPcP5ZXpL6OA9iyHskfo0zKI60H6XriGNNNb5sugGz80nqfyJ25jXPRYGAWcjH-1KGy5_eQuJQ"
>        }
>     }
> 
> 
>        // Perform normalization
>        var clone = Object.assign({}, signedObject.signature);     // Clone "signature" child object
>        var signature = decodeBase64URL(clone.val);                // Get signature value
>        delete signedObject.signature.val;                         // Remove signature value property from signed object
>        var data = convertToUTF8(JSON.stringify(signedObject));    // Get normalized JSON string (signed data)
>        signedObject.signature = clone;                            // Restore signed object
>        // Do the crypto now
> 
>     That's clearly not rocket science.
> 
>     Anders
> 
> 
>         I have this need frequently:
> 
>         { {A = [... JSON Data...]} { Signature (A) } }
> 
>         The way I solve this using JSON is to BASE-64 encode:
> 
>         { { A = base64(... JSON Data...)} { Signature (A) } }
> 
>         Which is brutal but entirely effective and only expands the data by 33%
> 
>         For an efficient encoding, I use JSON-B which is a strict superset of JSON with additional code points that allow binary data to be spliced in.
> 
>         JSON only uses bytes in the range 1-127 for tagging. Bytes in the range 128-255 can only occur inside strings. Which means all the other values can be repurposed
> 
>         In JSON-B, the binary sequence 01 02 03 can be encoded as either "AQID" or
> 
>         88 03 01 02 03
> 
>         The first byte says that this is a binary value with an 8 bit length and the final block of the sequence (i.e. there is only one block in this sequence).
> 
>         The second byte is the length.
> 
>         The rest is the data.
> 
> 
>         I would much rather extend JSON to support efficient encoding of any binary value than develop a canonicalization hack that could only ever work for JSON.
> 
>         http://www.prismproof.org/Documents/draft-hallambaker-jsonbcd.html <http://www.prismproof.org/Documents/draft-hallambaker-jsonbcd.html>
> 
> 
> 
> 
>