Thanks for bringing it to the list, Owen. This is something we're trying to lock down in the CA/B Forum, at least with respect to the 'http-01' method, by making it clear that, like tls-alpn-01, it cannot be used as an Authorization Domain Name (i.e. a domain and all of its descendents), only as an FQDN.
So this method primarily is for the 'dns-01' method, which seems to suggest that, at a minimum, the ACME server needs to indicate to the ACME client what modifications it will accept, since the ACME client will need to actually modify the DNS record at the appropriate label. If the server only chooses a single label, then it seems both likely and possible that the server may choose a dns-01 challenge that the client cannot fulfill (e.g. the client can only modify subdomain.example.com and descendents, but the server/CA chooses to challenge against example.com) So I *think* it would benefit from having the server be able to issue challenges against several identifiers, and communicate that to the client, which seems to argue "Yes" for your question #2. Equally in this scenario, I think you're asking whether or not the client should be able to indicate its capabilities to the ACME server, for selecting appropriate challenges. If a client is using dns-01 and can only modify subdomain.example.com, it doesn't benefit the client at all if the server chooses to also allow example.com. The question is whether there's a security risk in doing so; that is, should the client be able to affirmatively restrict the server or does it not matter. Does that accurately capture things? On Fri, Dec 4, 2020 at 10:25 AM Owen Friel (ofriel) <ofriel= 40cisco....@dmarc.ietf.org> wrote: > That is what is currently documented – the server simply picks the one > domain that it wants the client to fulfil the challenge against. > > > > That was presented as the current documented approach. And I also > presented the open questions if we needed to build flexibility in client > request and/or server response. There were no concrete opinions as far as I > recall (waiting on the exact minutes) and Rich said to bring the qs to the > mailer for further discussion. > > > > Cheers, > > Owen > > > > > > *From:* Acme <acme-boun...@ietf.org> *On Behalf Of *Felipe Gasper > *Sent:* 04 December 2020 21:35 > *To:* Owen Friel (ofriel) <ofriel=40cisco....@dmarc.ietf.org> > *Cc:* acme@ietf.org > *Subject:* Re: [Acme] acme subdomains open items > > > > I wasn’t part of IETF 109 .. was it discussed simply to give CAs the > ability to choose whether it tries authz against parent domains without the > client’s requesting it? > > > > This is how our (non-ACME) Sectigo integration works currently, and it > suits us well. > > > > -F > > > > On Dec 4, 2020, at 02:23, Owen Friel (ofriel) < > ofriel=40cisco....@dmarc.ietf.org> wrote: > > > > Hi all, > > > > As recommended by the chairs at IETF109, bring the two open items to the > list for discussion. These were raised by Felipe and Ryan previously. > > > > 1: Does the client need a mechanism to indicate that they want to > authorize a parent domain and not the explicit subdomain identifier? Or a > mechanism to indicate that they are happy to authorize against a choice of > identifiers? > > > > E.g. for foo1.foo2.bar.example.com, should the client be able to specify > anywhere from 1 to 4 identifiers they are willing to fulfil challenges for? > > > > 2: Does the server need a mechanism to provide a choice of identifiers to > the client and let the client chose which challenge to fulfil? > > > > E.g. for foo1.foo2.bar.example.com, should the server be able to specify > anywhere from 1 to 4 identifiers that the client can pick from to fulfil? > > > > Both 1 and 2 require JSON object definition changes. Currently, the > document only defines how a client can submit a newOrder / newAuthz for a > subdomain, and the server can chose any one parent identifier that it > requires a challenge fulfilment on > > > > Owen > > > > > https://datatracker.ietf.org/meeting/109/materials/slides-109-acme-subdomains-01 > > > > https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-4 > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
