Re: [jose] Payment Perspective on draft-jones-jose-jws-signing-input-options 00

On 2015-08-12 12:20, Sergey Beryozkin wrote:
> Hi Anders
>
> I'm interesting in experimenting with JCS in our project, possibly
> implemented, I've created an issue to keep it on the map. It does not
> have to be RFC :-)...
> Now that I think about it I'm not even sure I understand why the
> ordering constraint is a problem, even the most primitive reader/writer
> I did myself uses LinkedHashMap.
>
> The situation where an intermediary uses some 3rd party parser that
> reads a payload then add something new and produces a different order
> appears to be somewhat isolated (in fact I'm not sure it is practically
> realistic because this intermediary would also need to have the same
> same signing/validating key and the problem of distributing the key
> securely between many parties in the chain appears to be much more
> complex for the actual exercise even to tale place). Sorry all if I
> misunderstood something :-)

Totally agree (of course) :-)

JCS (and GraphSignature) were designed to add a "Signed" capability to existing
JSON objects while keeping the message structure intact since business folks
tend to care more about their messages than about signatures.

This may sound a bit sloppy but assuming that both interests actually can be met, why not? :-)

I'm considering an RFC in the same vein as JSON-I where "Predictive Serialization"
would be outlined since this is really the core idea and a possible quality factor
for future JSON tools.

Cheers,
Anders

>
> Thanks, Sergey
> On 11/08/15 11:18, Anders Rundgren wrote:
>> On 2015-08-11 11:57, Sergey Beryozkin wrote:
>>> Hi Anders
>>> Not sure if it makes sense, but can the ordering requirement be relaxed
>>> and instead JSON keys are sorted first (natural string sorting) before
>>> the signature is created or validated ? Though it is probably not
>>> effective as it can block streaming...
>>
>> Hi Sergey,
>>
>> The point I have tried to make (and failed with) is that "Predictable
>> Serialization"
>> is a generic usable JSON feature.
>>
>> http://docs.oracle.com/javase/8/docs/api/java/util/LinkedHashMap.html
>>
>>     "This technique is particularly useful if a module takes a map on input,
>>      copies it, and later returns results whose order is determined by that
>>      of the copy. (Clients generally appreciate having things returned in
>> the
>>      same order they were presented.)"
>>
>> Clients = Users.
>>
>> Sorting would defeat the readability requirement and also depend on
>> external
>> signature processing code.  In my take on this topic, the parser/serializer
>> does all signature processing except for the core cryptographic operations.
>>
>> Anders
>>
>>> Cheers, Sergey
>>> On 11/08/15 07:52, Anders Rundgren wrote:
>>>> On 2015-08-11 07:41, Mike Jones wrote:
>>>>> I would think that the financial community would want a reliable
>>>>> signature method,
>>>>
>>>> Indeed.
>>>>
>>>>
>>>>> without the interop problems that relying on canonicalization creates,
>>>>> as so
>>>>    > thoroughly demonstrated in practice by XML Canonicalization.
>>>>
>>>> Absolutely!
>>>>
>>>>
>>>>> For starters, there isn't actually a JSON canonicalization standard in
>>>>> the first place.
>>>>
>>>> True.  As I have shown in specifications, code, etc. there's no need for
>>>> such a thing either.
>>>>
>>>>
>>>>> And relying on intermediaries not modifying the JSON in any way is
>>>>> also fraught with
>>>>    > danger and an invitation to attacks.
>>>>
>>>> It is possible that my analysis is flawed, but as far as I can tell, the
>>>> only thing
>>>> an adversary (or poorly working intermediary), could succeed with by a
>>>> substitution
>>>> attack on JCS [1], is invalidating signatures which I (FWIW) wouldn't
>>>> characterize
>>>> as a security problem but as a nuisance and interoperability issue.
>>>>
>>>>
>>>>> Would using JWS with detached payloads really be that onerous for this
>>>>> community,
>>>>    > provided they actually have a way to preserve the payload exactly?
>>>>
>>>> If nothing else helps they would go for that but as shown there are (at
>>>> least)
>>>> a couple of efforts out there pointing to more "JSONesque" schemes.
>>>>
>>>> My guess is that there are many other JSON signature schemes in the
>>>> workings we
>>>> don't know of, since financial communities tend to be rather
>>>> tight-lipped :-)
>>>>
>>>> It is important to realize that I'm in _no way_ "dissing" the JOSE work,
>>>> I only
>>>> see it as less suitable for the target market I mentioned.
>>>>
>>>> Best regards,
>>>> Anders
>>>>
>>>> 1]
>>>> https://cyberphone.github.io/openkeystore/resources/docs/jcs.html#Sample_Signature
>>>>
>>>>
>>>>
>>>>>
>>>>>                   -- Mike
>>>>>
>>>>> -----Original Message-----
>>>>> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders Rundgren
>>>>> Sent: Monday, August 10, 2015 10:07 PM
>>>>> To: Jim Schaad; jose@ietf.org
>>>>> Subject: Re: [jose] Payment Perspective on
>>>>> draft-jones-jose-jws-signing-input-options 00
>>>>>
>>>>> On 2015-08-10 23:00, Jim Schaad wrote:
>>>>>> I am just not interested in this I guess.
>>>>>
>>>>> Yes, the JOSE WG have more or less unanimously decided to ignore the
>>>>> needs of the financial community who wants to sign JSON objects [1]
>>>>> rather than signing arbitrary data using JSON-based signature
>>>>> containers.
>>>>>
>>>>> Anders
>>>>>
>>>>> 1] Although entirely different with respect to JSON normalization, the
>>>>> following independently developed schemes proposals seem to support
>>>>> this statement:
>>>>>
>>>>> https://web-payments.org/specs/source/vocabs/security.html#GraphSignature2012
>>>>>
>>>>>
>>>>> https://cyberphone.github.io/openkeystore/resources/docs/jcs.html#Sample_Signature
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jose mailing list
>>>>> jose@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>>
>>>>
>>>> _______________________________________________
>>>> jose mailing list
>>>> jose@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/jose
>>>
>>
>