> -----Original Message----- > From: Felipe Gasper <[email protected]> > Sent: 21 January 2020 14:15 > To: Ryan Sleevi <[email protected]> > Cc: Owen Friel (ofriel) <[email protected]>; IETF ACME <[email protected]> > Subject: Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call > for adoption draft-frield-acme-subdomains) > > > > On Jan 21, 2020, at 8:04 AM, Ryan Sleevi <[email protected]> wrote: > > > > On Tue, Jan 21, 2020 at 7:14 AM Owen Friel (ofriel) <[email protected]> > > 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.”
[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. > > -F _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
