Subject: Re: [Acme] Call for adoption draft-frield-acme-subdomains

From: "Salz, Rich" <[email-masked]>
Date: Tue, 26 Nov 2019 21:52:50 +0000

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 <[email-masked]>
Date: Tuesday, November 26, 2019 at 4:51 PM
To: "[email-masked]" <[email-masked]>
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.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 26 Nov 2019 22:50:45 +0000

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-masked]> On Behalf Of Salz, Rich
> Sent: 26 November 2019 21:53
> To: [email-masked]
> 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-masked]>
> To: "mailto:[email-masked]" <mailto:[email-masked]>
> 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.