[Acme] ACME or EST?

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 25 November 2014 21:41 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 65EE91A88F9 for <acme@ietfa.amsl.com>; Tue, 25 Nov 2014 13:41:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.647
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id NM7japLbSqKP for <acme@ietfa.amsl.com>; Tue, 25 Nov 2014 13:41:22 -0800 (PST)
Received: from proper.com (Hoffman.Proper.COM []) (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 D9D611A8940 for <acme@ietf.org>; Tue, 25 Nov 2014 13:41:21 -0800 (PST)
Received: from [] (142-254-17-143.dsl.dynamic.fusionbroadband.com []) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sAPLfJ9H035148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <acme@ietf.org>; Tue, 25 Nov 2014 14:41:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 142-254-17-143.dsl.dynamic.fusionbroadband.com [] claimed to be []
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <AD5940AA-6F01-4D0E-A4E0-19AEA56BBED3@vpnc.org>
Date: Tue, 25 Nov 2014 13:41:19 -0800
To: acme@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/acme/pUEJGrXo6QDlaIbNXORcChqO-eE
Subject: [Acme] 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 21:41:24 -0000

Greetings again. The abstract of the ACME pre-draft at https://github.com/letsencrypt/acme-spec (which Richard will hopefully publish as a real draft soon) says:

   document describes a protocol that a certificate authority (CA) and a
   applicant can use to automate the process of verification and
   certificate issuance. The protocol also provides facilities for
   other certificate management functions, such as certificate

This overlaps a lot with "Enrollment over Secure Transport" (EST), <https://tools.ietf.org/html/rfc7030>.

For many people who saw last week's announcement, the main use case of ACME is "make it easy to create a client that can create a key, get it enrolled with a server, get the new certificate back, and install that certificate in a web server". What does/will ACME offer that EST does not already?

--Paul Hoffman