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]
