Re: Giving up on XML DSig => JSON

And FWIW, the need to canonicalize was one reason why the ability to sign "parts" of a PDF (instead of the entire PDF) was removed from the spec – because it was impossible to define an acceptable model.

Leonard

From: "Frederick.Hirsch@nokia.com<mailto:Frederick.Hirsch@nokia.com>" <Frederick.Hirsch@nokia.com<mailto:Frederick.Hirsch@nokia.com>>
Date: Thursday, August 29, 2013 1:39 PM
To: "public-xmlsec@w3.org<mailto:public-xmlsec@w3.org>" <public-xmlsec@w3.org<mailto:public-xmlsec@w3.org>>
Subject: Fwd: Giving up on XML DSig => JSON
Resent-From: <public-xmlsec@w3.org<mailto:public-xmlsec@w3.org>>
Resent-Date: Thursday, August 29, 2013 1:39 PM

Notice that canonicalization concerns can apply to JSON as well, depending on the use case, so it is not just XML that requires canonicalization...

Regards, Frederick

Frederick Hirsch, Nokia



Begin forwarded message:

Resent-From: <public-identity@w3.org<mailto:public-identity@w3.org>>
From: ext Jim Klo <jim.klo@sri.com<mailto:jim.klo@sri.com>>
Date: August 29, 2013, 12:49:48 PM EDT
To: Anders Rundgren <anders.rundgren@telia.com<mailto:anders.rundgren@telia.com>>
Cc: "public-identity@w3.org<mailto:public-identity@w3.org>" <public-identity@w3.org<mailto:public-identity@w3.org>>
Subject: Re: Giving up on XML DSig => JSON

Hi Anders,

I did some work very similar some time back for Learning Registry [1].  There are some known issues with the solution we chose and upon investigation of your doc, seems to suffer from similar problems.

My first question might be is what is your indented use case for this?  Like JOSE this seems to have very limited use due to a number of issues I'll outline below.

JSON isn't guaranteed to serialize across systems consistently. These are equivalent expressions:

// fig 1
{
"alpha": 1,
"beta": "kappa"
}

and

// fig 2
{
"beta": "kappa",
"alpha": 1
}

JOSE gets around this because the data is contained within the JWT packaging. Additionally JOSE does signature validation of the base64 encoded material - no the JSON entities.  Like you've mentioned this isn't suitable for usage as a data model.

The challenge is there's no good way (that I've uncovered) to canonicalize JSON objects and retain use as a parsed data model that serializes between platforms consistently.  Ultimately what you've done is created a canonical format that just treats the entire entity as a string. This wouldn't necessarily work well as moving the data between Java, JavaScript, Ruby, Python, etc… dictionary keys are not ordered consistently… say my system receives fig 1 above and stores it for processing, the key order isn't guaranteed when parsing it from it's native format.  In our use case we use CouchDB which stores documents as JSON.  While CouchDB just happens to be consistent in storing/retrieving dictionaries in the same order as they submitted - there's not guarantee of that.  Clients connecting to the DB also may not reconstruct key order as well depending upon their JSON parsers.  Thus in order to make your solution work, Like JOSE, the canonical format must be retained indefinitely in a portable format.

I've covered dictionaries… and FWIW XML shares the same problem with element attributes. Other challenges in signing JSON are brought upon by floating point and boolean values.  Floating point precision is problematic unless encoded as strings as floating point precision is not portable across platforms. JavaScript, Erlang, and Python could introduce error when moving objects between systems.  Booleans have the same issue - some languages internally store 1 and 0 others actually have native true and false.

Ultimately we chose to use Bencode [2] as part of a canonicalization solution which unfortunately cannot handle floats very well, however in meeting I had with BitTorrent folks some time ago we discussed Tagged Netstrings [3] as a more viable solution.

IMO, the only way to make signing JSON objects reasonable is to have a solution that is trivial to canonicalize the format for reconstruction of the signed object and permits native serialization of the JSON. I don't want to have to keep some string blob around because I need to preserve the canonical format.

To a certain extent the solution to this lies in the development, implementation, and adoption of s  "CJSON" or Canonical JavaScript Object Notation, where the representation of the object is already canonical and requires no transformations.  Alas, there seems to be very little interest for this, since most of the current work is like JOSE where signatures are only needed short term for one time validation of data sent over the wire.

[1] http://docs.learningregistry.org/en/latest/spec/Identity_Trust_Auth_and_Security/index.html#identity-and-digital-signatures
[2] https://wiki.theory.org/BitTorrentSpecification#Bencoding
[3] http://tnetstrings.org/



Jim Klo
Senior Software Engineer
Center for Software Engineering
SRI International
t. @nsomnac

On Aug 28, 2013, at 11:30 PM, Anders Rundgren <anders.rundgren@telia.com<mailto:anders.rundgren@telia.com>> wrote:

Since Google doesn't support XSD or XML DSig in Android I began looking at other alternatives.
There were none :-( Now there is :-)

https://openkeystore.googlecode.com/svn/resources/trunk/docs/Enveloped-JSON-Signatures.pdf

Comments are welcome!

Cheers
Anders