Re: [Acme] kinds of proof

Peter Bowen <pzbowen@gmail.com> Tue, 02 December 2014 17:37 UTC

Return-Path: <pzbowen@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 042391A1AE6 for <acme@ietfa.amsl.com>; Tue, 2 Dec 2014 09:37:30 -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 sTPa9phSRvv9 for <acme@ietfa.amsl.com>; Tue, 2 Dec 2014 09:37:25 -0800 (PST)
Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B77691A1B4F for <acme@ietf.org>; Tue, 2 Dec 2014 09:37:19 -0800 (PST)
Received: by mail-pd0-f176.google.com with SMTP id y10so13570306pdj.21 for <acme@ietf.org>; Tue, 02 Dec 2014 09:37:19 -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:content-transfer-encoding; bh=hL0f1shutiIMf1KTSEadGdG5y23u8e2QDZXnmYBrJto=; b=stPYiTcWmYy8rGpYEVvuMdjzaRXUH8yKZD6o4MNdOodiFCSZIh/Ind9RvgQGswFgYP Pfbeo7ONhxBhc/79wZt2Y7/B+9sY8Dh+51A88IW+4OlcxfVQMPstMIlnZo8SfpLKJUP3 6MohsZQkmdxShAlA/JRJMAzh4UQaV3GrCqLMR4g3jvFN1POElkCVGIzSxsQicVNT+fmd RLfhX5pyH08bfGJ5UnvkaF+/PBR8LDkYdcTCbW7/w+/fg6c5zrYUWgQh0PPfJzz7joxg rjJZhoFIW7hUaX+MiqdqjIMEtxDHbu1UM135ouQIHdOvd7FKb+pGmCMeXfiHXNrOVFeQ +LLA==
MIME-Version: 1.0
X-Received: by 10.66.221.198 with SMTP id qg6mr743711pac.106.1417541838360; Tue, 02 Dec 2014 09:37:18 -0800 (PST)
Received: by 10.70.76.10 with HTTP; Tue, 2 Dec 2014 09:37:18 -0800 (PST)
In-Reply-To: <B303B16C-C282-4C15-99D1-BC59B9FC3989@vpnc.org>
References: <20141127211348.GE25114@mournblade.imrryr.org> <54784C61.2080508@cs.tcd.ie> <20141128170917.GC285@mournblade.imrryr.org> <88B49E1D-1601-4B86-8D93-14CF71501DFC@vpnc.org> <20141128213724.GG285@mournblade.imrryr.org> <7261AA75-5912-4514-A393-94F602C941C2@vpnc.org> <20141129170537.GK285@mournblade.imrryr.org> <m2tx1ehq63.wl%randy@psg.com> <CAK6vND83ehPaMtKm0i9nX2H+8k-xo_ztuh+fbnETn7HaoZqr3Q@mail.gmail.com> <DM2PR0301MB0655E1CABDDFF7E3198CA2BFA87A0@DM2PR0301MB0655.namprd03.prod.outlook.com> <20141202025438.GH285@mournblade.imrryr.org> <CAK6vND9GYED3T=2V1fL1M8eCwGz23PCAFOcaZAbxjTG5xtY2Tw@mail.gmail.com> <B303B16C-C282-4C15-99D1-BC59B9FC3989@vpnc.org>
Date: Tue, 2 Dec 2014 09:37:18 -0800
Message-ID: <CAK6vND_g0cRTxTrOc_-Q2wgm4_jgaABGHW9VBas5hhUT8zsi7g@mail.gmail.com>
From: Peter Bowen <pzbowen@gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/acme/T9rT0rtGfz110r5N2B9SsIpLmec
Cc: acme@ietf.org
Subject: Re: [Acme] kinds of proof
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, 02 Dec 2014 17:37:30 -0000

On Tue, Dec 2, 2014 at 9:29 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> Greetings. It seems that some people want ACME to force a higher level of assurance on the protocol than those of us who are trying to get more authenticated encryption everywhere would want. Given that we still don't have a published Internet Draft (ahem), it would be good to come to agreement early on what is going to be required.
>
> A specific use case that is important to me is someone running a web server on a commercial hoster should be able to get a TLS cert using ACME even if the hoster does not have its own ACME support. The site admin in that case should be able to run an ACME client on their laptop and be able to go through the ACME steps needed to get a cert that they can load into their web site, then tell the hoster to turn on port 443.
>
> If the hoster supports the ACME steps itself, the web admin might not even need to do anything: the hoster can run ACME for them to get the cert. Given that hosters are always trying to cut customer service costs, ACME should allow hosters to automate the cert process to the point where no human interaction is needed after the hoster decides "this site will now use HTTPS".

I would also encourage that the case be supported where the "hoster"
controls the DNS but not the content on the site.   This is the
situation for most CDNs and Load Balancing services.  Technically the
CDN/LB could special case responses for a well known path, as it is
handling the HTTP connection, but it is frequently easier to validate
control via DNS.

> Proposal:
>
> - ACME clients and servers can be run without human interaction during the ACME exchange itself. All configuration can be done before the ACME client initiates the session, as long as the system running the ACME client has control over the service for which the certificate is being issued. A human may need to make manual changes if their system does not have an ACME setup, but the ACME protocol supports full automation as well.
>
> - A CA must verify that the system on which the ACME client is running can control the service for which the certificate is being issued.

If the ACME client can change DNS, then it clearly can effectively
control the service (FQDN) for which the certificate is being issued.

> - The system running the ACME client does not have to have control over the DNS service that controls the domain name being used in the requested certificate; however, particular DNS control can be required by policy by an ACME server.

I would expect an ACME server can choose to support DNS-based
verification, HTTP-based verification, TLS-based verification, or some
combination thereof.

> - The ACME protocol has to have expressive enough semantics so that an ACME server can tell an ACME client in detail what policy is causing the ACME server to reject a particular certificate request.
>
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme