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 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
