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 <[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]
