[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-bounces@ietf.org> On Behalf Of Owen Friel (ofriel)
> Sent: 26 November 2019 22:51
> To: Salz, Rich <rsalz@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-bounces@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:rsalz@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