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
