[Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-star-delegation-07: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-acme-star-delegation-07: Discuss

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/



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


----------------------------------------------------------------------
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.]