Hi Thomas, Yaron, My apologies for having missed this until now, and for not having commented on the github versions of things.
The changes in the -08 are generally quite good (thank you!), though I will re-ballot shortly with a few comments on them (but no discuss). A few final thoughts inline... On Mon, May 10, 2021 at 06:05:37PM +0000, Thomas Fossati wrote: > 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. In my reading, the NDC/IdO ACME exchange is still a STAR exchange (albeit slightly modified), separate from the IdO/CA STAR exchange. In that sense the restrictions from 8739 would continue to apply, but I can see how it makes sense to you to reiterate the point ehre. > > 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. Okay; thanks for confirming that it was an intentional decision. > > 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 I think we are in agreement on the behavior of B in the respective cases, and thank you for writing them out clearly to anchor the discussion. I suspect that I'm just bothered by the word "decide" -- to me it implies a choice among several possibilities, but most of the time there is only one possibility that will actually work, and thus not a real choice. (What with failure not being an option, and all ;) If we instead used language along the lines of "might behave" for each case, I don't think it would seem problematic to me. > > 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 :-) That is eminently plausible, and a quite understandable conclusion :) Thanks again, Ben _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
