[Acme] Francesca Palombini's No Objection on draft-ietf-acme-star-delegation-07: (with COMMENT)

Francesca Palombini via Datatracker <noreply@ietf.org> Tue, 06 April 2021 10:37 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 C659B3A1AF2; Tue, 6 Apr 2021 03:37:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Francesca Palombini via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-acme-star-delegation@ietf.org, acme-chairs@ietf.org, acme@ietf.org, ynir.ietf@gmail.com, rsalz@akamai.com, rsalz@akamai.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.27.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Francesca Palombini <francesca.palombini@ericsson.com>
Message-ID: <161770546078.9796.3048793933198959287@ietfa.amsl.com>
Date: Tue, 06 Apr 2021 03:37:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/iX3JfS24MI7ESy-wKMFzPD_Nps4>
Subject: [Acme] Francesca Palombini's No Objection on draft-ietf-acme-star-delegation-07: (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, 06 Apr 2021 10:37:41 -0000

Francesca Palombini has entered the following ballot position for
draft-ietf-acme-star-delegation-07: No Objection

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-star-delegation/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work on this document, which I found clear and easy to read.
You can find some minor comments below. The only one that might require more
attention is 7. about IANA expert guidelines missing. I also have contacted
CBOR wg to double check the CDDL, and will add it here if there is anything
that comes up.

Francesca

1. -----

   the ACME CA and waits for the explicit revocation based on CRL and
   OCSP to propagate to the relying parties.

   ...

   result, the TLS connection to the dCDN edge is done with an SNI equal

FP: Please expand CRL, OCSP and SNI on first use.

2. -----

   *  delegations (required, string): A URL from which a list of
      delegations configured for this account can be fetched via a POST-
      as-GET request.

FP: the second occurrence of "delegation" needs a pointer to the next
subsection - Delegation Objects, otherwise this definition becomes confusing
(delegations is a URL from which a list of delegations can be fetched).

3. -----

   An example delegation object is shown in Figure 3.

FP: please note that the examples are in JSON.

4. -----

   (Forbidden) and type "urn:ietf:params:acme:error:unknownDelegation".

FP: suggestion to change to:

   (Forbidden), providing a problem document [RFC7807] with type 
   "urn:ietf:params:acme:error:unknownDelegation", as registered in section 5.5.

The error type appears later on as well (e.g. section 2.3.2), but even without
repeating each time, I think this reference at least here where it appears
first would help the reader.

5. -----

   The Order object created by the IdO:

   ...

   *  MUST copy the "star-certificate" field from the STAR Order.  The

FP: (suggestion for clarification) because there are 2 Orders going on in
sequence, this bullet point and more precisely "from the STAR Order" is
slightly confusing. You could use Order1 and Order2 as you have used in Figure
1 to clarify things (I believe this should be "from the STAR Order2 into
Order1) (Note that this is just a suggestion, the rest of the text is mostly
clear about which Order it refers to) Otherwise, I think it would be good to
add "... from the STAR Order into its Order resource." The same comment apply
to the next occurrence:

   *  MUST copy the "certificate" field from the Order, as well as

6. -----

   uCDN is configured to delegate to dCDN, and CP is configured to
   delegate to uCDN, both as defined in Section 2.3.1.

FP: Re Figure 12: I assume that 0. refers to the configuration CP and uCDN
share? In this case, why is there no arrow between uCDN and dCDN? If my
assumption is wrong, then what's the meaning of 0?

7. -----

FP: This document defines two new registry, one with policy Specification
required and the other Expert review (both of which will need designated
experts). https://tools.ietf.org/html/rfc8126#section-5.3 states that:

   When a designated expert is used, the documentation should give clear
   guidance to the designated expert, laying out criteria for performing
   an evaluation and reasons for rejecting a request.  In the case where

I have noticed that RFC 8555 only provided guidance for one of its registries,
and that the registries are quite straight forwards, but I still believe that
having some guidance for the experts to evaluate requests helps.