W3C home > Mailing lists > Public > public-web-security@w3.org > October 2015

Re: A Crypto-compliant JSON Implementation

From: <henry.story@bblfish.net>
Date: Wed, 7 Oct 2015 09:18:14 +0100
Cc: "public-web-security@w3.org" <public-web-security@w3.org>
Message-Id: <279380BC-3873-413F-9C8D-7A9C9C7CABD0@bblfish.net>
To: Anders Rundgren <anders.rundgren.net@gmail.com>

> On 7 Oct 2015, at 08:51, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> A Crypto-compliant JSON Implementation
> ==================================
> Although maybe not a topic for the W3C, I would anyway like (for those who don't follow the IETF-JOSE list) to describe a JSON implementation which enables "Signed JSON".
> Didn't the JOSE WG just finished that? No, the JOSE WG have created a set of JSON-flavored and URL-friendly cryptographic containers where the actual data has no relation to JSON ; it is rather Base64URL-encoded to be neutral to the content.
> Anyway, for me working payment systems and similar where signed JSON messages are wrapped by other signed JSON messages like "Russian dolls", Base64 simply wasn't an option:
> http://xmlns.webpki.org/webpay/v1/webpay-card-payment-messages.html#p11

nice example. I think that makese the case very well for signatures that don't munge
the input. 

> How much did I have to "violate" the JSON specification to accomplish this? Not a single bit.
> The reference implementation simply parse properties using LinkedHashMap (to maintain a predictive order) plus a minute fix for numbers by keeping a copy the original textual representation in the background for serialization.  That is, there is no canonicalization code to be find, serialization is all you need.

So what do you do with the LinkedHashMap to create the signature then?
I suppose the linked hash map is just a way to remove all reliance on white space etc,
so that you can then create a standard byte sequence which you then sign. 

So this means I suppose that any JSON code that wants to work with signatures needs
to start using LinkedHashMap implementations of JSON, so as not to loose the order, if
they ever want to verify the signature.

A document describing such requirements would be helpful.

> This also has the benefit that properties are serialized in the same order as they are created which is a feature often requested by the JSON community at large which isn't too surprising since XML elements, EDI, ASN.1, and plain-text always had this quality.

There is some research in the RDF space to do the same thing too, though
there things are complicated by the fact that RDF is not ordered, and is 
also syntax agnostic... This allows the data to be stored in a database.

> Anders
> https://github.com/cyberphone/openkeystore/tree/master/library/src/org/webpki/json
> https://mobilepki.org/jcs
Received on Wednesday, 7 October 2015 08:18:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 October 2015 08:18:45 UTC