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

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

> -----Original Message-----
> From: Acme <[e-mail]> On Behalf Of Felipe Gasper
> Sent: 20 January 2020 12:32
> To: IETF ACME <[e-mail]>
> Subject: Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call
> for adoption draft-frield-acme-subdomains)
> 
> Will this document eventually also describe subdomain authz via the standard
> ACME workflow?
> 
> Examples:
> 
> 1) Client wants a certificate for example.com & www.example.com. Ideally, if
> the client authzs example.com, then authz for www.example.com shouldn’t be
> necessary.
> 
> 2) Now client also wants a separate certificate for sub.example.com and
> www.sub.example.com. Since example.com was already authorized, this
> certificate order should not require any additional authz.
> 
> It seems like the above workflow should “just work”, but since it’s closely
> related to what your document describes I wonder if there’s benefit to
> mentioning it?
> 

[ofriel] That’s the exact workflow that the document is attempting to describe, so maybe it needs to be clarified.
The example section https://tools.ietf.org/html/draft-friel-acme-subdomains-01#section-4.2 (and I realise now looking at it that I messed up the numbered steps - they are all '1') outlines a client authorizing for "example.com" and getting certs for "sub0.example.com", "sub1.example.com" and "sub2.example.com". If its not clear, I can try reword in an update.

> Also, the linked document states:
> 
>    The call flow illustrates the DNS-based proof of ownership mechanism,
>    but the subdomain workflow is equally valid for HTTP based proof of
>    ownership.
> 
> Can’t I have HTTP access to a base domain’s website without having access to a
> subdomain’s, though? I thought that was the reason why ACME limits wildcard
> authz to DNS.

[ofriel] Daniel has clarified this already. Its a Lets Encrypt, not an ACME limitation.

> 
> 
> cheers,
> -Felipe Gasper
> 
> 
> > On Jan 20, 2020, at 6:48 AM, Owen Friel (ofriel) <[e-mail]> wrote:
> >
> > 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
> > _______________________________________________
> > Acme mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/acme
> 
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme