That indeed sounds like an interesting use case but brings many security concerns and challenges with it. One thing I've learned throughout this process is trying to prevent scope creep within this draft (which I've fallen victim to a couple of times during this process!)
The challenge being introduced here is not intended to be a solution for all possible scenarios, but rather the primary scenario of having multiple separate systems managing ACME certificates. Furthermore, the primary design constraint of this challenge is to make it easy for both ACME servers, and for ACME clients to adopt it, without diverging too much from the security footprint that the existing DNS-01 challenge provides. I do think that there is opportunity for future challenges to be introduced to cover more use cases like the one you mentioned. Cheers! On Sun, Dec 1, 2024 at 2:28 PM Jesper Kristensen <jesperm...@gmail.com> wrote: > Hi > > This document provides some nice added flexibility, but I am puzzled why > it does not go one step further. While this document allows multiple ACME > clients to run independently, it assumes that they are all controlled by > the same entity who also sets up the DNS CNAME records. This might work > great in a setup with multiple datacenters each needing to run their own > ACME client independently, or even multiple clouds assuming the cloud > customer is the one running these ACME clients. But I don't think it allows > for using multiple clouds when the cloud providers are the ones running the > ACME clients, for example for cloud services where the cloud provider > terminates the TLS connection for the customer. If a cloud provider were to > offer the dns-account-01 challenge to their customers without the same > cloud provider also controlling the customer's DNS, the cloud provider > would have to ask all their customers to create new CNAME records every > time they change what ACME account they use, e.g. when they add support for > a new CA. I don't think many cloud providers would accept such a limitation > for managing their ACME clients. This additional use case could be > supported by letting the client choose the domain label within certain > limits, instead of basing it on the ACME account URL. The document says > that the binding to account URI is not for integrity so the truncation to > 10 bytes is not a problem. But if integrity is not achieved anyway, why > then limit it to be coupled with the account URL, and therefore rule out > the use case where the entity controlling the DNS and setting up CNAME > records is different from the entity running the ACME client and managing > certificates? You would need to specify what a valid construction of the > domain label would be, and the CA would need to validate that when they > validate a challenge if they are no longer fully in control of the label, > but that seems to me to be a small price to pay to unlock this additional > use case. > > Den man. 18. nov. 2024 kl. 17.50 skrev Amir Omidi <amir= > 40aaomidi....@dmarc.ietf.org>: > >> Hi everyone, >> >> Based on the feedback received, we've published a new version of the >> DNS-ACCOUNT-01 draft ( >> https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account-label/). >> This version has been simplified by removing DNS-02 and the scoping >> mechanism, focusing purely on enabling multiple concurrent ACME clients to >> authorize the same domain. >> >> Key changes: >> >> - Removed DNS-02 challenge type completely >> - Removed the scoping mechanism (host/wildcard/domain) >> - Simplified DNS record format >> - More focused introduction on the core problem of enabling multiple >> concurrent ACME clients >> - Better explanation of use cases like multi-region deployments >> >> >> We welcome your feedback on these changes. >> >> Best regards, >> Amir Omidi >> _______________________________________________ >> Acme mailing list -- acme@ietf.org >> To unsubscribe send an email to acme-le...@ietf.org >> >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
