The point of adding more validation mechanisms should be to cover more use cases. So examples that http challenge response covers are not too helpful. I do not see the value of a second type of c/r scheme. Dns is a lousy match for c/r. Why are people so set on this? If you want to use dns, use a signing key to authorize the request. Put the fingerprint of the key in the dns
Sent from Outlook Mobile On Thu, Dec 17, 2015 at 12:58 PM -0800, "Ted Hardie" <[email protected]> wrote: On Thu, Dec 17, 2015 at 8:19 AM, Andrew Ayer <[email protected]> wrote: On Thu, 17 Dec 2015 02:23:20 -0500 Eric Mill <[email protected]> wrote: > Since DNS specifies that a CNAME can be thought of as an alias[6], > this means that a service like Tumblr is capable of setting a TXT > record for domains.tumblr.com with the validation token for > blog.ericmill.com. A spec-compliant DNS resolver looking for a TXT > record for blog.ericmill.com should follow the CNAME alias first, and > then correctly identify the TXT record for domains.tumblr.com as > applying to blog.ericmill.com. > > However, the current ACME spec asks for the record to be set for a > prefix, not for the requested FQDN. And if I CNAME blog.ericmill.com > over to Tumblr, Tumblr does not have the ability to set any records > for a prefix, such as _acme-challenge.blog.ericmill.com. This means > that services which have users CNAME domains are not able to use DNS > validation to obtain certificates. > > 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. Do any of the relevant services support ALIAS or DNAME? I'm also kind of wondering how many TXT records would build up at something like domains.tumblr.com if it was the target for many different blogs. regards, Ted 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. > 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 :-) Regards, Andrew _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
