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

[Benjamin Kaduk <[e-mail]>]

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" <[e-mail]> 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