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

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 28 January 2015 23:12 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 315D21A1DBE; Wed, 28 Jan 2015 15:12:15 -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 NkeGYY-PUa1q; Wed, 28 Jan 2015 15:12:13 -0800 (PST)
Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d: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 1EF8F1A1C05; Wed, 28 Jan 2015 15:11:47 -0800 (PST)
Received: by mail-qg0-f43.google.com with SMTP id e89so20983405qgf.2; Wed, 28 Jan 2015 15:11:46 -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=IUL+IEcBquHXAvrM0Xi/raXVR+EqesKAloNSVJ2J+jQ=; b=yKLAoAF8ckvK0yaWlYkLT9eXz7R+TxspOwkQV3Ee2LqqEbEafgROoTWkfuYZoz0t1M cwyR4X4/5k8LpNZmphGYhOnZnQ4VgTzrFFk758zQgAEmEl5jGXuOW/ESDfci6D90JRZM bRvcSJy7BSB9NbgCdnAC1feeDZWVXm7Dxwonv5WXLxiP6EAbyrnWEZH3f8T67ILZwQS6 h1AEU2ubyOsnW4ZAzLemnvx0+F81BXYv5n7WPnm6/oFvpigWSQunHcAmRIHb+6Oj6OtW lkvIeyXDmeu0nmZXzDmz6+Zq6T9jvexSJa+muEuce5ndZ6rmUgWs6y86Rx3PmuAY9PIj FOdw==
MIME-Version: 1.0
X-Received: by 10.140.34.67 with SMTP id k61mr185420qgk.95.1422486706287; Wed, 28 Jan 2015 15:11:46 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.140.92.135 with HTTP; Wed, 28 Jan 2015 15:11:46 -0800 (PST)
In-Reply-To: <20150128224346.GF3110@localhost>
References: <CAMm+Lwh12jzrH3ZVaS4HTqkNZkteg9mL+n6LYRsj5P1r-Q-DbQ@mail.gmail.com> <20150128224346.GF3110@localhost>
Date: Wed, 28 Jan 2015 18:11:46 -0500
X-Google-Sender-Auth: 1eqYfxIYgYSMv1u7dRuGpKJoU4s
Message-ID: <CAMm+LwhJ7Nuxk==T2x+pst020QQb6jc5NWTN6PtGS_YAEWS6Vg@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary=001a11c0dd5cd394f4050dbe7ea1
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/zJsnPZremaCvSQFVJ3DDj-Qm2Pc>
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:12:15 -0000

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

> On Wed, Jan 28, 2015 at 01:14:58PM -0500, Phillip Hallam-Baker wrote:
> > <JSON-BLOB> [Separator] <content-blob>
>
> I'll bite.
>
> Why not:
>
> <metadata JSON> <separator> <signature> <content>
>
> > Advantages:
> >
> > * Can read the metadata for a file etc with a plain ASCII editor or
> command
> > line tools like cat, more, etc.
> >
> > * Avoids the need to BASE64 armor the content. So if the content is JSON
> or
> > other ASCII/Unicode text it remains readable in an ASCII/Unicode editor.
>
> Why even have to base64-encode the signature?
>
> > * Can add signatures, digests and other metadata items to content in a
> > simple regular fashion.
>
> Ah.  Hmm, right!  It'd have ot be:
>


> <metadata JSON> <separator> <signature> <content> [<extra signatures>]
>
> or
>
> <metadata JSON> <separator> <content> [<signatures>]
>
> or as you suggest, put the [base64-encoded] signatures in the metadata.


Yep, that is the reason for doing it the way proposed. It is really useful
and necessary to have multiple signatures on the same content. This allows
for multiple algorithms, multiple signers, etc. Or just a signature and a
digest.




> > * It is a historical artifact and content metadata headers are mixed in
> > with protocol metadata headers without rhyme or reason.
> >
> > * It is not JSON and JSON is the spec we are now converging on for this
> > type of work. It has all the expressive capabilities of XML and ASM.1
> > without the insanities and stupid. It is as easy to read and write as
> > RFC822 but without the limitations.
>
> Meh.  It's just one of many suitable encodings.  Pick one, any one.


They seem to have picked JSON. Or S-expressions with curly braces if you
like to look at them that way...



> > JSON sequence specifies that "A JSON text sequence consists of any number
> > of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record
> > Separator (0x1E), and each ending with an ASCII Line Feed character
> (0x1A)"
> >
> > This is not ideal for JSON Container. We would prefer that the character
> > which is illegal in a JSON document be the one that is the separator
> > between the header and content.
>
> Just make it:
>
> RS JSON-blob LF FS content
>
> (That would be as close as this could get to being a JSON text
> sequence while also being sufficiently different.)


Works for me. If we are using RS, might as well use FS.



>
> > Applying this in a Web Service is very simple, our messages now have the
> > form:
> >
> > POST / HTTP/1.1
> > Host: example.com
> > Content-Type: application/json-container
> > Content-Length: 666
> >
> > { "Signature" : "wefwkjefkljwehfjklwhejkflh" }
> >
> > <0x1E>{ "Service-Type" : "acme.ws",
> >    "Transaction-ID" : "2h23roih23oih23orh",
> >    "Register" : { ....<web service parameters here> ... } }
>
> 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.

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.
Separating out protocol data from content-metadata is long overdue.



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