Re: A Crypto-compliant JSON Implementation

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.

Anders

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

Received on Wednesday, 7 October 2015 08:43:41 UTC