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

Fraser Tweedale <frase@frase.id.au> Thu, 29 January 2015 06:59 UTC

Return-Path: <frase@frase.id.au>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B261A8F4A; Wed, 28 Jan 2015 22:59:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.628
X-Spam-Level: *
X-Spam-Status: No, score=1.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HOST_EQ_STATIC=1.172, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rnsD0KzzJyW; Wed, 28 Jan 2015 22:59:29 -0800 (PST)
Received: from captainmorgan.hollandpark.frase.id.au (110-174-235-130.static.tpgi.com.au [110.174.235.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D56851A8F49; Wed, 28 Jan 2015 22:59:28 -0800 (PST)
Received: from bacardi.hollandpark.frase.id.au (bacardi.hollandpark.frase.id.au [192.168.0.100]) by captainmorgan.hollandpark.frase.id.au (8.14.9/8.14.9) with ESMTP id t0T6x9kN037051; Thu, 29 Jan 2015 16:59:09 +1000 (EST) (envelope-from frase@frase.id.au)
Received: from bacardi.hollandpark.frase.id.au (localhost [127.0.0.1]) by bacardi.hollandpark.frase.id.au (8.14.9/8.14.9) with ESMTP id t0T6x9ga005821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Jan 2015 16:59:09 +1000 (EST) (envelope-from frase@frase.id.au)
Received: (from fraser@localhost) by bacardi.hollandpark.frase.id.au (8.14.9/8.14.9/Submit) id t0T6x4je005820; Thu, 29 Jan 2015 16:59:04 +1000 (EST) (envelope-from frase@frase.id.au)
X-Authentication-Warning: bacardi.hollandpark.frase.id.au: fraser set sender to frase@frase.id.au using -f
Date: Thu, 29 Jan 2015 16:59:04 +1000
From: Fraser Tweedale <frase@frase.id.au>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <20150129065903.GC4845@bacardi.hollandpark.frase.id.au>
References: <CAMm+Lwh12jzrH3ZVaS4HTqkNZkteg9mL+n6LYRsj5P1r-Q-DbQ@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1284ED9AA38@WSMSG3153V.srv.dir.telstra.com> <CABzCy2DTa+2usPhGJRX7kq8vdxaC+LgAEgoZWNiBmaQNOaYdEg@mail.gmail.com> <CAMm+Lwirvv5tLU-2AEqnQe9DUDKT=GbJK9Jyy69BJVfeDZjCiA@mail.gmail.com> <20150129042508.GA4845@bacardi.hollandpark.frase.id.au> <54C9C765.7080604@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7gGkHNMELEOhSGF6"
Content-Disposition: inline
In-Reply-To: <54C9C765.7080604@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/c2zzNaPUgONwh2QtKsZX45An9Wo>
Cc: Nat Sakimura <sakimura@gmail.com>, Phillip Hallam-Baker <phill@hallambaker.com>, "Manger, James" <James.H.Manger@team.telstra.com>, "jose@ietf.org" <jose@ietf.org>, "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] [Json] Signed JSON document / Json Content Metaheader / JSON Container
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Jan 2015 06:59:31 -0000

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 <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
> >
> >
> >
> > _______________________________________________
> > Acme mailing list
> > Acme@ietf.org
> > https://www.ietf.org/mailman/listinfo/acme
> >
>