Re: [Acme] [Json] Signed JSON document / Json Content Metaheader / JSON Container

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 <sakimura@gmail.com> 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 <
> > James.H.Manger@team.telstra.com> 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
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme