Re: Giving up on XML DSig => JSON

On 2013-08-29 18:49, Jim Klo wrote:
> 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.

Hi Jim,
This sounds interesting!

> My first question might be is what is your indented use case for this?

Primary replacing this:  http://webpki.org/papers/keygen2/keygen2.junit.run.html
which is a part of:  https://code.google.com/p/openkeystore

>  Like JOSE this seems to have very limited use due to a number of issues I'll outline below.

Well, I have done some shortcuts/redefinitions of JSON which should make this scheme usable for a wide class of web-based security-protocols, where the _message_ is the core and a signature is only there to vouch for the message's authenticity.

That is, I don't expect this scheme to work with arbitrary JSON parsers.  I wrote a suitable parser from scratch that preserves property order as well as the base elements (int, bool, string) in text format.  If you do that canonicalization gets absolutely trivial:
https://code.google.com/p/openkeystore/source/browse/library/trunk/src/org/webpki/json/JSONParser.java
300 lines of code seems supportable.  it is brand new so it may have some "warts".

IBM has apparently patented (!!!) a JSON signature scheme ( http://patents.justia.com/patent/20100185869 ) which does canonicalization the hard ("right" if you prefer that...) way. I won't try that because then the advantage of JSON becomes limited.

> 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
> }

It would not validate using JSON schema ( http://json-schema.org/ ) and that is where I started (with my 12 years of XSD in the back).

I.e. I consider JSON properties equivalent to XML elements rather than XML attributes.
But that's of course *my* (re)definition of JSON :-)

Cheers
Anders

> 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> 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
>>

Received on Thursday, 29 August 2013 18:32:57 UTC