> 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 <tjtn...@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....@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 >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
