Subject: [Acme] Benjamin Kaduk's No Objection on draft-ietf-acme-star-delegation-08: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 09 Jun 2021 15:59:24 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-star-delegation-08: 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 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:
----------------------------------------------------------------------

Thanks for the (extensive!) changes to resolve my previous review remarks!
Just a few notes left from looking at the diff between -07 and -08:

Section 2.3.1.3

   In order to indicate which specific delegation applies to the
   requested certificate a new "delegation" attribute is added to the
   Order object on the NDC-IdO side (see Figure 4).  The value of this

We might want to get the phrase "request object" in here somehow, since
we go on to talk about returning an error response, which is of course
only possible if there is a corresponding request.  (The next section
does talk about the "request object created by the NDC").

Section 2.3.2

   If the delegation is for a STAR certificate, the request object
   created by the NDC:
   [...]
   *  MUST have entries in the "identifiers" field for each delegated
      name present in the configuration;

Just to confirm: this is saying that the request/order must request a
certificate for all names covered by the delegation; it cannot request
only a subset of the names in the particular delegation object?  On
first read this seems a bit restrictive, but I suppose it can make state
handling at the IdO easier since the information from the delegation
object can be used to construct the request to the actual CA.
(Similarly for the non-STAR case in §2.3.3, of course.)

The example delegation URL in Figure 4 doesn't match the URL structure
used for the example delegation list in Section 2.3.1.2.  (This is not
inherently problematic, but could cause a small amount of reader
confusion.)  The same identifier occurs in several subsequent figures,
as well.

Section 2.4

[Just noting that the text about the IdO being able to decide on a
per-identity basis whether to proxy vs act as IdO remains confusing to
me, but this is the same comment I made on the previous version and I
expect no further changes to be made and no further discussion on the
topic.]

Section 3

   Although most of this document, and in particular Section 2 is
   focused on the protocol between the NDC and to IdO, the protocol does
   affect the ACME server running in the CA.  A CA that wishes to
   support certificate delegation MUST also support unauthenticated

Is it correct to say "non-STAR certificate delegation" here?  (The
corresponding change needed to support STAR delegation would have been
done already to support non-delegated STAR issuance, if I understand
correctly.)

Section 7.2

   The ACME account associated with the delegation plays a crucial role
   in the overall security of the presented protocol.  This, in turn,
   means that in delegation scenarios the security requirements and
   verification associated with an ACME account may be more stringent
   than in traditional ACME, since the out-of-band configuration of
   delegations that an account is authorized to use, combined with
   account authentication, takes the place of the normal ACME
   authorization challenge procedures.  Therefore, the IdO MUST ensure
   that each account is associated with the exact policy (via a
   "delegation" object) that defines which domain names can be delegated
   to the account and how.  The IdO is expected to use out of band means
   to pre-register each NDC to the corresponding account.

Please double-check and confirm that the singular 'policy' and
'"delegation" object" are as intended here.  IIRC we do allow multiple
delegation objects to be associated with a single account.