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

Re: Note on JSON signing

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Mon, 14 Mar 2016 14:13:36 +0200
Message-ID: <CA+eFz_+gLAH-0OsdYVPZie7cc=C_H7N-DCEUkqhHvgzW6VMxow@mail.gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Cc: Jehan Tremback <jehan.tremback@gmail.com>, Stefan Thomas <stefan@ripple.com>, Anders Rundgren <anders.rundgren.net@gmail.com>, Interledger Community Group <public-interledger@w3.org>
> I'm becoming less persuaded that this is standards track work, when we I
see a subjective decision making process, without strong technical
justification.

That's a strange comment to make when this thread was started to prompt
discussion on the topic. Attempting to shut down a discussion because you
disagree with some of the comments is certainly not going to promote an
open collaborative standards development process.

If you re-read Stefan's opening email he says:

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

In other words, we are discussing what technology to use in the reference
implementations not what we want as normative references to any standards
track specification AND it's not set in stone, we're inviting opinions.

Right now, the only standard that is absolutely required for ILP is the
crypto-conditions because all parties need to be able to exchange and
understand these irrespective of how their ledger is implemented.

Standardized ledger and connector APIs are desirable for the sake of easy
interoperability but ultimately connectors can interface with ledgers
through whatever means they choose. It's quite possible a wholly different
messaging standard may evolve from this that doesn't even use JSON.



On 14 March 2016 at 13:50, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

>
>
> 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
>>>>>
>>>>
>>>>
>>>
>>
>
Received on Monday, 14 March 2016 12:14:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 14 March 2016 12:14:06 UTC