Re: [Acme] HTTP/J Draft

Fraser Tweedale <frase@frase.id.au> Fri, 27 February 2015 03:13 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 EC2AE1A00E4 for <acme@ietfa.amsl.com>; Thu, 26 Feb 2015 19:13:16 -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 AvXLkvdsgv4k for <acme@ietfa.amsl.com>; Thu, 26 Feb 2015 19:13:12 -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 E292D1A00ED for <acme@ietf.org>; Thu, 26 Feb 2015 19:13:11 -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 t1R3CgNH062066; Fri, 27 Feb 2015 13:12:42 +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 t1R3CgfU075052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Feb 2015 13:12:42 +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 t1R3CbmW075051; Fri, 27 Feb 2015 13:12:37 +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: Fri, 27 Feb 2015 13:12:36 +1000
From: Fraser Tweedale <frase@frase.id.au>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Message-ID: <20150227031235.GJ1553@bacardi.hollandpark.frase.id.au>
References: <CAMm+Lwhx=LE4=kgiU1=YJFC5vPEMaGYi129E8Oc=FHGFAEUQaA@mail.gmail.com> <20150226043717.GF1553@bacardi.hollandpark.frase.id.au> <CAMm+LwgVzaKraB1hDMT=1TbehMsSSTjOvcfqP6SU9DAStmay2A@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+LwgVzaKraB1hDMT=1TbehMsSSTjOvcfqP6SU9DAStmay2A@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/z67vwee57Ewc2kd2gIhqyAMQLjY>
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: Fri, 27 Feb 2015 03:13:17 -0000

On Thu, Feb 26, 2015 at 08:15:57AM -0500, Phillip Hallam-Baker wrote:
> Yes, Base64 is a deal breaker.
> 
> Try reading the JWS specs and it is impossible to make sense of them
> because they are just a series of base64 blobs.
> 
> There is zero point in using a text encoding and then making it impossible
> to read.
> 
> 
> On the detached signature side yes, it is going to be some sort of detached
> mode and if JWS can't do that we can use something else (the section you
> link to is incoherent).
> 
It states that there is no explicit support in JWS for a detached
signature mode, and that it is the application's responisbility to
remove and restore the payload to the appropriate place in the JWS
Serialization before processing.

It is straightforward, and IMO preferable to a custom signature
construction.

> Let us make things easy here. A digital signature signs a stream of bits,
> so that signed stream of bits should appear in the protocol message.
> 
> JWS is still a big improvement on the XML signature lunacy with XPATH and
> XSLT to allow the signature to turn the document inside out. Bletch.
> 
> 
> On Wed, Feb 25, 2015 at 11:37 PM, Fraser Tweedale <frase@frase.id.au> wrote:
> 
> > 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
> >
> >