Hi all, Another brief update that this ballot now passed at the CA and Browser Forum.
Best, Henry On Thu, Oct 9, 2025 at 12:26 PM Aaron Gable <aaron= [email protected]> wrote: > Since I now realize that I forgot to say this in my previous message: > Let's Encrypt plans to implement the server side of dns-persist in 2026. We > believe that it will provide a real benefit to our ACME clients, especially > in concert with the WebPKI reducing validation data reuse periods over the > next couple years. > > Aaron > > On Thu, Oct 9, 2025 at 8:51 AM Henry Birge-Lee <birgelee= > [email protected]> wrote: > >> Hi all, >> >> Michael Slaughter's ballot for this in the CA/Browser Forum is making >> great progress with (what I believe is) unanimous support and sufficient >> browser support (2 certificate consumer votes) to pass. It is likely the >> voting (which concludes tomorrow) will pass and it will enter IP review. >> >> I have already gotten a commitment to implement this in private from a >> very large ACME CA. >> >> Shiloh has already pushed initial test implementations for a client and a >> CA that interoperate. ( >> https://mailarchive.ietf.org/arch/msg/acme/X7eWneZfFRk19hNg7LuITzlIlk8/ >> ) . Shiloh also represents Fastly/Certainly, another large ACME CA that >> will very likely be implementing. Slaughter represents Amazon Trust >> Services which I would also expect to implement. Both Amazon and Fastly >> additionally run massive numbers of ACME clients which allows them to >> deploy the other side of this protocol as well. >> >> In addition, there is a "no RFC" way of doing this in ACME which several >> CAs have already brought to my attention: check DNS persist records in >> advance and then provide no challenges to the ACME client if there is a >> record. This requires no client modification but comes at a performance >> overhead and eliminates the client's ability to choose which challenge to >> use which is a part of the ACME protocol. If this technique is adopted in >> production without this I-D moving forward there would be no IETF guidance >> around this type of behavior. >> >> *Independent of the IETF's decision to adopt, I feel there is high >> likelihood this technique will be used in production at several large CAs* >> based on implementation interest I have received by various CAs and the >> popularity of the dns-01 with CNAME technique which shows the desire for a >> static DCV-related record. Implementation without an IETF draft would mean >> either 1) implementation only by non-ACME CAs which gives a disadvantage to >> the ACME protocol as there are legitimate use cases for doing this, 2) >> implementation using the "no RFC" approach discussed above without any IETF >> input, or 3) implementation based on a personal, non-adopted I-D. To me all >> three of these outcomes feel subpar. >> >> Based on my talk at IETF 123, I had gotten the impression that the ACME >> WG was interested in providing input on this standard and this approach >> more generally. We felt IETF involvement would be beneficial to the >> community which is why we brought this to the IETF. I encourage members of >> the working group to see this as an opportunity to contribute and improve >> on a standard that is already moving forward in other ecosystems. We want >> to work with the IETF community and have incorporated all feedback to >> date/are hoping for the opportunity to improve this further post adoption. >> >> Best, >> Henry >> >> >> On Tue, Sep 30, 2025 at 10:06 AM Michael Richardson < >> [email protected]> wrote: >> >>> >>> Henry Birge-Lee <[email protected]> wrote: >>> > and the acme-dns.io hosted offering of >>> https://github.com/joohoi/acme-dns ). >>> >>> Oh, yes, I knew about this, but since I already had debugged nsupdate, >>> and >>> could copy and paste that configuration, I never returned to that. >>> >>> > This approach of using a magic CNAME 1) creates a single point of >>> failure >>> > where a compromise of a CNAME service (potentially over the >>> network via DNS >>> > attacks like cache poisoning or BGP attacks) could take down >>> thousands >>> > of >>> >>> DNSSEC solves some of those sins. >>> And the auxiliary zone is much easier to DNSSEC sign. >>> >>> > Another perspective to consider is that should a subscriber >>> automate the >>> > dns-01 challenge, there is a risk the subscriber will put >>> unrestricted DNS >>> > API keys on their ACME client. This is not an ideal security >>> configuration >>> > and avoiding the need for online keys on the ACME client is >>> generally >>> > beneficial for security. >>> >>> I'm hearing that we might need/want CSR-attestation-like mechanism for >>> ACME account and API keys too :-) >>> >>> -- >>> Michael Richardson <[email protected]> . o O ( IPv6 IøT >>> consulting ) >>> Sandelman Software Works Inc, Ottawa and Worldwide >>> >>> >>> >>> >>> _______________________________________________ >> 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]
