On 2015-01-29 14:14, Justin Richer wrote:
Relying on side-effects of a handful of contemporary implementations is
dangerous at best and absolutely foolhardy at worst, especially when it
comes to security systems. You *need* to have a formal canonicalization,
normalization, or serialization in order for these things to work in
practice.
You are right: JCS isn't guaranteed to run on any JSON implementation.
However, JCS doesn't rely on side-effects, it has a formal normalization
scheme (the description may be crap but there is one at least), which is
explicitly implemented in two (yes, only two) reference implementations.
Then I have with the help of available documentation and communication
with the authors, verified that two "commercial" JSON implementations
also can support "predictive serialization" which BTW is a requested
item by the general JSON community for the simple reason that humans
(unlike computers) find it somewhat odd that if you define properties
A,B,C they come out as A,C,B.
The only (known NB) "fly in the soup" is that floating-point serialization
usually requires some specific measures to work as mandated by the JCS
normalization scheme. If this is a show-stopper and can't be corrected,
your best option is using JWS of course. The idea was never ever to
"compete" but to "complement". I have adjusted the JCS during the voyage
so that it nowadays reuses JOSE algorithms, curves, public key objects, and
signature blob format. "Crypto compatible".
Otherwise, you're betting on luck, and that's just daft.
Since I don't consider myself a gambler, I guess I have to settle on "daft"
then :-)
Anders
-- Justin
On 1/29/2015 12:38 AM, Anders Rundgren wrote:
On 2015-01-29 05:25, Fraser Tweedale wrote:
Hi Fraser,
I agree the JSON ship has sailed, but there *are* drawbacks.
The JSON ship may have sailed but it is actually more like a dinghy when
look closer making a turn or two fairly realistic.
Using predictable serialization which is anything but rocket-science,
"canonicalization" can [often] be reduced to "stringify":
https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html
https://code.google.com/p/openkeystore/source/browse/python/trunk/src/org/webpki/json
https://code.google.com/p/openkeystore/source/browse/resources/trunk/docs/JCSDemo.cs
Anders
On Wed, Jan 28, 2015 at 11:03:05PM -0500, Phillip Hallam-Baker wrote:
On Wed, Jan 28, 2015 at 9:57 PM, Nat Sakimura <[email protected]>
wrote:
On a side note: if such a spec is to be defined here, IMHO, it
should use
the algorithms and probably header parameters specified by JWA,
etc. It
should limit the scope to payload processing and expression of the
entire
thing in JSON Log like format, and leave the rest to JOSE.
Absolutely. In fact that is why I am not raising it in JOSE as that
just
provides the format for the main crypto attributes.
On Thu Jan 29 2015 at 11:51:24 Manger, James <
[email protected]> wrote:
A signed JAR file meets some of these requirements.
Metadata and signatures are in extra files in the ZIP archive:
META-INF/MANIFEST.MF, META-INF/MYKEY.SF, META-INF/MYKEY.RSA.
Content is the other files in the archive.
It is not JSON of course, and the signature & certs are packaged in
ASN.1, but it is a useful comparison. It avoids BASE64 on the
content; can
adds signatures, digests, and other metadata; can transport
content and
metadata as a regular blob (*.jar file); can sign complete code
distributions.
I have used signed jar files. But Sun rather poisoned the well there by
suing Microsoft over control of Java followed up by further lawsuits
from
Oracle.
I can't imagine anyone is going to accept Jar or anything involving
assinine.1 as a wire format for packaging. Those days are long past.
The
way you get coherence is to pick one encoding and stick to it. JSON
seems
to have been the one we picked. It has all the functionality offered
by the
alternatives and none of the drawbacks.
There are ∞ valid ways to serialise a JSON object. If a JSON object
is signed over, it must be canonicalised, or signed over and
transported in serialised form. JOSE takes the latter approach
(base64url-encoded serialised JSON object, inside a JSON object),
while JWK thumbprint draft uses canonicalisation. ASN.1 encodings
and deterministic binary serialisations can avoid the need for these
sorts of hacks.
I agree the JSON ship has sailed, but there *are* drawbacks.
Regards,
Fraser
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
