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