Skip to main content

Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc:, The IESG <>, Daniel McCarney <>,,,,,
Subject: Protocol Action: 'ACME TLS ALPN Challenge Extension' to Proposed Standard (draft-ietf-acme-tls-alpn-07.txt)

The IESG has approved the following document:
- 'ACME TLS ALPN Challenge Extension'
  (draft-ietf-acme-tls-alpn-07.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 Roman Danyliw.

A URL of this Internet Draft is:

Ballot Text

Technical Summary

The ACME-TLS-ALPN draft extends the Automatic Certificate Management Environment
(ACME) with a new domain validation challenge type (tls-alpn-01) that can be
performed at the TLS layer alone. This challenge type meets the need of users
(hosting providers, CDNs, etc) who wish to prove authorization of a DNS
identifier without modifying HTTP handling behaviour or updating DNS zone data.
This is the spiritual successor to the deprecated/removed TLS-SNI-01/02
challenge types from earlier ACME drafts.

Working Group Summary

There is WG consensus on the document

Earlier drafts specified a id-pe-acmeIdentifier OID that was already assigned by
IANA. This has been addressed in the latest draft. The ASN.1 format of the
id-pe-acmeIdentifier was also both simplified (removing an unneeded subarc from
the OID) and clarified (to emphasize the SHA-256 digest value).

Document Quality

Let's Encrypt, a high-volume ACME based CA, has fully implemented the
tls-alpn-01 challenge type and has been issuing certificates in production using
this challenge type since July 12th, 2018. Multiple independent ACME clients
have implemented support for this challenge type.

The overall document quality is high. Developing an implementation based on the
specification text is reasonable. Interoperable client/server implementations
exist and are in use in a production setting.


The document shepard is Daniel McCarney. 

The responsible area director is Roman Danyliw.

RFC Editor Note