On Thu, Dec 17, 2015 at 11:19 AM, Andrew Ayer <[email protected]> wrote:
> On Thu, 17 Dec 2015 02:23:20 -0500 > Eric Mill <[email protected]> wrote: > > > I think that ACME should revisit the DNS specification and avoid > > using a prefix for the TXT validation, to enable this use case. > > I disagree, because of a major restriction that DNS places on CNAMEs: > CNAMEs cannot coexist with other record types. If ACME didn't use > prefixes, and you CNAME'd blog.ericmill.com over to Tumblr, you would > lose the ability to yourself complete a DNS challenge for > blog.ericmill.com, since no other record type could coexist with that > CNAME. This would pose a major problem for users of third-party > services which do support TLS with user-provided certs but don't > implement ACME. > > Meanwhile, there is a simple solution that does enable your use case: > Tumblr can ask you to also CNAME _acme-challenge.blog.ericmill.com over > to them. It's slightly inconvenient to have to provision two CNAMEs > instead of one, but this seems preferable to forcing some users > to choose between CNAMEing to a third-party service and being able to > use ACME themselves. > Yes, but this forces users to do the work of adding a second CNAME that points to the third party service, and prevents the service from doing it themselves. The user base that would *benefit* from keeping the prefix consists of users who want to CNAME their domain to a service (instead of full DNS delegation) but who wish to obtain a cert themselves and then upload that certificate to the service they've CNAMEd their domain to. That user base sounds relatively small to me -- certainly smaller than the number of users who currently use (or would use) custom domain support on third party services. To me, it seems like we'll get more widespread use of ACME (and HTTPS adoption) by allowing large services to just "flip the switch" for everyone, rather than involving the user in this decision. The ideal would be to allow both use cases! So perhaps there's a way I'm not thinking of, or perhaps we could split this into two separate DNS-based validation methods, to support both kinds of uses. > > > Also: I can't think of any changes offhand that would enable Let's > > Encrypt to support a use case where users set an A record to point to > > a third party service, such as for apex domains in the services > > mentioned above. But this is another important use case, especially > > for service providers which don't distinguish between apex and > > non-apex domains in their business offerings.[7] It'd be great to > > hear ideas for how that might be achieved. > > Again, just CNAME _acme-challenge over to the third-party service :-) > The prefix does neatly solve the issue of delegating via A records - that's a good point. -- Eric > > Regards, > Andrew > -- konklone.com | @konklone <https://twitter.com/konklone>
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
