I support adopting this draft. I would articulate the two problems this draft is trying to solve as follows: 1. The webserver-based (http-01 and tls-alpn-01) challenges have operational difficulties: some webmasters don't want to have port 80 open, or use geo-ip blocking, or want to obtain a wildcard certificate (the WebPKI appropriately does not allow using these methods to validate wildcard names). 2. The DNS-based (dns-01 and dns-account-01) challenges have operational difficulties: DNS propagation can be slow, and many webmasters (appropriately) don't want to have DNS API keys on the same host as their ACME client (which is often on the same host as their webserver).
So even regardless of the approach taken here, I think this problem space is worth tackling. But beyond that, I think that this *solution* space is quite interesting, and worth discussing as a Working Group. The key insight is that, because ACME accounts are tightly bound to keypairs, ACME account URLs can be durable and cryptographically-bound stand-ins for random tokens. Both this method and the existing dns-01 show the same thing: the DNS operator approves of the operator of a specific ACME account. Of course, there's one hiccup: they actually only show *almost* the same thing. The dns-01 method shows that the DNS operator approves of the operator of a given ACME account (the one to which the random token was sent) *right now*. The proposed dns-persist-01 only demonstrates that the DNS operator approved of the ACME account *at some point in the past*. But while I think that distinction is critical and worth discussing extensively, I don't think it is disqualifying. In particular, I think that the tradeoff here -- less proof-of-freshness in return for massive operational simplification -- will result in large uptake of this validation method and a large improvement to the security and privacy of the web overall. Aaron On Fri, Sep 26, 2025 at 8:14 AM Mike Ounsworth via Datatracker < [email protected]> wrote: > > Subject: Call for adoption: draft-sheurich-acme-dns-persist-01 (Ends > 2025-10-10) > > This message starts a 2-week Call for Adoption for this document. > > Abstract: > This document specifies "dns-persist-01", a new validation method for > the Automated Certificate Management Environment (ACME) protocol. > This method allows a Certification Authority (CA) to verify control > over a domain by confirming the presence of a persistent DNS TXT > record containing CA and account identification information. This > method is particularly suited for environments where traditional > challenge methods are impractical, such as IoT deployments, multi- > tenant platforms, and scenarios requiring batch certificate > operations. The validation method is designed with a strong focus on > security and robustness, incorporating widely adopted industry best > practices for persistent domain control validation. This design aims > to make it suitable for Certification Authorities operating under > various policy environments, including those that align with the CA/ > Browser Forum Baseline Requirements. > > File can be retrieved from: > https://datatracker.ietf.org/doc/draft-sheurich-acme-dns-persist/ > > Please reply to this message keeping [email protected] in copy by indicating > whether you support or not the adoption of this draft as a WG document. > Comments to motivate your preference are highly appreciated. > > Authors, and WG participants in general, are reminded of the Intellectual > Property Rights (IPR) disclosure obligations described in BCP 79 [2]. > Appropriate IPR disclosures required for full conformance with the > provisions > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > Sanctions available for application to violators of IETF IPR Policy can be > found at [3]. > > Thank you. > [1] https://datatracker.ietf.org/doc/bcp78/ > [2] https://datatracker.ietf.org/doc/bcp79/ > [3] https://datatracker.ietf.org/doc/rfc6701/ > > > > _______________________________________________ > 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]
