Re: [Acme] scope in dns-account-01 and dns-02 challenge

> I think it doesn't specify how the scope for a given challenge is decided
and communicated.

Great point. My intention that I should probably clarify in the draft is
that the server picks based on the Authorization object:

   - If wildcard: true on the authorization object associated with the
   challenge, then the wildcard scope is used. (
   https://www.rfc-editor.org/rfc/rfc8555#section-7.1.4)
   - If subdomainAuthAllowed: true on the authorization object associated
   with the challenge, then the domain scope is used. (
   https://www.rfc-editor.org/rfc/rfc9444#section-4.1)
   - If none of these are present, then the host scope is used.

I guess there's an issue here where both wildcard and subdomainAuthAllowed
may be present?

Out of the options presented, I like the first and the third options here.
I also see what you mean by dropping dns-02, and just specifying three
dns-account-01 challenges.

On Mon, Mar 18, 2024 at 7:22 PM Seo Suchan <tjtncks@gmail.com> wrote:

> Would it be illegal to server probe both scope and pass if there is
> intended token?
>
>
> On 2024년 3월 19일 오전 8시 3분 7초 GMT+09:00, Jacob Hoffman-Andrews <jsha=
> 40letsencrypt.org@dmarc.ietf.org> wrote:
>
>> Thanks, authors, for the updates in
>> https://datatracker.ietf.org/doc/html/draft-ietf-acme-scoped-dns-challenges-00
>> .
>>
>> Adding a "scope" (host, wildcard, or subdomain) to the DNS record name is
>> great. Reading the draft, I think it doesn't specify how the scope for a
>> given challenge is decided and communicated. Three ideas:
>>
>> 1. Server picks, and tells the client.
>>
>> The challenge object contains a "scope" field. The client verifies that
>> the indicated scope is one of "host", "wildcard", or "subdomain", and is
>> less than the maximal scope the client is willing to validate for. For
>> instance, a client might be configured to only accept "host" scope.
>>
>> 2. Client picks.
>>
>> When the client POSTs to the challenge URL, instead of sending the empty
>> object {}, it sends {"scope": "host"}, {"scope": "wildcard"}, or {"scope":
>> "domain"}. The server verifies that the request scope is sufficient for the
>> authorization object (i.e. "wildcard" or above for an authorization object
>> that can be used to issue for a wildcard name), then performs the
>> validation.
>>
>> 3. Server offers options via challenge types
>>
>> We explode out the challenge types from two to six:
>>
>> dns-host-02
>> dns-wildcard-02
>> dns-domain-02
>> dns-account-host-01
>> dns-account-wildcard-01
>> dns-account-domain-01
>>
>> The server populates the authorization object with only those challenge
>> types that are acceptable. For instance, if the authorization object can be
>> used to issue for a wildcard name, the server would not offer dns-host-02
>> or dns-account-host-01.
>>
>> I like this option the best because it provides cleaner separation, and
>> uses the design of ACME nicely: servers offer appropriate challenges, and
>> clients pick the challenge that works best for them. Also it allows for
>> clean implementation in the BRs: they could specify by name which challenge
>> types are allowed to issue for wildcards.
>>
>> Of course, it feels messy to define so many challenge types. Perhaps we
>> could eliminate the dns-02 family? The idea being that clients and servers
>> that wish to adopt the modern best practices from
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/,
>> they can also adopt the account-scoping features of the dns-account-01
>> family, which are not burdensome.
>>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>