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

[Seo Suchan <[e-mail]>]

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=[e-mail]> 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.