Re: Note on JSON signing

Hmm - Melvin, do you have a pointer to the normalize spec?  Sorry - there
are a lot of specs flying around.

On Mon, Mar 14, 2016 at 1:39 PM, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

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


-- 
Shane McCarron
Projects Manager, Spec-Ops