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

[Sergey Beryozkin]

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

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



_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose