Re: Note on JSON signing

To verify the signature on some data you need to be able to reproduce the
data that was originally signed exactly as it was at that time.

JSON is problematic because it's not always passed around as a string.
Intermediary systems may interpret that string as a Javascript object and
then serialize it again as a string when it is sent onward. That process
has the potential to change the serialized form of the data (without
changing it's meaning) because it is not always serialized in exactly the
same way (ordering of fields etc).

So a valid signature may fail verification against JSON data that has been
passed around a bit.


On 11 March 2016 at 22:25, Jehan Tremback <jehan.tremback@gmail.com> wrote:

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