W3C home > Mailing lists > Public > public-interledger@w3.org > March 2016

Re: Note on JSON signing

From: Jehan Tremback <jehan.tremback@gmail.com>
Date: Fri, 11 Mar 2016 12:25:43 -0800
Message-ID: <CABG_PfQtY9fqyfm1udUribyHvpSx1MWkajge9auaY4g9bEi=UQ@mail.gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Cc: Stefan Thomas <stefan@ripple.com>, Anders Rundgren <anders.rundgren.net@gmail.com>, Interledger Community Group <public-interledger@w3.org>
Doesn't this JCS overlap with crypto conditions? Why should data be signed
in some special way just because it got serialized into JSON?

On Fri, Mar 11, 2016 at 12:12 PM, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On 11 March 2016 at 20:50, Stefan Thomas <stefan@ripple.com> wrote:
>
>> We need to sign JSON objects in a few places in the ledger and connector
>> level APIs. After evaluating the options, we concluded:
>>
>> Secure Messaging [1] depends on RDF Graph Normalization which is a fairly
>> complex process. We don't think it's a good idea to have a signature
>> standard have a complex dependency like that, despite the benefits. The
>> spec also isn't very widely used.
>>
>
> What do you mean by "complex".  Isnt it just the normalize() function.
>
> I use this, and found it pretty easy.  I intend to use it for inter ledger
> work too.
>
> Having reviewed your code in the past, which is in general high quality
> and advanced (particularly 5 bells stuff), im surprised that you found this
> piece challenging.  Did I miss something?
>
>
>>
>> JSON Web Signatures (JWS) [2] normally contain the data they is signing.
>> So our objects would get bloated by a bunch of base64-encoded redundant
>> JSON - incredibly wasteful and ugly in our case. It was designed for
>> signing tokens, not objects in an API, so it really isn't meant for our use
>> case. Since transfers could get large with nesting, this is a dealbreaker.
>>
>> We can deviate from standard JWS and just provide the signature by
>> itself. JWS library usually support this way of using it. So that's nice,
>> but now the standard doesn't specify how to canonicalize the JSON, what to
>> call the signature header field, what to call the signature field, where
>> those fields should be added in relation to the object being signed.
>>
>> Fortunately, somebody else has already run into the exact same issue.
>>
>
> Agree.
>
>
>>
>> JCS [3] is designed for our use case exactly. It is building very closely
>> on JWS in the sense that it would be trivial to extend a JWS library with
>> JCS support. In most cases you'll even be able to use a JWS library to
>> verify and generate JCS signatures with minimal glue.
>>
>> For these reasons, we plan to use JCS in the reference implementation for
>> now. Curious to hear everyone's input, the final decision on what the
>> long-term API will be is still open.
>>
>
> Not sure I'll support this unless there's a large benefit in terms of user
> base.  Good food for thought though.
>
>
>>
>> [1] https://web-payments.org/specs/source/secure-messaging/
>> [2] https://tools.ietf.org/html/rfc7515
>> [3] https://cyberphone.github.io/openkeystore/resources/docs/jcs.html
>>
>
>
Received on Friday, 11 March 2016 20:26:16 UTC

This archive was generated by hypermail 2.3.1 : Friday, 11 March 2016 20:26:17 UTC