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
