[Acme] Re: draft-ietf-acme-dns-persist-02

[Seo Suchan <[e-mail]>]

GTS decided to use draft-01 version as is in production until it 
finalize: should this make we better bump challenge number?

https://developers.google.com/public-key-infrastructure/updates/september2026-dns-persist-01 


26. 9. 26. 11:05에 Sebastian Robin Nielsen 이(가) 쓴 글:
>
> The point of versioning (not in the datatracker, but with the 
> protocol/challenge name) is so a server during a ”overlap period” 
> could offer both dns-persist-01 and dns-persist-02 before 
> dns-persist-01 is sunsetted.
>
> In this way, old certificates for live sites doesn’t break because 
> breaking changes are made and client doesn’t speak the correct 
> protocol variant.
>
> Im pretty sure dns-persist-01 have never seen real production use 
> (with live certificates).
>
> The biggest problem with updating versioning numbers in staging is 
> that too many changes will get weird numbers like dns-persist-27, 
> http-12, tls-alpn-32, dns-23 and so on. So I think the number should 
> only be changed if protocol changes are made since the challenge 
> method have been in production – as defined by ”lets encrypt”.
>
> By using ”lets encrypt” as the gold standard, it also ensures clients 
> are updated correctly.
>
> *Från:*Henry Birge-Lee <henry=[e-mail]>
> *Skickat:* den 26 september 2026 03:55
> *Till:* Sebastian Robin Nielsen <sebastian=[e-mail]>
> *Kopia:* Mailing List <[e-mail]>
> *Ämne:* [Acme] Re: draft-ietf-acme-dns-persist-02
>
> Hi Sebastian,
>
> While I am not that particular about IETF draft version numbers, I did 
> want to point out that in a CA/Browser forum call several weeks back 
> some CAs spoke to signing certificates using the standard accounturi 
> format. I believe there is production use of dns-persist records with 
> accounturi=<account URL from ACME directory server>
>
> I am also a bit confused as -01 was on data tracker. Isn't the point 
> of versioning to allow references to snapshots in the document's history?
>
> Best,
>
> Henry
>
> On Fri, Sep 25, 2026 at 9:49 PM Sebastian Robin Nielsen 
> <sebastian=[e-mail]> wrote:
>
>     Also, I do not think we should up the version number to
>     dns-persist-02.
>
>     Since dns-persist-01 have ever only been in staging, so even if
>     breaking changes are made, it will not harm a live site.
>
>     It will just harm people’s testing scripts and testing machines
>     and testing sites.
>
>     No real (live) certificate have ever been issued using
>     dns-persist-01 so I think we should keep it at dns-persist-01 even
>     tough significant protocol changes are made.
>
>     The only reason to change the version number is if a sunset and
>     overlap period is needed, so a ACME server or a client need to be
>     able to speak both protocol variants at the same time.
>
>     Since dns-persist-01 have ever only been in staging, we could make
>     the switch using a ”flag day”. Clients will get ample time to
>     upgrade their protocol code since the ”new” variant of
>     dns-perist-01 (with hashed URIs) will also be in staging for a
>     period before going live in production.
>
>     *Från:*Matthew McPherrin <mattm=[e-mail]>
>     *Skickat:* den 26 september 2026 02:08
>     *Till:* Henry Birge-Lee <henry=[e-mail]>
>     *Kopia:* Max Hearnden <[e-mail]>; [e-mail]
>     *Ämne:* [Acme] Re: draft-ietf-acme-dns-persist-02
>
>     On Tue, Sep 22, 2026 at 6:07 PM Henry Birge-Lee
>     <henry=[e-mail]> wrote:
>
>         The concern would probably be some storage attack on the CA by
>         making a bunch of key rotations but this would have to be
>         balanced with a comparable attack that could just come from
>         making a bunch of new ACME account.
>
>     The registrations table for all Let's Encrypt accounts, ever, is
>     under 350 gigabytes. We haven't even bothered to implement any
>     sort of unused-account pruning in our production environment,
>     though perhaps we will some day.
>
>     I'm not particularly worried about the storage aspect here, and if
>     an account is misbehaving or otherwise acting maliciously, we can
>     always just ban them.
>
>     _______________________________________________
>     Acme mailing list -- [e-mail]
>     To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> Acme mailing list [e-mail]
> To unsubscribe send an email [e-mail]