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

Nico Williams <nico@cryptonector.com> Wed, 28 January 2015 23:20 UTC

Return-Path: <nico@cryptonector.com>
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 0318B1A6F11; Wed, 28 Jan 2015 15:20:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.266
X-Spam-Level:
X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 rQXkDiocyaZb; Wed, 28 Jan 2015 15:20:07 -0800 (PST)
Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB0B1A6EE8; Wed, 28 Jan 2015 15:20:07 -0800 (PST)
Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 0CF786B007C; Wed, 28 Jan 2015 15:20:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=K2sOGVTeuiv0z9 UvBEQGDyzkRFo=; b=nF7LfR+dMIsAzQ2eORlBR/ZUovByAvxQ1tgm62RSqi8oHv MPPRx1kdF11ln4atUlbOBn5i+aJgD4rBNeDkpXPRH9IRMOjKpF0HkK/seJ7k04J2 8/CXKWYHQZD9sT5IY3589Ghdxi22+J01ViBrwfBj6IbaGjgkQGW3KNqUEiwrI=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPA id A578C6B0070; Wed, 28 Jan 2015 15:20:06 -0800 (PST)
Date: Wed, 28 Jan 2015 17:20:06 -0600
From: Nico Williams <nico@cryptonector.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Message-ID: <20150128232002.GK3110@localhost>
References: <CAMm+Lwh12jzrH3ZVaS4HTqkNZkteg9mL+n6LYRsj5P1r-Q-DbQ@mail.gmail.com> <20150128224346.GF3110@localhost> <CAMm+LwhJ7Nuxk==T2x+pst020QQb6jc5NWTN6PtGS_YAEWS6Vg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMm+LwhJ7Nuxk==T2x+pst020QQb6jc5NWTN6PtGS_YAEWS6Vg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/l6Jis4OVTdTxP-K5nWHwKryu06c>
Cc: "acme@ietf.org" <acme@ietf.org>, JSON WG <json@ietf.org>
Subject: Re: [Acme] 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: Wed, 28 Jan 2015 23:20:08 -0000

On Wed, Jan 28, 2015 at 06:11:46PM -0500, Phillip Hallam-Baker wrote:
> > OK, but why not put all of this into the headers anyways?
> 
> Well that is what I suggested in my Content-Signature work and that is
> exactly how my code works today. But folk proposed introducing the
> signature in the HTTP content segment and that forced me to think about
> which approach is better.

Your approach looks like a Transfer-Encoding to me.  If that's what it
looks like, and that's what it walks like, [and that's what we want,]
then that's what it should be.

> I think I can make a good architectural argument for the JSON Container
> approach and besides which it is really useful at the file system level.

You want the contents of the object to include the signature??

I mean, I've wanted filesystems to expose some internal metadata (e.g.,
a Merkle hash tree root hash for a file's content, with those parameters
needed to reconstruct the same hash from just the contents, namely, the
shape of the tree and the size of each non-tail block of contents).  But
making this part of the contents instead of the metadata strikes me as
rather problematic.

> Separating out protocol data from content-metadata is long overdue.

Maybe, but I do want POSIX to continue not commingling contents and
metadata.

> > > Notice how we have just developed a format that allows us to sign a
> > > complete code distribution including content data very easily. This is
> > > obviously out of scope for ACME but the fact that an approach transfers
> > so
> > > neatly to a completely different problem suggests that it is the right
> > > track.
> >
> > Wasn't JOSE about this sort of thing?
> 
> Sort of. That might be where we eventually do the work. But the
> requirements would be ACME in the first instance and the constraints from
> JSON. I would see JOSE as being something we just plop in and should work
> (or else they have some splainin' to do.

I meant: why not use whatever JOSE delivered?

Nico
--