[Acme] HTTP/J Draft

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 26 February 2015 03:14 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 7AF4B1A1B80 for <acme@ietfa.amsl.com>; Wed, 25 Feb 2015 19:14:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id q5Vhcdl7PSSK for <acme@ietfa.amsl.com>; Wed, 25 Feb 2015 19:14:06 -0800 (PST)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55E91A0387 for <acme@ietf.org>; Wed, 25 Feb 2015 19:14:05 -0800 (PST)
Received: by lbiz11 with SMTP id z11so8162436lbi.5 for <acme@ietf.org>; Wed, 25 Feb 2015 19:14:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=PM8VnYBZBkhoW9L5hVF/PQmAilAkGGm0XsUZUkYYoiI=; b=Tqnd92cWgY/ZYlJo1Sq8GycZuV2mjr6lurxf4r7XVXr7OqYwcCmrLbixRBb+zuKAnE wtMBQunT11qUj4SF9qq2KNdsWEt39HwTwzkDWX29i6mSuRL/uvxxNP7AHYDkC9gb/3VU AHV1O5yq+zT4XN7oyWf9ofwdp5ZFJnTOp1iuir99SS+Gp1j+FbSKZPWb7WQ/zY2+Y83n OzNaDJQkjgWAEeNvrNM5mc5lg1tKOKctmPacrnoPtQ+D24lt2MLWgtxt9TMWGdSlz8y7 Y6fzdtJSbHiZSbGbofS097en4uuiBFYGi4D7IISYM2qCXfdpXVc9T6qyPhz0PpRtIRuy 5fqg==
MIME-Version: 1.0
X-Received: by with SMTP id z1mr5604563lad.124.1424920444000; Wed, 25 Feb 2015 19:14:04 -0800 (PST)
Sender: hallam@gmail.com
Received: by with HTTP; Wed, 25 Feb 2015 19:14:03 -0800 (PST)
Date: Wed, 25 Feb 2015 22:14:03 -0500
X-Google-Sender-Auth: Wqokq3IUVIwxW7GJpEWTBlYBKl4
Message-ID: <CAMm+Lwhx=LE4=kgiU1=YJFC5vPEMaGYi129E8Oc=FHGFAEUQaA@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: "acme@ietf.org" <acme@ietf.org>
Content-Type: multipart/alternative; boundary=089e014940aee5df06050ff524b5
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/q7LVKkzMXH4125f1Aayw2KEfFJk>
Subject: [Acme] HTTP/J Draft
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, 26 Feb 2015 03:14:08 -0000

Earlier on this list we discussed the question of how to use JSON to encode
messages. I think that it would be useful to write this up as a draft.

I don't particularly care what the rules are but I would like to avoid
writing a new set of rules for each protocol that comes along. One of the
main attractions for me in using JSON is that instead of offering five ways
of encoding a data structure like ASN.1 does or fifty like XML does, there
is one way to do most things.

What we don't have convergence on is how to sign JSON data in a protocol
message. Though this has been discussed on the JSON list a bit as well as

Drawing together the earlier discussion points, here are things that I
think there was broad agreement on:

1) The signature covers exactly one data blob which is placed in the
payload portion of a HTTP message.

This means no signed headers, no signed request or response line. Any data
that is significant in the application protocol is carried in the
application content area.

2) The signature data is passed in the HTTP payload section, not as a

This means I have to change my code. But I think it is the right thing to
do. The mixing of content metadata headers and protocol headers is a really
unlovely feature of HTTP. Putting the signature in the payload section
raises no implementation difficulties.

3) The payload section consists of a signature block followed by some
record separator mark followed by the signed data. The signed data is
passed verbatim without base 64 encoding.

4) The signature is described using JSON/JOSE

So a typical message would be something like

/.well-known/acme/Register POST HTTP/1.1
Host: example.com
Content-Length: 230

{ "signatures" : { "signature":


{ "Register" : { ... Acme Stuff ...}

I see no point in requiring base64 encoding or using any mechanism to allow
signing of HTTP headers. Put all the protocol related data in one place and
stick a signature on the front.

If folk get really upset then maybe we reverse the order and put the
signature blocks at the end so that a chunking/streaming approach can be
easily supported. But this adds quite a bit to implementation complexity
and ACME doesn't need it.