On Thu, Jan 29, 2015 at 06:38:45AM +0100, 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": > This means that you either:
a) have a JSON library that serialises objects in precisely the
manner required, or affords users the degree of control needed
to achieve it, or
b) must write the serialisation function yourself
Although b) is not rocket-science, the format is hostile to code
reuse. JOSE made a different tradeoff - you can use any JSON
library but the format is more complex. One drawback is traded off
against another.
JSON has benefits compared with ASN.1, but using it presents you
with an unavoidable choice between significant drawbacks. This fact
ought not be glibly ignored.
Regards,
Fraser
> 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
> >
>
pgpridGT4KRPi.pgp
Description: PGP signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
