At 13:04 21/01/2020 Tuesday, Ryan Sleevi wrote:
>On Tue, Jan 21, 2020 at 7:14 AM Owen Friel (ofriel) ><<mailto:ofr...@cisco.com>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