An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates
draft-ietf-acme-star-delegation-09

[Ballot 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.

[Ballot comment]
Thank you for addressing my DISCUSS and the non blocking comments (archived at https://mailarchive.ietf.org/arch/msg/acme/KojTzwwWZrWnOI7bCErfeJq_YVk/ ).

Thanks again to Carsten Bormann and Richard Barnes for their reviews!

Francesca

[Ballot comment]
Thank you for addressing my DISCUSS and the non blocking comments (archived at https://mailarchive.ietf.org/arch/msg/acme/KojTzwwWZrWnOI7bCErfeJq_YVk/ ).

Thanks again to Carsten Bormann and Richard Barnes for their review!

Francesca

[Ballot discuss]
This document requires the use of per-delegation-object URLs in the
order request object but does not provide a way to obtain such URLs
(only a URL for a list of delegations associated to an account is
available, not per-delegation URLs).

I agree with Francesca and the DE that attaching the "delegation"
attribute to the identifier makes less sense than attaching it to the
order; accordingly, I support Francesca's Discuss.

Similarly (and relatedly), there seems to be an object structure
mismatch while using a CSR to finalize an order, that may merit some
discussion.  Each delegation can have its own CSR template, but if a
single order is to have the possibility to incorporate multiple
identifiers, and each identifier has its own delegation, then there's no
reason to expect that a single CSR can be compatible with the templates
from the disparate delegations invoked in a single order.  We could in
principle just require that the CSR templates must be "consistent" (and
define what that means) in scenarios with multiple identifiers in a
single order, but it seems better if we can restructure the object model
so things are more naturally aligned.  Taken to an extreme, this would
entirely divorce CSR template objects from delegation objects, with a
URL for the associated CSR template object being an attribute of a
delegation.  Then we could have something like multiple identifiers and
multiple delegations in an order, provided that they all refer to the
same CSR template object.

I also don't think I understand the need for having
"allow-certificate-get" in the Order Object (nor its semantics) -- what
do we gain from having it in the Object itself that is not achieved by
the existing newOrder request payload?  As far as I can tell the we only
talk about writing to it in the rest of the document, and never have to
read or consult its value.  If it is necessary, it seems like the
document needs to be more clear about why.

[Ballot comment]
I made a pull request at https://github.com/yaronf/I-D/pull/175 with
some suggestions, including some mentioned in the comments below.  They
are not really all editorial, though, as a result.

I feel like it would be approprate to have a dedicated (sub)section for
the delegation objects list, that covers in a little more detail the use
of the value in the "delegations" attribute of the Account Object and
gives a more prominent home for noting that POST-as-GET to it returns a
list of delegations associated with the account.  Consider, for example,
§7.1.2.1 of RFC 8555.  (Such a section would also provide a way to
specify how URLs for individual delegation objects are constructed, per
the discuss point.)

Section 1.1

  CA  A Certification Authority that implements the ACME protocol.  In
      this document, the term is synonymous with "ACME server".

RFC 8555 is careful to distinguish between ACME server and CA, and I'm
not sure that we get much value from coalescing the two, here.
If we do keep the concepts separate, then we could skip the note in
Section 2.1 that points out that ACME server and CA are not the same!

Section 2

  This section presents the protocol flow.  For completeness, we
  include the ACME profile proposed in this document as well as the
  extended ACME protocol described in [RFC8739].

nit: extended with respect to which baseline?

Section 2.2

  Note that the interactive identifier authorization phase described in
  Section 7.5 of [RFC8555] is suppressed on the NDC-IdO side because
  the delegated identity contained in the CSR presented to the IdO is
  validated against the configured CSR template (Section 2.3.1).
  Therefore, the NDC sends the finalize request, including the CSR, to
  the IdO immediately after Order1 has been acknowledged.  The IdO
  SHALL buffer a (valid) CSR until the Validation phase completes
  successfully.

I'd consider also noting that the negotiation of the "unauthenticated
GET" for the star-certificate URL (per RFC 8793) is required in order
for copying the star-certificate URL from Order2 to Order1 to be useful.

Also, we haven't defined the "validation phase" yet, so a
forward-reference might be helpful.

Section 2.3.1.1

    "orders": "https://example.com/acme/orders/rzGoeA",

I recommend not reusing the "orders" URL from RFC 8555 in the example,
since the RFC 8555 account instance did not have a "delegations"
attribute.

Section 2.3.1.2

The "cname-map" example is not very enlightening to me.
Given the description that the map "name is the delgated identifier" it
would seem like the map name is going to be the name that's in the
issued cert, i.e., a name in the IdO's control.  Logically, then the map
value would have to be a name in the NDC's control, with a CNAME in the
IdO's zone.  The owner name of the CNAME is the delegated identifier and
the RDATA of the CNAME is the target name under the NDC's control.  But
in the example the map name contains both "ndc" and "ido" -- the
public-facing delegated name should *not* reference the "ndc", since
that name needs to remain valid even if the IdO terminates the
delegation and switches to self-hosting or a different CDN.

  *  cname-map (optional, object): a map of FQDN pairs.  In each pair,
      the name is the delegated identifier, the value is the
      corresponding IdO name that is aliased in the IdO's zone file to
      redirect the resolvers to the delegated entity.  Both names and

nit: this text also confused me at first, since it has a construction of the
form "aliased [...] to", but it is not actually of the form "X is
aliased to Y" -- instead, it's "X is aliased in order to Y".  If we
could instead refer to it as a "target" (or maybe just add the "in order
to" phrasing), I think that would help readability.

      "subject": {
        "country": "CA",
        "stateOrProvince": "**",
        "locality": "**",
        "commonName": "**"

It's not clear to me that it's a useful example to have stateOrProvince
and locality be mandatory, and to have the value of commonName left up
to the client.  (Perhaps we should just skip commonName entirely given
draft-ietf-uta-use-san.)

  If the "delegation" attribute in the Order object contains a URL that
  does not correspond to a configuration available to the requesting
  NDC, the IdO MUST return an error response with status code 403

I think we want the delegation to be bound to the ACME account (vs NDC)
and should say that here; the NDC is potentially a more coarse-grained
concept.  (Note also my remark on §6.1.)

Section 2.3.2

  If the delegation is for a STAR certificate, the Order object created
  by the NDC:

I'd be careful about the phrasing "Order object created by" -- this
usage appears to be having "created" mean "used to populate the body of
a POST request", but IMO RFC 8555 talks about Order Objects as being
resources managed by the ACME server.  So, in the RFC 8555 model, I
think we'd be talking about a "request object" here (and later).

  *  MUST NOT contain the "notBefore" and "notAfter" fields;
  *  MUST contain an "auto-renewal" object and inside it, the fields
      listed in Section 3.1.1 of [RFC8739].

(These are already required by RFC 8739 for STAR certificates, and this
list is still scoped to STAR certificates.)

    "protected": base64url({
      "alg": "ES256",
      "kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg",
      "nonce": "5XJ1L3lEkMG7tR6pA00clA",

Do not reuse the nonce from the example in RFC 8555.  (Reusing the kid
is probably tolerable.)  It is core to ACME that the nonce is never
reused, and we should not be sloppy in our examples.

      "auto-renewal": {
        "end-date": "2020-04-20T00:00:00Z",

(nit) almost a year in the past; might be worth updating.

    }),
    "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"

Don't reuse the signature from RFC 8555 either -- that will inherently
change on every POST.

  The Order object that is created on the IdO:

(In contrast to the start of the section, this does seem to be referring
to an RFC 8555-style Order object managed by the ACME server.)

    "status": "ready",
    "expires": "2019-05-01T00:00:00Z",

This date is even older than before; is that even internally consistent?

  The Order is then finalized by the NDC supplying the CSR containing
  the delegated identifiers.  The IdO checks the provided CSR against
  the template that applies to each delegated identifier, as described

How does the "each" come into play -- I thought there was only a single
delegated identifier per CSR (and each delegation could have its own CSR
template)?

  The Order object created by the IdO:

(same as above)

  *  MUST carry a copy of the "auto-renewal" object sent by the NDC and
      augment it with an "allow-certificate-get" attribute set to true.

I think we should reference 8739 for "allow-certificate-get"; we've only
used it so far in the example bodies but not the prose.

Also, I don't think we should have the IdO augmenting the order with
allow-certificate-get; the straightforward interpretation of RFC 8739
suggests that it should only be used when initially requested by the
client.  Can't we require that an NDC client must always set it in the
original request?

  When the validation of the identifiers has been successfully
  completed and the certificate has been issued by the CA, the IdO:

The authorization as well?

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

Copy from the STAR order, to ... where?

      latter indirectly includes (via the NotBefore and NotAfter HTTP

("the latter" also suggests that "to the order resource on the IdO" or
similar is intended here.)

  *  MUST copy the "star-certificate" field from the STAR Order.  The
      latter indirectly includes (via the NotBefore and NotAfter HTTP
      headers) the renewal timers needed by the NDC to inform its
      certificate reload logic.

The relevant HTTP header *fields* are "Cert-Not-Before" and
"Cert-Not-After".

    "status": "valid",
    "expires": "2019-05-01T00:00:00Z",

(old date again)

    "auto-renewal": {
      "end-date": "2020-04-20T00:00:00Z",

(ditto)

Section 2.3.2.1

  If an identifier object of type "dns" was included, the IdO can add
  the corresponding CNAME records to its zone, e.g.:

(nit) I'd suggest a few more words about "corresponding" (it comes from
the delegation object, right?).

Section 2.3.3

    "finalize": "https://acme.ido.example/acme/order/to8RFGO/finalize"

(nit) this appears to differ from the finalize URL from the STAR-case
example only in the case of the order identifier; something more
obviously distinct might be appropriate.

[I won't repeat comments on the text that is common between §2.3.2 and
here.  Thank you for using different nonce and signature values in the
examples.  I wonder if we should use distinct delegation object URLs as
well.]

  *  MUST include the "allow-certificate-get" attribute set to true.

(This is a slightly different wording than in the STAR case, but a
similar sentiment applies about "allow-certificate-get" being sent in
the initial NDC request object.)

Section 2.3.5.2

  revoke the certificate using the associated private key.  However,
  given the trust relationship between NDC and IdO expected by the
  delegation trust model (Section 6.1), as well as the lack of
  incentives for the NDC to prematurely terminate the delegation, this
  does not represent a security risk.

I'd say it does not represent a significant security risk -- there is
slightly broader scope of attack since if the NDC is attacked and the
private key compromised, the cert can be revoked; in a STAR workflow
only the IdO account key could cause the cancellation but in the
non-STAR case there are two keys that could effectuate revocation.

Section 2.4

  An entity implementing the IdO server role - an "ACME Delegation
  server" - can decide, on a per-identity case, whether to act as a
  proxy into another ACME Delegation server, or to behave as an IdO and
  obtain a certificate directly.  The determining factor is whether it

This sentence confuses me somewhat, in that it seems to be portraying a
"bottom-up" decision tree but I expect a "top-down" one.  That is, in my
mental model, the IdO itself is the only entity that can be expected to
pass any of the normal ACME authorization challenges, and so ultimately
it is responsible for obtaining the certificate.  It delegates down to
an NDC, and that NDC can in turn decide whether or not to perform
further delegation.  I don't see how an IdO (as ACME Delegation server)
would be able to decide to proxy up to some other ACME Delegation server
that can't actually obtain a certificate for the delegated name.

Section 3.1

  e.g. by restricting field lengths.  In this regard, note that a
  "subjectAltName" of type "DNS" can be specified using the wildcard
  notation, meaning that the NDC can be required ("**") or offered the
  possibility ("*") to define the delegated domain name by itself.  If
  this is the case, the IdO needs to have a further layer of checks on
  top of the control rules already provided by the CSR template to
  fully validate the CSR input.

(side note) My instincts want a stronger warning here, though I don't
have any specific suggestions at the moment.

    "subject": {
      "country": "CA",
      "stateOrProvince": "**",
      "locality": "**",
      "commonName": "**"

(Same comment as in §2.3.1)

    "extensions": {
      "subjectAltName": {
        "DNS": [
          "client1.ndc.ido.example"

(This doesn't seem like it would actually be suitable for "governing the
delegation exchanges provided in the rest of this document.", since
those use the name abc.ndc.ido.example.)

Section 4.1.2

  *  The namespace that is made available to the dCDN to mint its
      delegated names;

(side note) this phrasing where the dCDN is "mint"ing delegated names
surprises me -- the act of delegation usually does not involve the
delegatee getting to pick what is delegated.

Section 4.2

We should probably mention unauthenticated GET for the order in this
example as well, for consistency.

There's an arrow labeled '7' in Figure 13 but no prose corresponding to
it.

Section 6.1

I think this might be a good place to note that a delegation is
fundamentally associated with an ACME account and cannot be used outside
that account.  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.  (To be clear, I think it is very
important to talk about this *somewhere* though it need not be here.
The brief earlier mention of a delegation being tied to an NDC doesn't
count.)

  contractually defined.  Note that using standard [RFC6125] identity
  verification there are no mechanisms available to the IdO to restrict
  the use of the delegated name once the name has been handed over to
  the first NDC.

I'd suggest reiterating that contractual measures are expected to be
usable to get some assurance that re-delegation is not being performed.

Section 6.3

It seems like it might be useful for Figure 14 to retain the separation
between (IdO) ACME client and (IdO) validation server, even while
retaining a loose IdO grouping.

Section 6.4

  *  The domain owner uses a CAA record [RFC8659] to restrict
      certificate issuance for the domain to specific CAs that comply
      with ACME and are known to implement [RFC8657].

(IIRC, this restriction is only heeded by CAs that actually check CAA,
which is probably required by the CABforum BRs at this point but may not
hold for other PKIs.)

Section 8.1

In my reading, RFCs 8657 and 8659 could be classified as informative,
since we use their technologies only in example scenarios.

Appendix B

[just noting that I didn't do much validation of this schema, e.g.,
cross-checking OIDs]

Some guidance on what corpus to use when picking strings for new
extensions to the schema (e.g., EKU types) might be helpful, though is
hardly required.

Appendix C

  While the CSR template must follow the syntax defined here, neither
  the IdO nor the NDC are expected to validate it at run-time.

It's slightly surprising to see this phrasing, since in the case of
conflict the CDDL schema would take precedence over this one.

[I did not do any validation of the actual schema, though I do note that
this seems to require an RSA key length to be a multiple of 8 bits, and
the CDDL does not.]

[Ballot comment]
Thank you for the work put into this document. The usefulness of this specification is clear and important!

Special thanks for the doc shepherd's write-up as it writes about the WG consensus/discussion.

Please find below some blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
Should "delegated identifier" be more defined ? Honestly, after reading the abstract, I have no clue...

-- Section 1 --
In "This document is a companion document to [RFC8739]" is "companion" the right word? I am not a native English speaker but "companion" sounds like the fates of two documents are bound together, suggest to use "complements" ?

In the abstract CDN is just a use case while, in this introduction section, it is the main goal.

Please expand "NDC" at first use ? Perhaps moving section 1.1 earlier ?

  "We note that other ongoing efforts address the problem of certificate
  delegation for TLS connections, specifically [I-D.ietf-tls-subcerts]
  and [I-D.mglt-lurk-tls13]."
I am trusting the responsible ADs (SEC & TSV) about having 2+ competing IETF standards...

-- Section 2 --
It is a little unclear whether there is one NDC (one per CDN) or multiple NDC (one per edge-cache). The latter could have scalability issues. Section 1.1 seems to indicate the former but it may be ambiguous.

-- Section 2.3.1.2 --
As I am not an expert in CDN, I wonder whether the example entry for 'cname-map' is correct? (I would have used "abc.ido.ndc.example." as the value).

== NITS ==

-- Abstract --
s/This memo defines/This document defines/ AFAIK, the 'memo' wording was used back in the XXth century ;-)

-- Section 1.1 --
s/symmetry/similarity/ ?

[Ballot discuss]
EDIT (06-04-2021): Thank you very much to Carsten Bormann for the CDDL review: https://mailarchive.ietf.org/arch/msg/cbor/23A-PFhRY-pdkg2-Kgcd4jqySVo/ Authors - please make sure to answer Carsten's comments (and keep me in cc so I can clear my DISCUSS).

EDIT (07-04-2021): Also wanted to point out the IANA Designated Expert review to make sure it is addressed (found in the datatracker, but which I report here for simplicity as well) - thank you to Richard Barnes for it:

1. The "delegation" field is currently attached to the "identifier" object, which is a bad semantic fit in a few ways. ACME orders can have multiple identifiers, and delegations can describe multiple SAN values, yet this design assumes singularity on both sides. This field should be moved to the order object; in fact, if you wanted to be more radical, you could even use it to replace the "identifiers" field in the newOrder request.

2. The "allow-certificate-get" field is listed as configurable. It seems like this is a matter of CA policy, so it should either be non-configurable, or if you allow the client to request a value for it, there should be a clear specification that the server is allowed to ignore the client's preference.

[Ballot discuss]
EDIT (06-04-2021): Thank you very much to Carsten Bormann for the CDDL review: https://mailarchive.ietf.org/arch/msg/cbor/23A-PFhRY-pdkg2-Kgcd4jqySVo/ Authors - please make sure to answer Carsten's comments (and keep me in cc so I can clear my DISCUSS).

[Ballot 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.

EDIT TO ADD (06-04-2021): I see that Lars has added a discuss about the same topic - I support that discuss.

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.

[Ballot discuss]
Section 5.1, paragraph 4, discuss:
>    This document requests that IANA create the following new registry
>    under the Automated Certificate Management Environment (ACME)
>    Protocol:
>
>    *  ACME Identifier Object Fields
>
>    This registry is administered under a Specification Required policy
>    [RFC8126].

RFC8126 strongly suggests that guidance needs to be given to expert reviewers
that are supposed to review and approve requests for "Expert Review" and
"Specification Required" registries. This guidance is missing here. What's also
missing are designated contact persons and a change controller.

Section 5.6, paragraph 2, discuss:
> 5.6.  CSR Template Extensions
>
>    IANA is requested to establish a registry "STAR Delegation CSR
>    Template Extensions", with "Expert Review" as its registration
>    procedure.

Same as above.

[Ballot comment]
Section 1, paragraph 8, comment:
>    We note that other ongoing efforts address the problem of certificate
>    delegation for TLS connections, specifically [I-D.ietf-tls-subcerts]
>    and [I-D.mglt-lurk-tls13].  Compared to these other solutions, the
>    current document does not introduce additional latency to the TLS
>    connection, nor does it require changes to the TLS network stack of
>    either the client or the server.

This paragraph should probably be removed upon publication as an RFC?

-------------------------------------------------------------------------------
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Section 3.1, paragraph 10, nit:
-    e.g. by restricting field lengths.  In this regard, note that a
+    e.g., by restricting field lengths.  In this regard, note that a
+        +

Section 4.1, paragraph 3, nit:
-    This section uses specifically CDNI terminology, e.g. "uCDN" and
+    This section uses specifically CDNI terminology, e.g., "uCDN" and
+                                                        +

Section 4.1.2.1, paragraph 5, nit:
-    Unlike HTTP based redirection, where the original URL is supplanted
-              ^
+    Unlike HTTP-based redirection, where the original URL is supplanted
+              ^

[Ballot 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.

[Ballot comment]
[ section 2.1 ]

* I know it's a list of prereqs, but I was wondering if "NDC is required"
  might want to be "NDC is REQUIRED".

Authors: A couple of points for you:

1. The "delegation" field is currently attached to the "identifier" object, which is a bad semantic fit in a few ways.  ACME orders can have multiple identifiers, and delegations can describe multiple SAN values, yet this design assumes singularity on both sides.  This field should be moved to the order object; in fact, if you wanted to be more radical, you could even use it to replace the "identifiers" field in the newOrder request.

2. The "allow-certificate-get" field is listed as configurable.  It seems like this is a matter of CA policy, so it should either be non-configurable, or  if you allow the client to request a value for it, there should be a clear specification that the server is allowed to ignore the client's preference.

(BEGIN IANA COMMENTS)

IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-acme-star-delegation-06. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are six actions which we must complete.

First, a new registry is to be created called the ACME Identifier Object Fields registry. The new registry will be located on the Automated Certificate Management Environment (ACME) Protocol registry page located at:

https://www.iana.org/assignments/acme/

The registration procedure for the new registry will be Specification Required as defined by RFC8126.

There are initial registrations in the new registry as follows:

+============+============+===========================+
| Field Name | Field Type | Reference |
+============+============+===========================+
| type | string | Section 7.1.3 of RFC 8555 |
+------------+------------+---------------------------+
| value | string | Section 7.1.3 of RFC 8555 |
+------------+------------+---------------------------+
| delegation | string | [ RFC-to-be ] |
+------------+------------+---------------------------+

Second, in the ACME Directory Metadata Fields registry also on the Automated Certificate Management Environment (ACME) Protocol registry page located at:

https://www.iana.org/assignments/acme/

a new registration will be made as follows:

Field Name: delegation-enabled
Field Type: boolean
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, in the ACME Order Object Fields registry also on the Automated Certificate Management Environment (ACME) Protocol registry page located at:

https://www.iana.org/assignments/acme/

a new registration will be made as follows:

Field Name: allow-certificate-get
Field Type: boolean
Configurable: true
Reference: [ RFC-to-be ]

As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Fourth, in the ACME Account Object Fields registry also on the Automated Certificate Management Environment (ACME) Protocol registry page located at:

https://www.iana.org/assignments/acme/

a new registration will be made as follows:

Field Name: delegations
Field Type: string
Requests: none
Reference: [ RFC-to-be ]

As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Fifth, in the ACME Error Types registry also on the Automated Certificate Management Environment (ACME) Protocol registry page located at:

https://www.iana.org/assignments/acme/

a new registration will be made as follows:

Type: unknownDelegation
Description: An unknown configuration is listed in the "delegations" attribute of the request Order
Reference: [ RFC-to-be ]

As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Sixth, a new registry is to be created called the STAR Delegation CSR Template Extensions registry.

IANA QUESTION -> Where should this new registry be located? Is it a néw registry on the IANA Matrix or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained?

The registration procedure for the new registry is Expert Review as defined in RFC8126. There are initial registrations in the new registry as follows:

+==================+=============+===============================+
| Extension Name | Extension | Mapping to X.509 Certificate |
| | Syntax | Extension |
+==================+=============+===============================+
| keyUsage | See | [RFC5280], Sec. 4.2.1.3 |
| | Appendix | |
| | C | |
| |[ RFC-to-be ]| |
+------------------+-------------+-------------------------------+
| extendedKeyUsage | See | [RFC5280], Sec. 4.2.1.12 |
| | Appendix | |
| | C | |
| |[ RFC-to-be ]| |
+------------------+-------------+-------------------------------+
| subjectAltName | See | [RFC5280], Sec. 4.2.1.6 (note |
| | Appendix | that only specific name |
| | C | formats are allowed: URI, DNS |
| |[ RFC-to-be ]| name, email address) |
+------------------+-------------+-------------------------------+

IANA QUESTION --> Can you confirm if the "Extension Syntax" field is meant to take the place of the "Reference" field or if the registry should have both?

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

(END IANA COMMENTS)

The following Last Call announcement was sent out (ends 2021-03-22):

From: The IESG
To: IETF-Announce
CC: acme-chairs@ietf.org, acme@ietf.org, draft-ietf-acme-star-delegation@ietf.org, rdd@cert.org, rsalz@akamai.com, ynir.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (An ACME Profile for Generating Delegated STAR Certificates) to Proposed Standard


The IESG has received a request from the Automated Certificate Management
Environment WG (acme) to consider the following document: - 'An ACME Profile
for Generating Delegated STAR Certificates'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-03-22. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This memo proposes a profile of the ACME protocol that allows the
  owner of an identifier (e.g., a domain name) to delegate to a third
  party access to a certificate associated with said identifier.  A
  primary use case is that of a CDN (the third party) terminating TLS
  sessions on behalf of a content provider (the owner of a domain
  name).  The presented mechanism allows the owner of the identifier to
  retain control over the delegation and revoke it at any time by
  cancelling the associated STAR certificate renewal with the ACME CA.
  Another key property of this mechanism is it does not require any
  modification to the deployed TLS ecosystem.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation/



No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard. This is appropriate, since this can be used for Web origins to delegate actions, such as content delivery, to a third party, such as a CDN.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This memo proposes a profile of the ACME protocol that allows the
  owner of an identifier (e.g., a domain name) to delegate to a third
  party access to a certificate associated with said identifier.  A
  primary use case is that of a CDN (the third party) terminating TLS
  sessions on behalf of a content provider (the owner of a domain
  name).  The presented mechanism allows the owner of the identifier to
  retain control over the delegation and revoke it at any time by
  cancelling the associated STAR certificate renewal with the ACME CA.

Working Group Summary:

This was a pretty quiet draft and did not have much email traffic. Most comments were along the lines of "enh, seems fine." There was no controversy. There were several presentations at F2F IETF meetings over the course of development, and I recall nothing more than clarifications or occasional editorial-level suggestions.

Document Quality:

The document is good. There are some nits that can be addressed in IESG review (like copyright year being old, lack of IPv6 examples). It seems quite feasible to implement basic on this document. It should pass any registrar reviews easily. I believe that at least one CDN provider would use this, and there are indications that some commercial CA's would support this, but no commitments.  Note that this is a challenge part of ACME, so use/lack-of-use doesn't invalidate use of ACME overall.

Who is the Document Shepherd? Who is the Responsible Area Director?

Rich Salz (WG co-chair) is the Shepherd and Roman Danyliw is the AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I re-read the document. I looked through IETF meeting slides. I checked the "Nits!" output. I searched the mailing list.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.  It serves a particular  community, and I believe the authors represent a good portion of that community.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.  JSON over HTTPS.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes; there are none.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No,

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

As implied above, the bulk of the WG is "meh, okay"  But ACME is a framework for providing challenges to get certificates, and this meets a particular community need, so the level of WG involvement seems fine to me.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

As mentioned above, copyright year and IP addresses in examples might need some touch-up.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

It adds some entries to various IANA ACME registries.  Should be simple. It adds a column to an existing ACME (RFC 8555) registry.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No,

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

It seems accurate to me.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

In section 5.5:
  IANA is requested to establish a registry "STAR Delegation CSR
  Template Extensions", with "Expert Review" as its registration
  procedure.

This is consistent with the other ACME registraries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

There are none.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard. This is appropriate, since this can be used for Web origins to delegate actions, such as content delivery, to a third party, such as a CDN.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This memo proposes a profile of the ACME protocol that allows the
  owner of an identifier (e.g., a domain name) to delegate to a third
  party access to a certificate associated with said identifier.  A
  primary use case is that of a CDN (the third party) terminating TLS
  sessions on behalf of a content provider (the owner of a domain
  name).  The presented mechanism allows the owner of the identifier to
  retain control over the delegation and revoke it at any time by
  cancelling the associated STAR certificate renewal with the ACME CA.

Working Group Summary:

This was a pretty quiet draft and did not have much email traffic. Most comments were along the lines of "enh, seems fine." There was no controversy. There were several presentations at F2F IETF meetings over the course of development, and I recall nothing more than clarifications or occasional editorial-level suggestions.

Document Quality:

The document is good. There are some nits that can be addressed in IESG review (like copyright year being old, lack of IPv6 examples). It seems quite feasible to implement basic on this document. It should pass any registrar reviews easily. I believe that at least one CDN provider would use this, and there are indications that some commercial CA's would support this, but no commitments.  Note that this is a challenge part of ACME, so use/lack-of-use doesn't invalidate use of ACME overall.

Who is the Document Shepherd? Who is the Responsible Area Director?

Rich Salz (WG co-chair) is the Shepherd and Roman Danyliw is the AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I re-read the document. I looked through IETF meeting slides. I checked the "Nits!" output. I searched the mailing list.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.  It serves a particular  community, and I believe the authors represent a good portion of that community.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.  JSON over HTTPS.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes; there are none.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No,

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

As implied above, the bulk of the WG is "meh, okay"  But ACME is a framework for providing challenges to get certificates, and this meets a particular community need, so the level of WG involvement seems fine to me.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

As mentioned above, copyright year and IP addresses in examples might need some touch-up.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

It adds some entries to various IANA ACME registries.  Should be simple. It adds a column to an existing ACME (RFC 8555) registry.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No,

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

It seems accurate to me.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

In section 5.5:
  IANA is requested to establish a registry "STAR Delegation CSR
  Template Extensions", with "Expert Review" as its registration
  procedure.

This is consistent with the other ACME registraries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

There are none.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.