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
