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
