> -----Original Message----- > From: Felipe Gasper <[email protected]> > Sent: 21 January 2020 14:01 > To: Owen Friel (ofriel) <[email protected]> > Cc: IETF ACME <[email protected]> > Subject: Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call > for adoption draft-frield-acme-subdomains) > > > > On Jan 21, 2020, at 7:13 AM, Owen Friel (ofriel) <[email protected]> wrote: > > > >> > >> Will this document eventually also describe subdomain authz via the > >> standard ACME workflow? > >> > >> <snip> > > > > [ofriel] That’s the exact workflow that the document is attempting to > describe, so maybe it needs to be clarified. > > The example section https://tools.ietf.org/html/draft-friel-acme-subdomains- > 01#section-4.2 (and I realise now looking at it that I messed up the numbered > steps - they are all '1') outlines a client authorizing for "example.com" and > getting certs for "sub0.example.com", "sub1.example.com" and > "sub2.example.com". If its not clear, I can try reword in an update. > > Your document seems to confine itself to the pre-authorization workflow, > though (as per section 4’s 2nd paragraph, anyhow); I’m thinking applicability > to > 8555’s default/standard/order-then-authz workflow.
[ofriel] Confining to pre-authorization certainly isn’t the intention, and I can clarify this. https://tools.ietf.org/html/draft-friel-acme-subdomains-01#section-4.1 states: " If a server has such a policy and a client is not authorized for the parent domain then: ... o If the client submits a newOrder request for a subdomain: The server MUST return a status 201 (Created) response. The response body is an order object with status set to "pending" and links to newly created authorizations objects against the parent domain." So some of the text explicitly allows this. I will refactor. > > -FG _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
