Re: [Acme] Usage of HTTP Re: ACME or EST?

Martin Thomson <martin.thomson@gmail.com> Tue, 25 November 2014 23:29 UTC

Return-Path: <martin.thomson@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 CD2631A87B2 for <acme@ietfa.amsl.com>; Tue, 25 Nov 2014 15:29:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 YXbTQSKG1JrK for <acme@ietfa.amsl.com>; Tue, 25 Nov 2014 15:29:14 -0800 (PST)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D4D1A8723 for <acme@ietf.org>; Tue, 25 Nov 2014 15:29:14 -0800 (PST)
Received: by mail-oi0-f47.google.com with SMTP id v63so1223258oia.6 for <acme@ietf.org>; Tue, 25 Nov 2014 15:29:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rMfB7slW7q+Q0Ts9U62qE5GIIrBvOKCRtDtVUO4k5M0=; b=vRSYK8+8fcEEyF3G+fBZNVjIerkYiM4tAGX56GRmkuYyg5mwFM7yVt/IjdsV30zjpc 1VQ3ZGlMpH4ts3rYLIrFP3Pdk9XXDE3TW/bWMXQivWdgPVIAdg4mAD5nafsI9ER56w28 ffgJ0lYYhjGRwId42wpnb4jFsBCYCnQ0tpc5cUTzzWpc/+kQs4UzCHi3+xEU76XaRnDz ca3+F4XA59JIxHbSO8DfvUaA0onaXma4qzZqdk/Tehnu37CJswD6UM80UzJS4luKaWiT 5nT/Zw5GhfapjItcCS1q0nuYKVO0/UCBRSQgwuHCphjIwPCzMXzhNvRBTAxGJpxjLqFt FMnw==
MIME-Version: 1.0
X-Received: by 10.183.24.129 with SMTP id ii1mr16082084obd.34.1416958153634; Tue, 25 Nov 2014 15:29:13 -0800 (PST)
Received: by 10.202.115.4 with HTTP; Tue, 25 Nov 2014 15:29:13 -0800 (PST)
In-Reply-To: <20141125231612.GW3200@localhost>
References: <CAL02cgTSiugToRqMWAHqcBOVR0RGxLhjkJ-3FyPt6HP-qcV16w@mail.gmail.com> <20141125231612.GW3200@localhost>
Date: Tue, 25 Nov 2014 15:29:13 -0800
Message-ID: <CABkgnnWqtpj7+tyy=FmCX_aOcim9U=1y6G2NRm2hwO0U3xGBAw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/acme/wA9xCnW-Bh7c2P2I9bPC6s5Mt0I
Cc: Richard Barnes <rlb@ipv.sx>, "acme@ietf.org" <acme@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [Acme] Usage of HTTP Re: ACME or EST?
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: Tue, 25 Nov 2014 23:29:16 -0000

On 25 November 2014 at 15:16, Nico Williams <nico@cryptonector.com> wrote:
> I've a feeling that (2) is what the APPSWG folks like, but I'm fine with (1).


I'm not sure if I'm an APPSAWG entity as such, but I would like to add
support to the idea that (2) is a better architectural choice.  For
instance, you might want to create an architecture where one server
does the (expensive) process of identity validation, but issuance and
re-issuance is performed by another.  Follow-your-nose seems entirely
appropriate there.

RFC 7030 is abominable in this regard, but ACME is not significantly
better as it stands.  Better, but not great.

If the intent is to wed the concepts in this protocol to HTTP, then
there are challenges (you can't just send a GET request with a body),
but I don't think that the current proposal is in line with current
design paradigms.