Hi Paul and DNSOP, As an author of the dns-persist EITF draft ( https://datatracker.ietf.org/doc/draft-ietf-acme-dns-persist/ ) and an advocate of the technique at the CA/Browser Forum, I am happy you consider it worthy of reference. I do think referencing it in validation techniques would help future proof verification-techniques when it goes through the RFC process. I think there will be significant adoption of the method based on the current dynamics we see in the web PKI (I discuss this in this blog post if you are interested: https://www.crosslayerlabs.com/blog/the-future-of-domain-control-validation ), and referencing it in (what is currently) the canonical work on DCV methods would be helpful.
Also, I know the IETF draft is still in early versions (-00) but in some ways this approach is already standardized. Michael Slaughter's CA/Browser Forum ballot that outlines exactly how CAs perform dns-persist DCV and which fields need to be checked was already voted through a couple months ago. For the most part the wire protocol between the CA and the domain is thus standardized and the IETF ACME draft is the ACME protocol application of this. So while its understandable to be hesitant about a -00 I-D (and I can't speak to exactly what the ACME-specific parts of the protocol will ultimately look like after WG iteration), I do think there will likely be dns-persist DCV and a corresponding ACME draft worth referencing. Best, Henry On Wed, Feb 18, 2026 at 10:06 AM Paul Hoffman <[email protected]> wrote: > Greetings again. draft-ietf-dnsop-domain-verification-techniques-11 talks > about ACME a bit, but has not been updated to cover a new proposal in the > ACME WG, draft-ietf-acme-dns-persist-00. I normally wouldn't expect such a > reference to a -00 draft from another WG, except that in this case the new > protocol is already seeing adoption. For example, Let's Encrypt posted this > today: > https://letsencrypt.org/2026/02/18/dns-persist-01.html > > draft-ietf-acme-dns-persist is relevant to > draft-ietf-dnsop-domain-verification-techniques for two significant > reasons. First, it models a new method of domain control validation that > can reduce the attack surface for a domain name. Second, it fixes the > wildcard problem discussed in Section 5 of > draft-ietf-dnsop-domain-verification-techniques. > > It would be grand if the -12 version covered this new ACME work, even if > that new ACME work is not yet finished. > > --Paul Hoffman > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
