Automatic Certificate Management Environment (ACME)
draft-ietf-acme-acme-18

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Yoav Nir <ynir.ietf@gmail.com>, ekr@rtfm.com, The IESG <iesg@ietf.org>, draft-ietf-acme-acme@ietf.org, acme@ietf.org, ynir.ietf@gmail.com, acme-chairs@ietf.org, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'Automatic Certificate Management Environment (ACME)' to Proposed Standard (draft-ietf-acme-acme-18.txt)

The IESG has approved the following document:
- 'Automatic Certificate Management Environment (ACME)'
  (draft-ietf-acme-acme-18.txt) as Proposed Standard

This document is the product of the Automated Certificate Management
Environment Working Group.

The IESG contact persons are Benjamin Kaduk and Eric Rescorla.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-acme/


Summary
   Richard Barnes, Jacob Hoffman-Andrews, and James Kasten are the authors. 
   Yoav Nir is the document shepherd. Eric Rescorla is the responsible Area 
   Director.
   
   Certificates in PKI using X.509 (PKIX) are used for a number of
   purposes, the most significant of which is the authentication of
   domain names.  Thus, certificate authorities in the Web PKI are
   trusted to verify that an applicant for a certificate legitimately
   represents the domain name(s) in the certificate.  Today, this
   verification is done through a collection of ad hoc mechanisms.  This
   document describes a protocol that a certification authority (CA) and
   an 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
   revocation.
   
Review and Consensus
   This document represents the consensus of the ACME working group. The draft
   has been the main document of the group for the last two years, and has been
   through WGLC since February 2017. 
   Much of the discussion since then has been feedback from commercial CAs 
   about integrating the protocol with their processes. Several of them are now 
   committed to deploy this protocol following publication.
   Most of the session in IETF 99 was devoted to verifying that there are no 
   more open issues for this draft.

Intellectual Property
   The authors have stated that they do not have any IPR related to this 
   document, and that they are not aware of any IPR claims made by others about 
   the content of this document.

Other Points
   None

IANA Note

The following registries are established with a "specification required" per RFC8126:
   1.  ACME Account Object Fields (Section 9.7.1)
   2.  ACME Order Object Fields (Section 9.7.2)
   3.  ACME Error Types (Section 9.7.3)
   4.  ACME Resource Types (Section 9.7.4)
   5.  ACME Identifier Types (Section 9.7.5)
   6.  ACME Challenge Types (Section 9.7.6)

Entries are requested to be added to the following registries:
"Media Types", "Well-Known URIs", "Message Headers", 
"JSON Web Signature and Encryption Header Parameters", 
"JSON Web Signature and Encryption Header Parameters", and 
"IETF URN Sub-namespace for Registered Protocol Parameter 
 Identifiers"