Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-friel-acme-subdomains)
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 On Behalf Of Owen Friel (ofriel) Sent: 29 January 2020 05:51 To: Felipe Gasper Cc: IETF ACME Subject: Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains) > -Original Message- > From: Felipe Gasper > Sent: 21 January 2020 14:01 > To: Owen Friel (ofriel) > Cc: IETF ACME > 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) wrote: > > > >> > >> Will this document eventually also describe subdomain authz via the > >> standard ACME workflow? > >> > >> > > > > [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
[Acme] The session in Vancouver - Looking for a volunteer
Hi As it turns out, both Rich and I will not be able to attend IETF 107 due to company and government (in my case) restrictions on travel. For now we hope not to cancel the ACME session. Since neither of us is going to be on-site, we are looking for a volunteer to sling the slides, send around the blue sheets and operate the Big Red Button, which should see considerably more use this time. So if you are: (1) still planning to attend, and (2) allowed to do so by your employer, your government, Canada’s government, and your significant others, and (3) willing to sit up front and run the meeting, please send a message to Rich and me. We will still prepare the slides and will, if possible, even present them from home, but we really need someone to sit up front. Thanks in advance. Rich & Yoav. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
