Within draft-ietf-dnsop-domain-verification-techniques <https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques> there is considerable discussion about the risks associated with DNS DCV records (such as ACME DNS-01) not being clear in the record about whether the scope applies to just a single hostname (example.com) or to a wildcard (*.example.com). While DNS-01 has this within the token, the DNS TXT record itself only includes a hash of the token making this hard for a DNS admin to validate.
We have a proposed change to use distinct labels for different scopes. For example: * "`_acme-host-challenge.example.com`" applies only to the specific host name of "example.com" and not to anything underneath it. * "`_acme-wildcard-challenge.example.com`" applies to all host names at the level immediately underneath "example.com". For example, it would apply to " foo.example.com" but not "example.com" nor "quux.bar.example.com". In the ACME context this would be for *.example.com. Pull request for this is here: <goog_1991325217> https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/90/files What is the sense of the ACME WG on if this would make sense? Roll-out would presumably take quite some time so both would need to keep working. I'd suggest that it may make sense to incorporate as part of draft-ietf-acme-dns-account-challenge since the roll-out for both would likely follow a similar pattern. In that case I'd proposed that we'd replace the "-account" in that draft with a specification to use either "-host" or "-wildcard" depending on scope. (That might also mean expanding the title of that draft.) There's also a scope of the domain and its subdomains, covering example.com, *.example.com, *.*.example.com, *.{...}.example.com, etc, but this isn't something specified by ACME due to the semantics of wilcards X509 certs. Erik
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
