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

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 29 January 2015 00:50 UTC

Return-Path: <hallam@gmail.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 308F61A89F9; Wed, 28 Jan 2015 16:50:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 X_d40UuSEpgC; Wed, 28 Jan 2015 16:50:31 -0800 (PST)
Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29EC21A89F5; Wed, 28 Jan 2015 16:50:31 -0800 (PST)
Received: by mail-lb0-f181.google.com with SMTP id u10so22885105lbd.12; Wed, 28 Jan 2015 16:50:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8IHKtDulHZ3pr6Lvf+6Ks+u4DOxg7m6CKyG+b5t1qBY=; b=ZnJDbXOEOp38MdTVVBOiAqjGL/u/ok10ijuCX2Yl6tX5mzc5aI0CVwLJXfAB6my4It 9HGs6muJaZEG5i0Xy04w2ERgqy26RFB+c3c/rai7A9bM4GTzlbF8HTgwDCR/iz8HN0Im Xm0M9MuWdffm9obMVXM38wvm6F4TnPCdvGOtI6pUe4so2eIKNgEKwFC5MA+eQK+fbCmf S7Bblpq7LuH2cAb24CfX/2B84y0v/V+pwq5Uw93HCf4+jfGDX7DTmdy3zLS5txXepLVr Yj3/LrtaeQOffufkOTZOXCDTJKoiW7U+zQh0mGxKx1pZxKSiCgTSLYDPlOH+uPt3HAUH //XA==
MIME-Version: 1.0
X-Received: by 10.152.6.101 with SMTP id z5mr11488611laz.19.1422492629635; Wed, 28 Jan 2015 16:50:29 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.147.193 with HTTP; Wed, 28 Jan 2015 16:50:29 -0800 (PST)
In-Reply-To: <20150128232002.GK3110@localhost>
References: <CAMm+Lwh12jzrH3ZVaS4HTqkNZkteg9mL+n6LYRsj5P1r-Q-DbQ@mail.gmail.com> <20150128224346.GF3110@localhost> <CAMm+LwhJ7Nuxk==T2x+pst020QQb6jc5NWTN6PtGS_YAEWS6Vg@mail.gmail.com> <20150128232002.GK3110@localhost>
Date: Wed, 28 Jan 2015 19:50:29 -0500
X-Google-Sender-Auth: 55pjeCe_2ljr5Et8gteW8IP7trQ
Message-ID: <CAMm+LwjN_6cbLfq4NAHQ0U=pRjV-ksLDZX+CEBs42m72p5GVJA@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary=089e01494332e29b00050dbfdf8c
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/rfH8jtvZsEC1dtaqm4Nw0AlGpMg>
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: Thu, 29 Jan 2015 00:50:33 -0000

On Wed, Jan 28, 2015 at 6:20 PM, Nico Williams <nico@cryptonector.com>
wrote:

> 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.


Umm, I designed the Chunked transfer encoding. A TE gives the length of
blobs. This is not a TE.



>
> > 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??
>

No, I want the option of doing drag and drop on the file plus metadata blob
in a fully interoperable fashion. So the contents are still the contents.
But they are prefixed by the metadata.




> 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.


It isn't making it part of the contents. Metadata is still metadata.

Trying to get the file system to support additional semantics is a losing
proposition. And even if they are supported they won't be standard across
all the platforms.



>
> > Separating out protocol data from content-metadata is long overdue.
>
> Maybe, but I do want POSIX to continue not commingling contents and
> metadata.


I want POSIX to curl up in the corner and die.

Co-mingling the contents and metadata are an inevitable consequence of
considering files to just be a stream of bits. inside the container is the
only place that metadata can go.

UNIX has had horrid kludges for putting metadata into the content since the
start. Thats what magic numbers are.

> 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?
>

Base64 encoding the content so as to be able to work out the boundaries.
Blech.