Re: A Crypto-compliant JSON Implementation

> On 7 Oct 2015, at 09:43, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
> On 2015-10-07 10:18, henry.story@bblfish.net wrote:
>> 
>>> 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.
> 
> Yes
> 
>> 
>>> 
>>> 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.
> 
> The LinkedHashMap is only used for preserving reading order of properties.
> White space is always ignored by JSON parsers.
> 
>> 
>> 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 lot of other parsers already have this feature while few if any supports the number fix.
> 
>> 
>> A document describing such requirements would be helpful.
> 
> https://cyberphone.github.io/openkeystore/resources/docs/jcs.html#Normalization_and_Signature_Validation
> Normalization = Serialization in the reference implementation.
> 
>>> 
>>> 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.
> 
> JSON properties are not ordered either, I only added a method for preserving creation order which does not change semantics or affect its ability to be stored in a database.
> Although my knowledge of RDF is close to nil, I guess that this could be applied to RDF as well.

Ah ok, so your problem is that someone receiving some JSON won't know if the format has preserved creation order or not, so they won't know if the signature is broken just because of that or something more serious.

Research in RDF has gone into finding an ordering for a graph that does not rely on a accidental property such as "creation order", but instead to find a reproducible function from graph to serialisation that can be used whatever the order one is given for the graph.

I think Dave Longley has been working on this for JSON LD.

Btw. it is never too late to augment one's knowledge of RDF so that it be above nil,
though it would be especially  welcome given that you have been commenting on the WebID mailing list for a few years now, and that is a requirement for active participation in that group.

Henry

> 
> Anders
> 
>> 
>> 
>>> 
>>> Anders
>>> https://github.com/cyberphone/openkeystore/tree/master/library/src/org/webpki/json
>>> https://mobilepki.org/jcs

Received on Wednesday, 7 October 2015 09:36:20 UTC