[Acme] Proposed ACME Charter Language

Russ Housley <housley@vigilsec.com> Mon, 20 April 2015 15:24 UTC

Return-Path: <housley@vigilsec.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 141BD1B2EE6 for <acme@ietfa.amsl.com>; Mon, 20 Apr 2015 08:24:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.5
X-Spam-Level:
X-Spam-Status: No, score=-100.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, USER_IN_WHITELIST=-100] 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 ImunajuJ6KF9 for <acme@ietfa.amsl.com>; Mon, 20 Apr 2015 08:24:25 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 49D241B2EE5 for <acme@ietf.org>; Mon, 20 Apr 2015 08:24:25 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id AED029A4021 for <acme@ietf.org>; Mon, 20 Apr 2015 11:24:14 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id EzP1bouuQijk for <acme@ietf.org>; Mon, 20 Apr 2015 11:23:53 -0400 (EDT)
Received: from [192.168.2.100] (pool-96-255-133-185.washdc.fios.verizon.net [96.255.133.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 8763B9A401A for <acme@ietf.org>; Mon, 20 Apr 2015 11:23:53 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 20 Apr 2015 11:23:42 -0400
Message-Id: <6A9C3116-8CC9-472C-8AA8-F555D060834C@vigilsec.com>
To: IETF ACME <acme@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/lJeRUQTgOaRMg3EBsUmBMwn0Pz4>
Subject: [Acme] Proposed ACME Charter Language
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: Mon, 20 Apr 2015 15:24:27 -0000

At the end of the ACME BoF, it was suggested that the next step was charter language.  I took a stab at some to get the discussion going.

I did not consider milestones yet.  I think it is easier to get consensus on the charter text and then discuss milestones.

Please review and comment.

Russ

= = = = = = = 

Automated Certificate Management Environment (ACME)

Historically, issuance of certificates for Internet applications
(e.g., web servers) has involved many manual identity validation steps
by the certification authority (CA).  The ACME WG will specify
conventions for automated X.509 certificate management, including
validation of control over an identifier, certificate issuance,
certificate renewal, and certificate revocation.  The initial focus of
the ACME WG will be on domain name certificates (as used by web
servers), but other uses of certificates can be considered as work
progresses.

ACME certificate management must allow the CA to verify, in an
automated manner, that the party requesting a certificate has authority
over the requested identifiers, including the subject and subject
alternative names.  The processing must also confirm that the requesting
party has access to the private key that corresponds to the public key
that will appear in the certificate.  All of the processing must be done
in a manner that is compatible with common service deployment
environments, such as hosting environments.

ACME certificate management must, in an automated manner, allow a
party that has previously requested a certificate to subsequently
request revocation of that certificate.

In order to facilitate deployment by CAs, the ACME protocol must be
compatible with common industry standards for the operation of a CA,
for example the CA/Browser Forum Baseline Requirements [0].

The ACME WG will not duplicate work from previous IETF
certificate management efforts.  If it is necessary to develop a
replacement for previous effort, the ACME WG will document the aspects
of that work that prevent it from being used for the envisioned
automated tasks.

The starting point for ACME WG discussions shall be draft-barnes-acme.

[0] https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf