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

[Alan Doherty]

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


>On Tue, Jan 21, 2020 at 7:14 AM Owen Friel (ofriel) 
><ofr...@cisco.com> wrote:
>> 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? 

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



>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.
>
>
>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?
>
>___
>Acme mailing list
>Acme@ietf.org
>https://www.ietf.org/mailman/listinfo/acme

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Felipe Gasper]

> On Jan 21, 2020, at 8:04 AM, Ryan Sleevi  wrote:
> 
> On Tue, Jan 21, 2020 at 7:14 AM Owen Friel (ofriel)  wrote:
> > 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.
> 
> 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
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Felipe Gasper]

> On Jan 21, 2020, at 7:13 AM, Owen Friel (ofriel)  wrote:
> 
>> 
>> Will this document eventually also describe subdomain authz via the standard
>> ACME workflow?
>> 
>> 
> 
> [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.

-FG
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Ryan Sleevi]

On Tue, Jan 21, 2020 at 7:14 AM Owen Friel (ofriel) 
wrote:

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


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?

>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Owen Friel (ofriel)]

> -Original Message-
> From: Acme  On Behalf Of Felipe Gasper
> Sent: 20 January 2020 12:32
> To: IETF ACME 
> 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)  wrote:
> >
> > FYI, https://tools.ietf.org/html/draft-friel-acme-subdomains-01 documents
> the proposed new authorization object field "basedomain"
> >
> >
> >> -Original Message-
> >> From: Acme  On Behalf Of Owen Friel (ofriel)
> >> Sent: 06 December 2019 15:41
> >> To: Salz, Rich ; acme@ietf.org
> >> 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  On Behalf Of Owen Friel (ofriel)
> >>> Sent: 26 November 2019 22:51
> >>> To: Salz, Rich ; acme@ietf.org
> >>> 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"
> >>>