After some deliberation on this, I think we're erring on the side of DNS-ACCOUNT-01 rather than DNS-02. Speaking to a few people privately, there is a concern that DNS-02 implies a deprecation of DNS-01 which is not the intention of this draft. This unintentional implication may be detrimental to the adoption of ACME.
We're also planning on renaming the draft to draft-ietf-acme-dns-account-challenge to reduce the confusion with the two number suffixes. On Mon, May 22, 2023 at 7:33 AM Deb Cooley <debcool...@gmail.com> wrote: > What is confusing is having a numerical value as part of the draft title. > Currently: draft-ietf-acme-dns-account-01-01 which is only going to be > worse as the draft moves through version numbers. My suggestion would be > to name it without the use of a numerical value. This gets rid of both > problems. The only question is what to actually call it. > > Deb Cooley (no hats) > deco...@radium.ncsc.mil > > > > On Fri, May 19, 2023 at 8:38 AM Sean Dilda <s...@duke.edu> wrote: > >> I don't spend a lot of time on the Let's Encrypt forums, but I do >> maintain an internal ACME server and work with the IT staff that manage >> certs/acme client installs. Most of my users are only vaguely aware that >> their ACME client creates an account as part of the process. Given that, I >> suspect they would find the name 'DNS-ACCOUNT-01' confusing as it wouldn't >> be clear to them which account is being referred to. They would likely >> assume it would be the account on their DNS provider. I think 'DNS-02' >> as a newer version of the DNS challenge type would be less confusing. >> ------------------------------ >> *From:* Acme <acme-boun...@ietf.org> on behalf of Amir Omidi <aaomidi= >> 40google....@dmarc.ietf.org> >> *Sent:* Thursday, May 18, 2023 5:03 PM >> *To:* Seo Suchan <tjtn...@gmail.com> >> *Cc:* acme@ietf.org <acme@ietf.org> >> *Subject:* Re: [Acme] DNS-ACCOUNT-01 Updates >> >> I think what decision happens here will probably end up setting the >> precedent on either these digits are "version numbers" of the "base >> challenge types" (Not sure what to call them), and they act as a >> replacement of them. Or that they are another flavor of the >> technologies/protocols used in those challenges. I do not have strong >> opinions here either way. >> >> Another factor to consider is how would support/Q&A forums feel about the >> name choice of DNS-ACCOUNT-01 vs DNS-02. For example, if there is anyone >> here who's keeping an eye on the Let's Encrypt's community forum do you >> think DNS-02 would make things easier or harder for users adopting ACME >> based certificate issuance and the folks helping them out? If harder, do >> you think DNS-ACCOUNT-01 would be a better option here? >> >> On Sat, May 13, 2023 at 5:24 AM Seo Suchan <tjtn...@gmail.com> wrote: >> >> I kinda think TLS-SNI-02 was made as version 2 of TLS-SNI-01, but it >> doesn't matter as they are no longer a thing >> 2023-05-13 오전 3:43에 Q Misell 이(가) 쓴 글: >> >> >> I'm also in favour of calling it DNS-02. I highly doubt there will be >> many (if any) versions of challenges beyond version 1. It makes more sense >> to me to read DNS-02 and DNS challenge type 2, not a upgraded edition of >> version 1. >> ------------------------------ >> >> Any statements contained in this email are personal to the author and are >> not necessarily the statements of the company unless specifically stated. >> AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, >> Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company >> registered in Wales under № 12417574 >> <https://urldefense.com/v3/__https://find-and-update.company-information.service.gov.uk/company/12417574__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLMzA2bpN$>. >> ICO register №: ZA782876 >> <https://urldefense.com/v3/__https://ico.org.uk/ESDWebPages/Entry/ZA782876__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLKSmK3R2$>. >> UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. >> South Korean VAT №: 522-80-03080. Glauca Digital and the Glauca logo are >> registered trademarks in the UK, under № UK00003718474 and № UK00003718468, >> respectively. >> >> >> On Fri, 12 May 2023 at 17:58, Aaron Gable <aaron= >> 40letsencrypt....@dmarc.ietf.org> wrote: >> >> For what it's worth, I'm in favor of calling it DNS-02. Despite your >> totally correct descriptions of the disadvantages of this new method, I >> *do* still view it as a generally-improved version of DNS-01. It's >> obviously backwards-incompatible, hence the new major version number, but >> it is generally an improvement that creates more flexibility for clients at >> little cost. I also find the name "DNS-ACCOUNT-01" to be slightly >> unfortunate, as no "dns accounts" are involved -- it makes sense once you >> understand the method, but the name gives little to no hint to how the >> method works on its own. >> >> Aaron >> >> On Thu, May 11, 2023 at 4:52 PM Antonios Chariton <daknob....@gmail.com> >> wrote: >> >> Hello everyone, >> >> I’m sending this e-mail to the list to update you all on DNS-ACCOUNT-01 >> and the news we have since the presentation in IETF 116. >> >> You can all help by reviewing the text[0], these updates, and sharing >> your opinion in this thread here! >> >> The CA/B Forum 2023-05-04 meeting discussed DNS-ACCOUNT-01 and three >> things came out of it, as it is evident in the minutes[1]: >> >> 1) This method is compatible with the CA/B Forum Baseline Requirements >> that are binding for all WebPKI CAs, specifically section 3.2.2.4.7 for >> agreed-upon change to a DNS record. This means that CAs can start using >> this standard immediately, and there are no other dependencies. The design >> seemed to be good in its current version. Obviously, quick changes to their >> CP/CPS may be required, but this is not blocking and unilateral. >> >> 2) There is a documented need for various usecases where this challenge >> would help, from several stakeholders, and evidence that it could be >> beneficial to the ecosystem and its development. It allows ACME to be used >> in even more situations where more traditional and non-automatable methods >> had to be relied upon. >> >> 3) There was a suggestion to rename this challenge to DNS-02. This is >> something that we had rejected back when we created this challenge, however >> it has been suggested several times, so we are happy to reconsider this. It >> may be the right choice. >> >> There’s no published precedence of what -02 means right now, so it’s >> unclear whether it is a second option, or a next generation / improved >> challenge. We never planned to replace DNS-01 with our challenge, we always >> intended to add more options, and cover more use cases. Here are some >> technical “disadvantages” of this work vs DNS-01: >> >> 1) ACME Clients need to calculate the correct label. Although we provide >> the algorithm, a bash script, and test vectors, anecdotal data from ISRG >> suggest that some clients still mess things up (implementing RFC 8555), so >> this is another value where this may happen. An easy solution here would be >> to share the expected label with the client, but we decided against this to >> protect against cross-protocol attacks, and also to protect the client >> against an ACME server giving it arbitrary DNS records to change. If >> clients calculate this independently, they don’t need to trust the server. >> >> 2) The label is longer, so some very very long domain names may no longer >> work. Since this is 17 characters longer than DNS-01’s label, anything >> approaching the various limits (of DNS, etc.) may break. For example, if in >> DNS-01 you end up with a 236-253 character domain name to check for the TXT >> record, then DNS-ACCOUNT-01 will go over the limit and won’t work. We don’t >> consider this to be a major problem. We’re also not aware of many domain >> names in the 236-253 character range. >> >> 3) If an ACME client for whatever reason loses access to the ACME >> account, this “set and forget” DNS label now has to change. Things would >> break here with other standards too (if you need an EAB token, you can’t >> create a new account anyways, if you limit the ACME account via CAA >> records, you can’t issue, etc.) but DNS-ACCOUNT-01 would just add to the >> things that would have to be taken into account. We don’t currently >> consider this a huge issue, but if you think it could be, let us know. >> >> As you can see, these 3 tradeoffs above had to be made, to ensure we can >> cover more use cases. We think these are good tradeoffs for an additional >> ACME challenge, but perhaps they are not for an “upgraded” one. >> >> What do you think about the naming? Do you perceive “DNS-02” as an >> improved version, or as a second option? We are happy to rename this to >> DNS-02 and we have no plans of breaking any ACME server or client already >> using DNS-01 :) >> >> Thanks for reading through this, and I am happy to hear your thoughts and >> get reviews on the draft, so we can move further with this work. >> >> Antonios Chariton >> Independent Contributor ;) >> >> - - - >> Links: >> >> [0] : >> https://archive.cabforum.org/pipermail/validation/2023-May/001892.html >> <https://urldefense.com/v3/__https://archive.cabforum.org/pipermail/validation/2023-May/001892.html__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLJ-dXGZ7$> >> [1] : https://daknob.github.io/draft-todo-chariton-dns-account-01/ >> <https://urldefense.com/v3/__https://daknob.github.io/draft-todo-chariton-dns-account-01/__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLAIe3NHy$> >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLIdl8lBK$> >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLIdl8lBK$> >> >> >> _______________________________________________ >> Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme >> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLIdl8lBK$> >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLIdl8lBK$> >> >> _______________________________________________ >> 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 >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
