[Acme] Adam Roach's Yes on draft-ietf-acme-tls-alpn-06: (with COMMENT)
Adam Roach via Datatracker <noreply@ietf.org> Tue, 01 October 2019 05:29 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: acme@ietf.org
Delivered-To: acme@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F67812002E; Mon, 30 Sep 2019 22:29:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-acme-tls-alpn@ietf.org, Daniel McCarney <cpu@letsencrypt.org>, acme-chairs@ietf.org, cpu@letsencrypt.org, acme@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.103.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Adam Roach <adam@nostrum.com>
Message-ID: <156990777251.24033.18215055468280561834.idtracker@ietfa.amsl.com>
Date: Mon, 30 Sep 2019 22:29:32 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/zXYlq2ouGwIv9ZMwZY4KWnJ319M>
Subject: [Acme] Adam Roach's Yes on draft-ietf-acme-tls-alpn-06: (with COMMENT)
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 01 Oct 2019 05:29:32 -0000
Adam Roach has entered the following ballot position for draft-ietf-acme-tls-alpn-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-acme-tls-alpn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for all the work that has gone into creating a viable TLS-based mechanism for ACME validation. I have one fairly important (yet trivial to fix) comment, and a small number of editorial suggestions. I also have read through the ARTART review, and endorse Martin's comments. Please respond to that review, and incorporate his suggestions as you feel appropriate. --------------------------------------------------------------------------- §1: > The Automatic Certificate Management Environment (ACME) [RFC8555] > standard specifies methods for validating control of domain names via > HTTP and DNS. As a fairly major comment, RFC 8555 is not a standard. See RFCs 2026 and 6410 for details. Please rephrase this text along the lines of: The Automatic Certificate Management Environment (ACME) [RFC8555] specification describes methods for validating control of domain names via HTTP and DNS. --------------------------------------------------------------------------- §3: > The TLS with Application Layer Protocol Negotiation (TLS ALPN) > validation method proves control over a domain name by requiring the > client to configure a TLS server to respond to specific connection > attempts utilizing the ALPN extension with identifying information. This took a couple of readings before I understood what it meant. It might make things clearer if the role of the client were clearer; e.g., "...by requiring the ACME client to configure a TLS server..." This is also true throughout much of this section, where "client" and "server" are used without qualification to talk about ACME clients and ACME servers. Consider qualifying such instances. --------------------------------------------------------------------------- §3: > The client prepares for validation by constructing a self-signed > certificate which MUST contain a acmeIdentifier extension Nit: "...contain an acmeIdentifier..." --------------------------------------------------------------------------- §3: > 3. The AMCE server initiates a TLS connection to the chosen IP > address, this connection MUST use TCP port 443. The ACME server > MUST provide a ALPN extension with the single protocol name > "acme-tls/1" and a SNI extension containing only the domain name > being validated during the TLS handshake. Nit: "...chosen IP address. This connection..." Nit: "...an ALPN..." Nit: "...an SNI..." --------------------------------------------------------------------------- §5: Unlike section 3, this section appears to use unqualified "server" to mean "HTTPS server" or somesuch, rather than "ACME server". These *definitely* need to be qualified.
- [Acme] Adam Roach's Yes on draft-ietf-acme-tls-al… Adam Roach via Datatracker