Re: [Acme] HTTP/J Draft

Fraser Tweedale <frase@frase.id.au> Thu, 26 February 2015 04:37 UTC

Return-Path: <frase@frase.id.au>
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 C13311A01CB for <acme@ietfa.amsl.com>; Wed, 25 Feb 2015 20:37:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.628
X-Spam-Level: *
X-Spam-Status: No, score=1.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HOST_EQ_STATIC=1.172, 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 nL8w0R6zayzN for <acme@ietfa.amsl.com>; Wed, 25 Feb 2015 20:37:55 -0800 (PST)
Received: from captainmorgan.hollandpark.frase.id.au (110-174-235-130.static.tpgi.com.au [110.174.235.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F57F1A00F9 for <acme@ietf.org>; Wed, 25 Feb 2015 20:37:54 -0800 (PST)
Received: from bacardi.hollandpark.frase.id.au (bacardi.hollandpark.frase.id.au [192.168.0.100]) by captainmorgan.hollandpark.frase.id.au (8.14.9/8.14.9) with ESMTP id t1Q4bNXg049700; Thu, 26 Feb 2015 14:37:23 +1000 (EST) (envelope-from frase@frase.id.au)
Received: from bacardi.hollandpark.frase.id.au (localhost [127.0.0.1]) by bacardi.hollandpark.frase.id.au (8.14.9/8.14.9) with ESMTP id t1Q4bNHg060313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 26 Feb 2015 14:37:23 +1000 (EST) (envelope-from frase@frase.id.au)
Received: (from fraser@localhost) by bacardi.hollandpark.frase.id.au (8.14.9/8.14.9/Submit) id t1Q4bIPt060312; Thu, 26 Feb 2015 14:37:18 +1000 (EST) (envelope-from frase@frase.id.au)
X-Authentication-Warning: bacardi.hollandpark.frase.id.au: fraser set sender to frase@frase.id.au using -f
Date: Thu, 26 Feb 2015 14:37:18 +1000
From: Fraser Tweedale <frase@frase.id.au>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Message-ID: <20150226043717.GF1553@bacardi.hollandpark.frase.id.au>
References: <CAMm+Lwhx=LE4=kgiU1=YJFC5vPEMaGYi129E8Oc=FHGFAEUQaA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <CAMm+Lwhx=LE4=kgiU1=YJFC5vPEMaGYi129E8Oc=FHGFAEUQaA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/jvHaZZiPEFqSF51NCzF06CxwMBA>
Cc: "acme@ietf.org" <acme@ietf.org>
Subject: Re: [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 04:37:56 -0000

On Wed, Feb 25, 2015 at 10:14:03PM -0500, Phillip Hallam-Baker wrote:
> 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
> 
Please be specific about what JWS serialisation(s) are supported.
Are you intending only the JWS Compact Serialization to be used?

Also, I presume you intend that JWS be used in a "detached content"
mode as described at [1], to avoid duplicating the content in both
the JWS object as well as after the "signatures block?

[1] http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#appendix-F

Finally, why not just use JWS by itself?  The only advantage I can
see to this construction is that the payload is not Base64-encoded.
Is that an important concern?  Important enough to warrant the
additional complexity over just using JWS?

Cheers,
Fraser

> 
> 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 mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme