Hi Q and all, We responded on Github and sent out a new version addressing this feedback on Datatracker: https://datatracker.ietf.org/doc/draft-sheurich-acme-dns-persist/
As we mentioned previously, we are aiming for a call for adoption shortly. Best, Henry On Mon, Aug 11, 2025 at 7:30 AM Q Misell <[email protected]> wrote: > Thanks for the continued work! > > I've gone through the draft and opened a few issues on GitHub with my > comments. > > Ar Llun, 11 Awst 2025 am 00:03 Henry Birge-Lee <birgelee= > [email protected]> ysgrifennodd: > >> Hi all, >> >> I wanted to update everyone that I have deprecated my original ACME dns >> persist draft from earlier in this thread in favor of a joint draft with >> Shiloh >> Heurich (Fastly) and Michael Slaughter (Amazon). >> >> The draft is on data tracker at: >> https://datatracker.ietf.org/doc/draft-sheurich-acme-dns-persist/ >> >> We are also working out of GitHub so people can view ongoing >> conversations and issues at: >> https://github.com/sheurich/draft-sheurich-acme-dns-persist >> >> We are hoping to get initial feedback before a call for adoption. I am >> very excited to be working with Slaughter and Shiloh on this draft. Slaughter >> is the author of the ballot SC-088 at the CA/Browser Forum which this >> proposal is based on and Shiloh intends to be doing implementation work >> on Boulder and ACME clients to put this method in. Overall we are hoping to >> have strong alignment with the CA/Browser Forum standard and running >> code in a reasonable timeframe. >> >> Feel free to let us know your thoughts on the draft and its readiness for >> a call for adoption. >> >> Best, >> Henry >> >> >> >> >> On Tue, Jul 15, 2025 at 3:17 PM Henry Birge-Lee <birgelee= >> [email protected]> wrote: >> >>> Hi Q, >>> >>> Thanks for your feedback. I will review RFC9799 and incorporate more of >>> that format. >>> >>> I had always intended to include a concise and informative security >>> implications section as well as an intro and abstract. I will flush out >>> these sections and update the draft (also posting it to datatracker). I >>> never meant for security implications to be contained in mailing list >>> posts, I just wanted to get the core idea of the draft out for feedback >>> first. >>> >>> If there is time in the ACME session for Madrid, I would be happy to >>> give a short presentation. If not I think it is fine to work on this in the >>> list. >>> >>> Thanks again for looking this over. >>> >>> Best, >>> Henry >>> >>> >>> On Tue, Jul 15, 2025 at 3:27 AM Q Misell <q= >>> [email protected]> wrote: >>> >>>> Hi Henry, >>>> >>>> First of all, thanks for the work on this draft so far. >>>> >>>> Whilst clearly at an early draft stage, its pretty concise and clear in >>>> what it achieves. I'd be supportive of progressing this work in the WG. >>>> I think it needs a bit more work before its ready for a call for >>>> adoption. >>>> If you'd like some guidance on the general layout of a document >>>> defining a new ACME challenge (and not to flatter myself too much here) it >>>> might be worth looking at the recently published RFC9799. >>>> >>>> In general, having unique security implications is not in and of itself >>>> a problem. What a draft needs however is a concise, but thorough, >>>> explanation of what they are and how they matter for operators. >>>> An operator won't go and read the mailing list, they'll want it in the >>>> draft of what to do / not do for various security properties. >>>> >>>> Finally, not to pre-empt the chairs, but we usually have a some time >>>> left at the end of the ACME working group, so this should fit nicely into >>>> our any other business. >>>> >>>> Q >>>> ------------------------------ >>>> >>>> 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://find-and-update.company-information.service.gov.uk/company/12417574>, >>>> LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 >>>> <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: >>>> GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean >>>> VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at >>>> Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as >>>> Glauca Digital, is a company registered in Estonia under № 16755226. >>>> Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are >>>> registered trademarks in the UK, under № UK00003718474 and № UK00003718468, >>>> respectively. >>>> >>>> >>>> Ar Maw, 15 Gorff 2025 am 04:31 Henry Birge-Lee <birgelee= >>>> [email protected]> ysgrifennodd: >>>> >>>>> Hi all, >>>>> >>>>> I am an interested party at the CA Browser Forum ( >>>>> https://henrybirgelee.com/ ), and I have worked on some other PKI >>>>> standards. Lately the CA Browser Forum has been in the process of drafting >>>>> a ballot (SC-088) that eliminates the need for ephemeral challenge tokens >>>>> in the DNS change and allows a CA to sign a certificate solely based on >>>>> the >>>>> presence of a persistent DNS record (i.e., a record that does not need to >>>>> change between each renewal) ( >>>>> https://github.com/slghtr-says/servercert/pull/3 ). >>>>> >>>>> I know this is likely too last minute for discussion at Madrid (I had >>>>> originally planned to wait until the ballot was further along before >>>>> bringing this up), but a conversation in the CA/Browser Forum Validation >>>>> Subcommittee came up as to how exactly the new proposed method would be >>>>> implemented in ACME. In the interest of having a concrete proposal, I >>>>> drafted an Internet Draft that provides a tentative outline for what a new >>>>> ACME method could look like to support persistent validation. The draft is >>>>> at: >>>>> >>>>> https://birgelee.github.io/birgelee-acme-dns-persist-01/birgelee-acme-dns-persist-00/draft-birgelee-acme-dns-persist.html >>>>> >>>>> >>>>> The Abstract, Intro, and Security Considerations are still pending, >>>>> but Sections 3 and 4 contain the substance of the proposed method. I would >>>>> be interested to know if any working group members have thoughts on this >>>>> approach. If there is interest I will fill in the missing sections and >>>>> make >>>>> this a more mature draft. In general I think providing an ACME validation >>>>> method for this early on will allow ACME to support persistent validation >>>>> immediately should SC-088 pass. >>>>> >>>>> Also, while I understand there are unique security implications of >>>>> this when compared to the traditional token-based dns-01 validation >>>>> method, >>>>> I would prefer not to focus the conversation on that, and CAs that do not >>>>> wish to use this method can disable it. For reference, I did present a >>>>> more >>>>> in depth security analysis on the CA/Browser Forum list for those who are >>>>> interested ( >>>>> https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/4tATbCpQRpM/m/8mH-SX87BAAJ >>>>> ). >>>>> >>>>> Best, >>>>> Henry >>>>> >>>>> >>>>> _______________________________________________ >>>>> Acme mailing list -- [email protected] >>>>> To unsubscribe send an email to [email protected] >>>>> >>>> _______________________________________________ >> Acme mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
