Automated Certificate Management Environment (acme)
| WG | Name | Automated Certificate Management Environment | |
|---|---|---|---|
| Acronym | acme | ||
| Area | Security Area(sec) | ||
| State | Active | ||
| Charter | charter-ietf-acme-01Approved | ||
| Status update | Show Changed 2018-07-19 | ||
| Document dependencies | |||
| Additional resources | Issue tracker, Wiki, Zulip Stream | ||
| Personnel | Chairs | Mike Ounsworth,Yoav Nir | |
| Area Director | Deb Cooley | ||
| Delegate | Deb Cooley | ||
| Mailing list | Address | acme@ietf.org | |
| To subscribe | https://www.ietf.org/mailman/listinfo/acme | ||
| Archive | https://mailarchive.ietf.org/arch/browse/acme/ | ||
| Chat | Room address | https://zulip.ietf.org/#narrow/stream/acme |
Charter for Working Group
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 an
authorized party to request revocation of a certificate.
The ACME working group is specifying ways to automate certificate
issuance, validation, revocation and renewal. The ACME working
group is not reviewing or producing certificate policies or
practices.
The starting point for ACME WG discussions shall be draft-barnes-acme.
Milestones
| Date | Milestone | Associated documents |
|---|---|---|
| Nov 2024 | Senddraft-ietf-acme-dns-account-challenge to the IESG for standards track publication | draft-ietf-acme-dns-account-challenge |
| Jul 2024 | End user client and code signing certificates extension submitted to IESG or abandoned | draft-ietf-acme-client |
Done milestones
| Date | Milestone | Associated documents |
|---|---|---|
| Done | Send Renewal Information Extension to the IESG for standards track publication | rfc9773 (was draft-ietf-acme-ari) |
| Done | Senddraft-ietf-acme-onion the IESG for standards track publication | rfc9799 (was draft-ietf-acme-onion) |
| Done | Delay-Tolerant Networking (DTN) extensions submitted to IESG | rfc9891 (was draft-ietf-acme-dtnnodeid) |
| Done | ACME integration with with EST, BRSKI and TEAP use cases submitted to IESG | draft-ietf-acme-integrations |
| Done | Profile for delegated STAR certificates submitted to IESG | rfc9115 (was draft-ietf-acme-star-delegation) |
| Done | TNAuthlist extension submitted to IESG | rfc9447 (was draft-ietf-acme-authority-token) rfc9448 (was draft-ietf-acme-authority-token-tnauthlist) |
| Done | S/MIME extension submitted to IESG | rfc8823 (was draft-ietf-acme-email-smime) |
| Done | Submit working group draft to IESG as Proposed Standard | rfc8555 (was draft-ietf-acme-acme) |
| Done | Initial working group draft |