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 protected]> 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. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
