Clients do not have this removal behavior today, and there is still the issue of multiple providers and delegation of initiating the validation to hosting providers.
On Tue, Aug 30, 2022 at 10:31 AM John Han <[email protected]> wrote: > oh that makes sense. But I still can't get it. > if user use "_acme-challenge.example.com IN CNAME > example.com.validation.com", you can set TXT records like this. > example.com.validation.com TXT [ACME client 1] > example.com.validation.com TXT [ACME client 2] > ... > example.com.validation.com TXT [ACME client n] > since RFC8555 only requires " Verify that the contents of one of the TXT > records match the digest value". After validation, ACME clients just > remove what they write into DNS. > Should I missed something? > 在2022年8月30日星期二 UTC+8 23:51:37<[email protected]> 写道： > >> The main goal with this proposal is to be able to enable delegating >> domain control validation to multiple providers via CNAME. Since CNAMEs >> have to be unique in a DNS Zone, we're left with modifying the label of the >> TXT record. >> On Tuesday, August 30, 2022 at 11:11:22 AM UTC-4 [email protected] >> wrote: >> >>> How about use multiple TXT records for longer hash? like "_ >>> acme-challenge_accounts.example.com TXT [account hash]" >>> >>> 在2022年8月23日星期二 UTC+8 23:15:04<[email protected]> 写道： >>> >>>> This message is to solicit opinions about a proposed new ACME challenge >>>> to address hosting environments where a user cannot easily prove control >>>> using existing methods, but could via an alternative DNS-based approach. >>>> >>>> We have observed cases where customers want to restrict DNS changes for >>>> most of their domains and delegate the domain control validation through >>>> CNAMEs to a centralized location. However, with DNS-01 having a static >>>> label, these customers are prevented from being able to use CNAME >>>> delegation to integrate with more than one ACME CA for certificate >>>> issuance. >>>> >>>> Being able to have multiple independent instances of an ACME client >>>> obtain certificates for the same domain is particularly important for High >>>> Availability deployments, where Subscribers often set up multiple >>>> independent serving stacks that integrate with multiple ACME CAs for >>>> failover and need a valid certificate in each of them. >>>> >>>> The new challenge is called DNS-ACCOUNT-01 and it extends (but does not >>>> replace) DNS-01 in the following way: the DNS label under which the TXT >>>> record is created to respond to the challenge is account dependent. This >>>> allows a Subscriber to use multiple and separate subdomains to solve ACME >>>> challenges for the same domain. >>>> >>>> We plan to submit this as a draft to the IETF for consideration, to >>>> make the challenge available to all CAs and promote its adoption in ACME >>>> clients. >>>> >>>> >>>> The current draft is available here: >>>> https://daknob.github.io/draft-todo-chariton-dns-account-01/ >>>> >>>> A text version is available here: >>>> https://daknob.github.io/draft-todo-chariton-dns-account-01/draft.txt >>>> >>>> >>>> In DNS-01, the CA checks for DNS records under _acme-challenge. In >>>> DNS-ACCOUNT-01, the CA will check for DNS records under >>>> _acme-challenge_accountUniqueValue, e.g. _acme-challenge_ujmmovf2vn55tgye. >>>> The last part is constructed from base32 encoding a part of the SHA-256 >>>> hash of the ACME Account URL. This allows each ACME account to use a >>>> separate subdomain for the TXT record. We believe that BR Method 3.2.2.4.7 >>>> can be used with the proposed challenge for proof of domain control. >>>> >>>> >>>> We welcome any thoughts you may have on the matter and we will be happy >>>> to discuss this and move it forward. >>>> >>> -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/162fba26-bfe0-4cdf-a9fe-e57ec02a38fbn%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/162fba26-bfe0-4cdf-a9fe-e57ec02a38fbn%40mozilla.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CALVZKwZ_mOj5HdwF0RqCdFUSgka4%2BNsOebUm%3DVuVOua5G0KfXQ%40mail.gmail.com.
