What is the rationale for removing the scoping mechanism? As an operator that is using ACME, that is also a recurring problem that introduces risk that limits some use-cases (specifically it makes it more risky to use ACME) .
At a minimum it would be good to call out this risk in Security Considerations. The rationale is called out in draft-ietf-dnsop-domain-verification-techniques ( https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-06 ). I can see why domain-challenge might not be relevant for the ACME use-case, leaving primarily the host and wildcard cases. Specifically (pasting from that draft): 4. <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-06#section-4>Scope of Validation <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-06#name-scope-of-validation> *For security reasons, it is crucial to understand the scope of the domain name being validated. Both Application Service Providers and the User need to clearly specify and understand whether the validation request is for a single hostname, a wildcard (all hostnames immediately under that domain), or for the entire domain and subdomains rooted at that name. This is particularly important in large multi-tenant enterprises, where an individual deployer of a service may not necessarily have operational authority of an entire domain.* *In the case of X.509 certificate issuance, the certificate signing request and associated challenge are clear about whether they are for a single host or a wildcard domain. Unfortunately, the ACME protocol's DNS-01 challenge mechanism ([RFC8555 <https://www.rfc-editor.org/rfc/rfc8555>], Section 8.4 <https://rfc-editor.org/rfc/rfc8555#section-8.4>) does not differentiate these cases in the DNS Validation Record. In the absence of this distinction, the DNS administrator tasked with deploying the Validation Record may need to explicitly confirm the details of the certificate issuance request to make sure the certificate is not given broader authority than the User intended. (The ACME protocol is addressing this in [ACME-SCOPED-CHALLENGE <https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/>].)* *In the more general case of an Internet application service granting authority to a domain owner, again no existing DNS challenge scheme makes this distinction today. New applications should consider having different application names for different scopes, as described below in Section 5.2.1 <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-06#scope-indication>. Regardless, services should very clearly indicate the scope of the validation in their public documentation so that the domain administrator can use this information to assess whether the Validation Record is granting the appropriately scoped authority.* 5.2.1. <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-06#section-5.2.1>Scope Indication <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-06#name-scope-indication> *For applications that may apply more broadly than to a single hostname, the RECOMMENDED approach is to differentiate the application-specific underscore prefix labels to also include the scope (see Section 4 <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-06#scope>). In particular:* - *"_<PROVIDER_RELEVANT_NAME>-host-challenge.example.com <http://host-challenge.example.com>" applies only to the specific hostname of "example.com <http://example.com>" and not to anything underneath it.* - *"_<PROVIDER_RELEVANT_NAME>-wildcard-challenge.example.com <http://wildcard-challenge.example.com>" applies to all hostnames at the level immediately underneath "example.com <http://example.com>". For example, it would apply to "foo.example.com <http://foo.example.com>" but not "example.com <http://example.com>" nor "quux.bar.example.com <http://quux.bar.example.com>"* *[...]* Best, Erik On Tue, Nov 19, 2024 at 4:57 PM Wayne Thayer <wtha...@gmail.com> wrote: > Thank you Amir. This draft solves a problem that is hindering adoption of > ACME. I’ve reviewed it and am happy with the simplifications that place the > focus on solving that one specific problem. > > In order for CAs to implement this new domain validation method, the CAB > Forum’s TLS Baseline Requirements need to be updated. Unless concerns are > posted in the next week or two that might result in material changes to the > current draft, I will start a CAB Forum ballot to add dns-account-01 as an > additional permitted validation method in the TLS baseline Requirements. > > Thanks, > > Wayne > > On Mon, Nov 18, 2024 at 9:50 AM Amir Omidi <amir= > 40aaomidi....@dmarc.ietf.org> wrote: > >> Hi everyone, >> >> Based on the feedback received, we've published a new version of the >> DNS-ACCOUNT-01 draft ( >> https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account-label/). >> This version has been simplified by removing DNS-02 and the scoping >> mechanism, focusing purely on enabling multiple concurrent ACME clients to >> authorize the same domain. >> >> Key changes: >> >> - Removed DNS-02 challenge type completely >> - Removed the scoping mechanism (host/wildcard/domain) >> - Simplified DNS record format >> - More focused introduction on the core problem of enabling multiple >> concurrent ACME clients >> - Better explanation of use cases like multi-region deployments >> >> >> We welcome your feedback on these changes. >> >> Best regards, >> Amir Omidi >> _______________________________________________ >> Acme mailing list -- acme@ietf.org >> To unsubscribe send an email to acme-le...@ietf.org >> > _______________________________________________ > Acme mailing list -- acme@ietf.org > To unsubscribe send an email to acme-le...@ietf.org >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
