Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)

["Owen Friel (ofriel)" <[e-mail]>]

FYI, https://tools.ietf.org/html/draft-friel-acme-subdomains-01 documents the proposed new authorization object field "basedomain"


> -----Original Message-----
> From: Acme <[e-mail]> On Behalf Of Owen Friel (ofriel)
> Sent: 06 December 2019 15:41
> To: Salz, Rich <[e-mail]>; [e-mail]
> Subject: [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 <[e-mail]> On Behalf Of Owen Friel (ofriel)
> > Sent: 26 November 2019 22:51
> > To: Salz, Rich <[e-mail]>; [e-mail]
> > 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 <[e-mail]> On Behalf Of Salz, Rich
> > > Sent: 26 November 2019 21:53
> > > To: [e-mail]
> > > 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:[e-mail]>
> > > Date: Tuesday, November 26, 2019 at 4:51 PM
> > > To: "mailto:[e-mail]" <mailto:[e-mail]>
> > > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/acme
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme