[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 [127.0.0.1]) 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-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 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 10.152.18.225 with SMTP id z1mr5604563lad.124.1424920444000; Wed, 25 Feb 2015 19:14:04 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.113.3.165 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
here.


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

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":
     "MRjdkly7_-oTPTS3AXP41iQIGKa80A0ZmTuV5MEaHoxnW2

         e5CZ5NlKtainoFmKZopdHM1O2U4mwzJdQx996ivp83xuglII7PNDi84w
         nB-BDkoBwA78185hX-Es4JIwmDLJK3lfWRa-XtL0RnltuYv746iYTh_q
         HRD68BNt1uSNCrUCTJDt5aAE6x8wW1Kt9eRo4QPocSadnHXFxnt8Is9U
         zpERV0ePPQdLuW3IS_de3xyIrDaLGdjluPxUAhb6L2aXic1U12podGU0
         KLUQSE_oI-ZnmKJ3F4uOZDnd6QZWJushZ41Axf_fcIe8u9ipH84ogore
         e7vjbU5y18kDquDg"}


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