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

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
>