> On Jan 21, 2020, at 8:04 AM, Ryan Sleevi <ryan-i...@sleevi.com> 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? 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
