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:[email protected]] On Behalf Of Anders Rundgren
Sent: Monday, August 10, 2015 10:07 PM
To: Jim Schaad; [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
