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.
Otherwise, you're betting on luck, and that's just daft.
-- 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
