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

From: Thomas Fossati <[email-masked]>
Date: Mon, 10 May 2021 18:05:37 +0000

Hi Ben,

Thanks a lot for your in-depth review.

We think we have addressed all your comments, but please check [1] and
its attached PRs for confirmation.

The only points we didn't address are listed below, along with the
reasons why we decided to avoid changing the existing text.

On 08/04/2021, 05:47, "Benjamin Kaduk via Datatracker" <[email-masked]> wrote:
> Section 2.3.2
> [...]
>
>    *  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.)

True, but the NDC is not the same ACME client as the one specified in
8739 so it seems worth being explicit.

> Section 2.3.3
> [...]
>
> [...] I wonder if we should use distinct delegation object URLs as
> well.

This was deliberate: we decided to keep the same delegation order to
show that the choice of STAR vs non-STAR is orthogonal with respect to
the rest of the delegation configuration - it's basically the choice of
the NDC.

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

I think what we wanted to say - Yaron please correct me - is that one
entity can mediate different delegation paths at the same time and that
for each of these paths it can play an IdO role, an NDC role, or a proxy
role.

For example, suppose the following:
* A is an IdO holding the name "a.com"
* B is an IdO holding the name "b.com"
* B is also an NDC with A (e.g., it uses "a.com" to serve A's content)
* C is an NDC with B for both "a.com" and "b.com"

Then:
* If C requests a cert for "a.com", B will act as a proxy forwarding the
  request to A (the one that can complete the authorisation challenges
  for "a.com"), and A will ask the ACME server
* If C requests a cert for "b.com", B (i.e., the one that can complete
  the authorisation challenges for "b.com") will act as a IdO, and ask
  the ACME server directly

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

The existing corpus is a typographic mess, so trying to impose upfront
consistency may be an impossible task.  I'd leave the fun of exercising
typographical taste to the expert :-)

cheers!

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.