Re: [Acme] HTTP/J Draft

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 26 February 2015 13:16 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 DB6C51A00D8 for <acme@ietfa.amsl.com>; Thu, 26 Feb 2015 05:16:03 -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 nNsKyTz2MY9O for <acme@ietfa.amsl.com>; Thu, 26 Feb 2015 05:16:01 -0800 (PST)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (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 B77751A00FE for <acme@ietf.org>; Thu, 26 Feb 2015 05:15:58 -0800 (PST)
Received: by labhs14 with SMTP id hs14so10855342lab.1 for <acme@ietf.org>; Thu, 26 Feb 2015 05:15:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IBQiyohZUgGCztguMKybC3gDoeNpUHJ21V5ixylGdY4=; b=CnLFEHOCs/UehJufzmbyatXlpZyX3HY/SvBIN+7r5qYQq+35V2Y0TOVYbryYWXgZqQ lKIYPxfbHXD3lbwQPvWhzuqL5Em9EPBVmxzMiDMjcLxcQK9Nq1ggxYTGakziz7JXjnKI 4wPa4LMWI56ecGL3auNJ3V4+PEwff3FSRFQ58pdi6OplKWSBMhSU/FiiCViM4pkVkdq1 IGaLKaNzd4qRk0b4e4eCArWYroqWFley6yiVqWNU/FAHZUuj9M+qxCCE/S+xYDeBIZ+f hecj5BLkC0XfkfCfQ+MqdnJxPbs8ePPtJWIg5PfPDHiixQaQc6ZzFsyOZyqDbd24YNZ1 Hx9w==
MIME-Version: 1.0
X-Received: by 10.112.147.66 with SMTP id ti2mr7566603lbb.124.1424956557142; Thu, 26 Feb 2015 05:15:57 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.113.3.165 with HTTP; Thu, 26 Feb 2015 05:15:57 -0800 (PST)
In-Reply-To: <20150226043717.GF1553@bacardi.hollandpark.frase.id.au>
References: <CAMm+Lwhx=LE4=kgiU1=YJFC5vPEMaGYi129E8Oc=FHGFAEUQaA@mail.gmail.com> <20150226043717.GF1553@bacardi.hollandpark.frase.id.au>
Date: Thu, 26 Feb 2015 08:15:57 -0500
X-Google-Sender-Auth: WX0fjQPUz-mxPjtuZzz9niD_TEY
Message-ID: <CAMm+LwgVzaKraB1hDMT=1TbehMsSSTjOvcfqP6SU9DAStmay2A@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Fraser Tweedale <frase@frase.id.au>
Content-Type: multipart/alternative; boundary=047d7b3a869068b2ae050ffd8dcd
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/EBQqHcE4TYwnKd4266YCpw3vej8>
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 13:16:04 -0000

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

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