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
