Re: [Acme] kinds of proof

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 02 December 2014 17:29 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 4A76C1A1AD8 for <acme@ietfa.amsl.com>; Tue, 2 Dec 2014 09:29:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.647
X-Spam-Level:
X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 36T82qI6PTxO for <acme@ietfa.amsl.com>; Tue, 2 Dec 2014 09:29:53 -0800 (PST)
Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8555E1A1C06 for <acme@ietf.org>; Tue, 2 Dec 2014 09:29:53 -0800 (PST)
Received: from [10.20.30.90] (142-254-17-119.dsl.dynamic.fusionbroadband.com [142.254.17.119]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sB2HTqxZ059197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <acme@ietf.org>; Tue, 2 Dec 2014 10:29:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 142-254-17-119.dsl.dynamic.fusionbroadband.com [142.254.17.119] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CAK6vND9GYED3T=2V1fL1M8eCwGz23PCAFOcaZAbxjTG5xtY2Tw@mail.gmail.com>
Date: Tue, 2 Dec 2014 09:29:51 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: acme@ietf.org
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/acme/jzlEudL0edYYvBbW-sMmLjZ8WMs
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:29:55 -0000

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

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.

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

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