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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 9 Jun 2021 15:59:06 -0700

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

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

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 11 Jun 2021 08:54:17 +0000

Hi Ben,

Thank you again for your comments; Yaron has just pushed -09 which
should address most of them -- see below for the detail.

(I am merging this together with your Ballot email to have all the
discussion in one place.)

On 10/06/2021, 08:00, "Benjamin Kaduk" <[email-masked]> wrote:
> 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.

We changed "decide" to "might behave" as you suggest.

On 09/06/2021, 23:59, "Benjamin Kaduk via Datatracker" <[email-masked]> wrote:
> Section 2.3.1.3
>
>    In order to indicate which specific delegation applies to the
>    requested certificate a new "delegation" attribute is added to the
>    Order object on the NDC-IdO side (see Figure 4).  The value of this
>
> We might want to get the phrase "request object" in here somehow, since
> we go on to talk about returning an error response, which is of course
> only possible if there is a corresponding request.  (The next section
> does talk about the "request object created by the NDC").

Done.

> Section 2.3.2
>
>    If the delegation is for a STAR certificate, the request object
>    created by the NDC:
>    [...]
>    *  MUST have entries in the "identifiers" field for each delegated
>       name present in the configuration;
>
> Just to confirm: this is saying that the request/order must request a
> certificate for all names covered by the delegation; it cannot request
> only a subset of the names in the particular delegation object?  On
> first read this seems a bit restrictive, but I suppose it can make
> state handling at the IdO easier since the information from the
> delegation object can be used to construct the request to the actual
> CA.  (Similarly for the non-STAR case in §2.3.3, of course.)

Yes.

> The example delegation URL in Figure 4 doesn't match the URL structure
> used for the example delegation list in Section 2.3.1.2.  (This is not
> inherently problematic, but could cause a small amount of reader
> confusion.)  The same identifier occurs in several subsequent figures,
> as well.

Done - with a cameo :-)

> Section 3
>
>    Although most of this document, and in particular Section 2 is
>    focused on the protocol between the NDC and to IdO, the protocol does
>    affect the ACME server running in the CA.  A CA that wishes to
>    support certificate delegation MUST also support unauthenticated
>
> Is it correct to say "non-STAR certificate delegation" here?  (The
> corresponding change needed to support STAR delegation would have been
> done already to support non-delegated STAR issuance, if I understand
> correctly.)

I don't think the observation is correct: STAR issuance does not require
the server to support unauthenticated GET.  It is a feature that the
client needs to request explicitly, and the server could refuse if it
does not implement it -- or for any other reason.  (See Section 3.4 of
RFC8739.)

Or have I misinterpreted your thought?

> Section 7.2
>
>    The ACME account [...]
>
> Please double-check and confirm that the singular 'policy' and
> '"delegation" object" are as intended here.  IIRC we do allow multiple
> delegation objects to be associated with a single account.

Done, thanks for spotting this!

cheers, t

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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 11 Jun 2021 09:58:34 -0700

Hi Thomas,

Trimming to just the one part that needs a response other than "thanks"...

> Or have I misinterpreted your thought?

My thinking was something along the lines of "the new protocol mechanisms
in this document don't affect the CA operation for the STAR issuance case,
since the CA protocol mechanisms for the STAR case are specified in RFC
8739".  But you are also correct to say that in order to use the mechanisms
in this document the CA has to do/implement something that 8739 did not
require of it.  Since this text is not clearly about "new protocol
mechanisms" vs "actually using the protocol", I think you are correct and
we should leave the text as-is.

Thanks again for all the updates and explanations!

-Ben