[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.
- [Acme] HTTP/J Draft Phillip Hallam-Baker
- Re: [Acme] HTTP/J Draft Fraser Tweedale
- Re: [Acme] HTTP/J Draft Phillip Hallam-Baker
- Re: [Acme] HTTP/J Draft Fraser Tweedale
- Re: [Acme] HTTP/J Draft Tony Arcieri