Re: Note on JSON signing

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

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

Well I did ask why the normalization spec we've developed would not be
reused.  Or what was complex about it.


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