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

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Mon, 20 Jan 2020 11:48:42 +0000

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

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

---

From: Felipe Gasper <[email-masked]>
Date: Mon, 20 Jan 2020 07:31:50 -0500

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?

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.

cheers,
-Felipe Gasper

> On Jan 20, 2020, at 6:48 AM, Owen Friel (ofriel) <[email-masked]> wrote:
>

---

From: Daniel McCarney <[email-masked]>
Date: Mon, 20 Jan 2020 10:44:58 -0500

>
>  I thought that was the reason why ACME limits wildcard authz to DNS.

I don't think RFC 8555 imposes any restrictions on what challenge types can
be used for wildcard identifiers. Limiting wildcard DNS identifiers to the
DNS-01 challenge is a policy decision by Let's Encrypt.

On Mon, Jan 20, 2020 at 7:32 AM Felipe Gasper <[email-masked]>
wrote:

> 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?
>
> 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.
>
>
> cheers,
> -Felipe Gasper
>
>
> > FYI, https://tools.ietf.org/html/draft-friel-acme-subdomains-01
> documents the proposed new authorization object field "basedomain"
> >
> >

---

From: Felipe Gasper <[email-masked]>
Date: Mon, 20 Jan 2020 10:48:28 -0500

> On Jan 20, 2020, at 10:44 AM, Daniel McCarney <[email-masked]> wrote:
> 
> I don't think RFC 8555 imposes any restrictions on what challenge types can be used for wildcard identifiers. Limiting wildcard DNS identifiers to the DNS-01 challenge is a policy decision by Let's Encrypt.

You’re right; I was misreading it. Sorry for the confusion.

-F

> 
> On Mon, Jan 20, 2020 at 7:32 AM Felipe Gasper <[email-masked]> wrote:

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 21 Jan 2020 12:13:42 +0000

> From: Acme <[email-masked]> On Behalf Of Felipe Gasper
> Sent: 20 January 2020 12:32
> To: IETF ACME <[email-masked]>
> Subject: Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call
> for adoption draft-frield-acme-subdomains)
> 
> 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.
> 
> 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.

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

> > FYI, https://tools.ietf.org/html/draft-friel-acme-subdomains-01 documents
> the proposed new authorization object field "basedomain"
> >
> >
> >> 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.
> >>
> >>
> >>> For the subdomains use case, it looks as if it makes sense to define
> >>> a "parentdomain" boolean flag (or "basedomainname" or similar) to be
> >>> 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
> >>>> If you disagree with that, or have any other strong feelings,
> >>>> please post to the list before the end of next week.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 21 Jan 2020 08:04:11 -0500

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

Although the CA/Browser Forum / Browser Stores have repeatedly discussed
forbidding it. That is, allowing the HTTP and TLS methods of validation to
only be scoped for the host in question (and potentially the service in
question, if we can work out the safe SRVName transition, due to the
interaction of nameConstraints and policy)

Would it be simpler to remove the statement from the draft, rather than try
to clarify equally valid refers to the technology without commenting on the
policy?

---

From: Felipe Gasper <[email-masked]>
Date: Tue, 21 Jan 2020 09:00:48 -0500

> On Jan 21, 2020, at 7:13 AM, Owen Friel (ofriel) <[email-masked]> wrote:
> 
>> 
>> <snip>

Your document seems to confine itself to the pre-authorization workflow, though (as per section 4’s 2nd paragraph, anyhow); I’m thinking applicability to 8555’s default/standard/order-then-authz workflow.

-FG

---

From: Felipe Gasper <[email-masked]>
Date: Tue, 21 Jan 2020 09:14:46 -0500

> On Jan 21, 2020, at 8:04 AM, Ryan Sleevi <[email-masked]> wrote:
> 
> On Tue, Jan 21, 2020 at 7:14 AM Owen Friel (ofriel) <[email-masked]> wrote:
> Although the CA/Browser Forum / Browser Stores have repeatedly discussed forbidding it. That is, allowing the HTTP and TLS methods of validation to only be scoped for the host in question (and potentially the service in question, if we can work out the safe SRVName transition, due to the interaction of nameConstraints and policy)
> 
> Would it be simpler to remove the statement from the draft, rather than try to clarify equally valid refers to the technology without commenting on the policy?

For what my opinion is worth, that seems reasonable--though perhaps the best might be to defer explicitly to the CA/B guidelines, e.g., “whatever validation methods CA/B allows for subdomains/wildcards, this also allows.”

-F

---

From: Alan Doherty <[email-masked]>
Date: Tue, 21 Jan 2020 16:59:42 +0000

At 13:04 21/01/2020  Tuesday, Ryan Sleevi wrote:

>On Tue, Jan 21, 2020 at 7:14 AM Owen Friel (ofriel) <<mailto:[email-masked]>[email-masked]> wrote:
>>Â  Â  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? 

err yes you can (easily)
I as a website provider, have access to the http base domains of many customers (how we obtain/refresh the SAN certs that keep their websites available) I do not (and do not want/need access to create wildcard certs for their other sites elsewhere)
and customers do not assume their web host provider needs a lot of trust

I (separate hat) as a dns provider (separate set of customers some overlap) can access their basedomain to create wildcards, but as i could also repoint their other sites elsewhere (here for long enough to http authenticate them too, or to a reverse proxy to mitm them etc) this risk is omnipresent (why you should ensure your dns hoster is above reproach and has a small staff, here its 2 ppl with access to the dns servers)
and why dns hoster is usually seriously considered as largest risk in terms of Internet vulnerability

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 28 Jan 2020 21:50:30 +0000

> From: Felipe Gasper <[email-masked]>
> Sent: 21 January 2020 14:01
> To: Owen Friel (ofriel) <[email-masked]>
> Cc: IETF ACME <[email-masked]>
> > [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.
> 
> Your document seems to confine itself to the pre-authorization workflow,
> though (as per section 4’s 2nd paragraph, anyhow); I’m thinking applicability to
> 8555’s default/standard/order-then-authz workflow.

[ofriel] Confining to pre-authorization certainly isn’t the intention, and I can clarify this.

https://tools.ietf.org/html/draft-friel-acme-subdomains-01#section-4.1 states:

" If a server has such a policy and a client is not authorized for the
   parent domain then:
...
   o  If the client submits a newOrder request for a subdomain: The
      server MUST return a status 201 (Created) response.  The response
      body is an order object with status set to "pending" and links to
      newly created authorizations objects against the parent domain." 

So some of the text explicitly allows this. I will refactor.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 28 Jan 2020 21:50:36 +0000

> Sent: 21 January 2020 14:15
> To: Ryan Sleevi <[email-masked]>
> Cc: Owen Friel (ofriel) <[email-masked]>; IETF ACME <[email-masked]>
> > > 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.
> >
> > Although the CA/Browser Forum / Browser Stores have repeatedly
> > discussed forbidding it. That is, allowing the HTTP and TLS methods of
> > validation to only be scoped for the host in question (and potentially
> > the service in question, if we can work out the safe SRVName
> > transition, due to the interaction of nameConstraints and policy)
> >
> > Would it be simpler to remove the statement from the draft, rather than try to
> clarify equally valid refers to the technology without commenting on the policy?
> 
> For what my opinion is worth, that seems reasonable--though perhaps the best
> might be to defer explicitly to the CA/B guidelines, e.g., “whatever validation
> methods CA/B allows for subdomains/wildcards, this also allows.”

[ofriel] this suggestion makes sense. I will clarify what RFC8555 allows, and then refer to CA/B guidelines too. This could be for a private CA, or an IoT root CA (as per the long thread on lamps), so CA/B may not even be applicable depending on the use case.