> Instead of just using `base32(SHA-256(<ACCOUNT_URL>)[0:10])`, the ACME client would specify a `client_id` as a response field in the POST response to the challenge URL.
There is precedent for this. The (soon to be RFC) draft-ietf-acme-onion section 3.2 defines responding with additional fields in the challenge. ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. Ar Iau, 16 Ion 2025 am 07:09 Greg T. Wallace <greg= 40gregtwallace....@dmarc.ietf.org> ysgrifennodd: > This could actually be addressed by using something mentioned in RFC 8555 > that hasn't been used before. Section 7.5.1 provides in part "The server > updates the authorization document by updating its representation of the > challenge with the response object provided by the client. The server MUST > ignore any fields in the response object that are not specified as response > fields for this type of challenge. Note that the challenges in this document > do not define any response fields, but future specifications might define > them. The server provides a 200 (OK) response with the updated challenge > object as its body." > > Instead of just using `base32(SHA-256(<ACCOUNT_URL>)[0:10])`, the ACME client > would specify a `client_id` as a response field in the POST response to the > challenge URL. > > e.g., > > POST /acme/chall/prV_B7yEyA4 HTTP/1.1 > Host: example.com > Content-Type: application/jose+json > > { > "protected": base64url({ > "alg": "ES256", > "kid": "https://example.com/acme/acct/evOfKhNU60wg";, > "nonce": "Q_s3MWoqT05TrdkM2MTDcw", > "url": "https://example.com/acme/chall/prV_B7yEyA4"; > }), > "payload": base64url({"client_id": "abcde12345"}), > "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" > } > > Would result in the ACME Server checking for the DNS name: > `_abcde12345._acme-challenge.example.org` > > Resource owners (e.g. a business) can agree to a specific client_id with > their cloud provider(s) to coordinate things like CNAME delegation. This spec > probably should specify the criteria for valid client_id, though it could be > as open ended as `_` + as many valid dns characters as someone wants, so long > as the subdomain length requirement is met. Maybe something like `_` + 16 to > 128 base32 characters (no padding character). > > This also makes a little more logical sense because an ACME Client may manage > many ACME Accounts (and would redundantly need multiple CNAMEs for one > client), or one ACME Account may be present on multiple ACME Clients (and > therefore dns name conflicts would still occur since the SHA256 would be the > same). Using an ID specific to the client allows one CNAME per client and > allows each client to manage its challenges internally to avoid dns name > conflicts. > > If you go this route, `dns-02` may be a more appropriate challenge type. This > would be the same as `dns-01` with added `client_id` field to the challenge > and to the dns name. > > Because of this, to go even a step further, if the ACME Client does not POST > a `client_id` (i.e., it POSTs the empty object `{}`), the current `dns-01` > URL would be expected instead (e.g., `_acme-challenge.www.example.org.`). If > you take this step, this RFC could actually modify the definition of `dns-01` > with full backward compatibility. This prevents the challenge array from > growing in size to accommodate a new challenge type, doesn't break existing > dns-01 implementations (client or server - a client sending the field to an > unsupported server would just have the field ignored and the client would > note the field absence in the response from the server; a server not > receiving the field would use the current dns-01 behavior as the > non-supporting client would already expect), and adds this new functionality. > This would also be preferred to adding as dns-02 and eventually retiring > dns-01 as acme servers and clients would have to proactively update to the > new dns-02 challenge name. > > > As a final note, I know scope was removed from this draft. However, looking > forward, `scope` could be added to the response object as well. Again, as a > non-breaking change with full backwards compat to existing dns-01. > > > > On Sun, Dec 1, 2024 at 2:28 PM Jesper Kristensen <jesperm...@gmail.com> > <<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> <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 >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
