> -----Original Message----- > From: Acme <[email protected]> On Behalf Of Felipe Gasper > Sent: 20 January 2020 12:32 > To: IETF ACME <[email protected]> > Subject: Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call > for adoption draft-frield-acme-subdomains) > > Will this document eventually also describe subdomain authz via the standard > ACME workflow? > > Examples: > > 1) Client wants a certificate for example.com & www.example.com. Ideally, if > the client authzs example.com, then authz for www.example.com shouldn’t be > necessary. > > 2) Now client also wants a separate certificate for sub.example.com and > www.sub.example.com. Since example.com was already authorized, this > certificate order should not require any additional authz. > > It seems like the above workflow should “just work”, but since it’s closely > related to what your document describes I wonder if there’s benefit to > mentioning it? >
[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. > Also, the linked document states: > > The call flow illustrates the DNS-based proof of ownership mechanism, > but the subdomain workflow is equally valid for HTTP based proof of > ownership. > > Can’t I have HTTP access to a base domain’s website without having access to a > subdomain’s, though? I thought that was the reason why ACME limits wildcard > authz to DNS. [ofriel] Daniel has clarified this already. Its a Lets Encrypt, not an ACME limitation. > > > cheers, > -Felipe Gasper > > > > On Jan 20, 2020, at 6:48 AM, Owen Friel (ofriel) <[email protected]> wrote: > > > > FYI, https://tools.ietf.org/html/draft-friel-acme-subdomains-01 documents > the proposed new authorization object field "basedomain" > > > > > >> -----Original Message----- > >> From: Acme <[email protected]> On Behalf Of Owen Friel (ofriel) > >> Sent: 06 December 2019 15:41 > >> To: Salz, Rich <[email protected]>; [email protected] > >> Subject: [Acme] ACME wildcards vs. subdomain authorizations (was RE: > >> Call for adoption draft-frield-acme-subdomains) > >> > >> Any comments on this email on how to explicitly distinguish between > >> wildcard and subdomain authorizations, which hopefully addresses ekr's mic > comments. > >> > >> > >>> -----Original Message----- > >>> From: Acme <[email protected]> On Behalf Of Owen Friel (ofriel) > >>> Sent: 26 November 2019 22:51 > >>> To: Salz, Rich <[email protected]>; [email protected] > >>> Subject: Re: [Acme] Call for adoption draft-frield-acme-subdomains > >>> > >>> DNS wildcards are mentioned in 3 sections in RFC8555 (in addition to > >>> the IANA Considerations section): > >>> > >>> 1. https://tools.ietf.org/html/rfc8555#section-7.1.3 Order Objects: > >>> > >>> Any identifier of type "dns" in a newOrder request MAY have a > >>> wildcard domain name as its value. A wildcard domain name consists > >>> of a single asterisk character followed by a single full stop > >>> character ("*.") followed by a domain name as defined for use in the > >>> Subject Alternate Name Extension by [RFC5280]. An authorization > >>> returned by the server for a wildcard domain name identifier MUST NOT > >>> include the asterisk and full stop ("*.") prefix in the authorization > >>> identifier value. The returned authorization MUST include the > >>> optional "wildcard" field, with a value of true. > >>> > >>> 2. https://tools.ietf.org/html/rfc8555#section-7.1.4 Authorization > >>> Objects: > >>> > >>> If an > >>> authorization object conveys authorization for the base domain of a > >>> newOrder DNS identifier containing a wildcard domain name, then the > >>> optional authorizations "wildcard" field MUST be present with a value > >>> of true. > >>> > >>> 3. https://tools.ietf.org/html/rfc8555#section-7.4.1 > >>> Pre-authorization > >>> > >>> Note that because the identifier in a pre-authorization request is > >>> the exact identifier to be included in the authorization object, pre- > >>> authorization cannot be used to authorize issuance of certificates > >>> containing wildcard domain names. > >>> > >>> For the subdomains use case, it looks as if it makes sense to define > >>> a "parentdomain" boolean flag (or "basedomainname" or similar) to be > >>> included in the authorization object for a domain that authorizes > >>> subdomain certs. The relevant CAB guidelines are quoted in > >>> https://tools.ietf.org/html/draft-friel- > >>> acme-subdomains-00#appendix-A. > >>> > >>> The authorization object would then explicitly indicate that this is > >>> a base domain authorization and thus subdomain certs may be issued > >>> off this. This is conceptually similar to the current "wildcard" > >>> flag which indicates that a wildcard cert may be issued off the > >>> identifier in the object, and would definitively differentiate > >>> wildcard vs. base domain vs. explicit domain authorizations. > >>> > >>> Item #3 from section 7.4.1 Pre-authorization is already called out > >>> as a substantive change from RFC8555: i.e. the identifier in the > >>> authorization object may be different from the identifier in the > >>> newAuthz > >> object. > >>> > >>>> -----Original Message----- > >>>> From: Acme <[email protected]> On Behalf Of Salz, Rich > >>>> Sent: 26 November 2019 21:53 > >>>> To: [email protected] > >>>> Subject: Re: [Acme] Call for adoption draft-frield-acme-subdomains > >>>> > >>>> WRONG. My mistake. > >>>> > >>>> Please discuss this, especially the subdomains/wildcard issues. > >>>> This is *NOT* a call for adoption. We will take this up in > >>>> Vancouver, IETF > >> 107. > >>>> > >>>> From: Rich Salz <mailto:[email protected]> > >>>> Date: Tuesday, November 26, 2019 at 4:51 PM > >>>> To: "mailto:[email protected]"; <mailto:[email protected]> > >>>> Subject: [Acme] Call for adoption draft-frield-acme-subdomains > >>>> > >>>> This email starts a ten-day call for adoption. There was consensus > >>>> in the room at IETF 106 to adopt this as a working group document. > >>>> If you disagree with that, or have any other strong feelings, > >>>> please post to the list before the end of next week. > >>>> Also discussed was the need for some additional clarity around > >>>> subdomains and the existing wildcard challenges. > >>>> > >>>> Thank you. > >>>> > >>> _______________________________________________ > >>> Acme mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/acme > >> _______________________________________________ > >> Acme mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/acme > > _______________________________________________ > > Acme mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/acme > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
