I just published draft-02 https://www.ietf.org/id/draft-friel-acme-subdomains-02.txt which hopefully addresses the pre-authorization and policy discussions below.
-----Original Message----- From: Acme <acme-boun...@ietf.org> On Behalf Of Owen Friel (ofriel) Sent: 29 January 2020 05:51 To: Felipe Gasper <fel...@felipegasper.com> Cc: IETF ACME <acme@ietf.org> Subject: Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains) > -----Original Message----- > From: Felipe Gasper <fel...@felipegasper.com> > Sent: 21 January 2020 14:01 > To: Owen Friel (ofriel) <ofr...@cisco.com> > Cc: IETF ACME <acme@ietf.org> > 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) <ofr...@cisco.com> 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 Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
