Re: Note on JSON signing

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