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

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 29 January 2015 01:02 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 7938B1A0032; Wed, 28 Jan 2015 17:02:14 -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 P1tLyGgJsUgU; Wed, 28 Jan 2015 17:02:13 -0800 (PST)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC871A8A47; Wed, 28 Jan 2015 17:02:02 -0800 (PST)
Received: by mail-lb0-f171.google.com with SMTP id u14so22862920lbd.2; Wed, 28 Jan 2015 17:02:01 -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=kOF2LvEcRH4mNh6pgbdE0vnW8+ciQT4XDu/xnwJMh6s=; b=S2F4fqMmyx4bJlMBtOOBcSiZpWjfQcPXVohgdhC67xrNJdgHX99eA9zRbj1LTZmKwe c+bEIXMF6k0Yfx/LwU+h7rxlPsI7xK/rQLBlx1gdWE8wbAXc8AnpsVhgkPn/zUXWxrX8 9mw/vQCO4XGuafvX29AnyNRYHjOnE+cE56h6Ex7NcRF4Xr09gsqNqwB0Q6tDPcKi6Hkj HotCSOPxC2NaLdhpdERTEnq4mb3SGUHe7dy/pir9addorYLOPHToZgrvmg55k00aSW+j uHtrlq89Fa6oGWXRktglerzSLyo3rJFSsaifuQEsPWEz/+pk+zWSnp6TZLM2QiRAv1aw dG9Q==
MIME-Version: 1.0
X-Received: by 10.112.162.226 with SMTP id yd2mr11558683lbb.1.1422493321183; Wed, 28 Jan 2015 17:02:01 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.147.193 with HTTP; Wed, 28 Jan 2015 17:02:01 -0800 (PST)
In-Reply-To: <20150129005357.GM3110@localhost>
References: <CAMm+Lwh12jzrH3ZVaS4HTqkNZkteg9mL+n6LYRsj5P1r-Q-DbQ@mail.gmail.com> <20150128224346.GF3110@localhost> <CAMm+LwhJ7Nuxk==T2x+pst020QQb6jc5NWTN6PtGS_YAEWS6Vg@mail.gmail.com> <20150128232002.GK3110@localhost> <CAMm+LwjN_6cbLfq4NAHQ0U=pRjV-ksLDZX+CEBs42m72p5GVJA@mail.gmail.com> <20150129005357.GM3110@localhost>
Date: Wed, 28 Jan 2015 20:02:01 -0500
X-Google-Sender-Auth: bZVPLqcK5PkTA2e2WfrL_BB-BlU
Message-ID: <CAMm+LwjqZ70AQ-VErfTLM4hmzrV-uWaR=nZNvc3U7oDYJQtU3Q@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary=089e0112c86c1afde6050dc0098b
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/esSStuwlTc4EqvTE_eCrbjjxUpI>
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 01:02:14 -0000

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

> On Wed, Jan 28, 2015 at 07:50:29PM -0500, Phillip Hallam-Baker wrote:
> > 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.
>
> So it's a new MIME type of signed data?
>

A  new MIME type of JSON wrapped data similar to the rfc822 type.

The content could be encrypted for example or just be the metadata.