[cabf_validation] Fwd: [Acme] Protocol Action: 'ACME TLS ALPN Challenge Extension' to Proposed Standard (draft-ietf-acme-tls-alpn-07.txt)

Jacob Hoffman-Andrews jsha at letsencrypt.org
Fri Oct 18 10:49:28 MST 2019


This still has a few steps to go through to become an RFC; I think it makes
sense to wait for now.

On Thu, Oct 17, 2019 at 5:54 PM Wayne Thayer via Validation <
validation at cabforum.org> wrote:

> Should we go ahead now and replace method 10 with this?
>
> - Wayne
>
> ---------- Forwarded message ---------
> From: The IESG <iesg-secretary at ietf.org>
> Date: Thu, Oct 17, 2019 at 12:32 PM
> Subject: [Acme] Protocol Action: 'ACME TLS ALPN Challenge Extension' to
> Proposed Standard (draft-ietf-acme-tls-alpn-07.txt)
> To: IETF-Announce <ietf-announce at ietf.org>
> Cc: <rdd at cert.org>, <cpu at letsencrypt.org>, <acme at ietf.org>, <
> draft-ietf-acme-tls-alpn at ietf.org>, The IESG <iesg at ietf.org>, <
> acme-chairs at ietf.org>, <rfc-editor at rfc-editor.org>
>
>
> 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:
> https://datatracker.ietf.org/doc/draft-ietf-acme-tls-alpn/
>
>
>
>
>
> 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.
>
> Personnel
>
> The document shepard is Daniel McCarney.
>
> The responsible area director is Roman Danyliw.
>
> _______________________________________________
> Acme mailing list
> Acme at ietf.org
> https://www.ietf.org/mailman/listinfo/acme
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20191018/ea6bdf19/attachment.html>


More information about the Validation mailing list