Re: Note on JSON signing

On 14 March 2016 at 12:27, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:

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

This is the whole reason for normalizing it.

I'll have to -1 the JCS proposal

Secure messaging is a perfectly good, scalable and extensible solution that
was designed to do exactly.

The argument about being "fairly complex" can be applied to most of the
items in ILP.  It is not convincing.

I'm becoming less persuaded that this is standards track work, when we I
see a subjective decision making process, without strong technical
justification.

Nevertheless, it is will still be valuable, even if it becomes just a Note
/ Documentation.


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