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]
