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? 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. cheers, -Felipe Gasper > On Jan 20, 2020, at 6:48 AM, Owen Friel (ofriel) <ofr...@cisco.com> wrote: > > FYI, https://tools.ietf.org/html/draft-friel-acme-subdomains-01 documents the > proposed new authorization object field "basedomain" > > >> -----Original Message----- >> From: Acme <acme-boun...@ietf.org> On Behalf Of Owen Friel (ofriel) >> Sent: 06 December 2019 15:41 >> To: Salz, Rich <rs...@akamai.com>; acme@ietf.org >> 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 <acme-boun...@ietf.org> On Behalf Of Owen Friel (ofriel) >>> Sent: 26 November 2019 22:51 >>> To: Salz, Rich <rs...@akamai.com>; acme@ietf.org >>> 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 <acme-boun...@ietf.org> On Behalf Of Salz, Rich >>>> Sent: 26 November 2019 21:53 >>>> To: acme@ietf.org >>>> 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:rs...@akamai.com> >>>> Date: Tuesday, November 26, 2019 at 4:51 PM >>>> To: "mailto:acme@ietf.org"; <mailto:acme@ietf.org> >>>> 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 >>> Acme@ietf.org >>> https://www.ietf.org/mailman/listinfo/acme >> _______________________________________________ >> 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 mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
