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

Fraser Tweedale <frase@frase.id.au> Thu, 29 January 2015 04:25 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 89CF21A1B74; Wed, 28 Jan 2015 20:25:52 -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 ADGR7OdzgLuX; Wed, 28 Jan 2015 20:25:51 -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 E90CF1A1AB4; Wed, 28 Jan 2015 20:25:50 -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 t0T4PF7p036188; Thu, 29 Jan 2015 14:25:15 +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 t0T4PFnJ004856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Jan 2015 14:25:15 +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 t0T4P9xr004855; Thu, 29 Jan 2015 14:25:09 +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 14:25:09 +1000
From: Fraser Tweedale <frase@frase.id.au>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Message-ID: <20150129042508.GA4845@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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm"
Content-Disposition: inline
In-Reply-To: <CAMm+Lwirvv5tLU-2AEqnQe9DUDKT=GbJK9Jyy69BJVfeDZjCiA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/RQJBZj2FQznt6BCRdkhi4eqI4EM>
Cc: "Manger, James" <James.H.Manger@team.telstra.com>, "acme@ietf.org" <acme@ietf.org>, Nat Sakimura <sakimura@gmail.com>, JSON WG <json@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 04:25:52 -0000

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