I've been thinking about this more. I'm going to remove the uniqueness stipulation, and just formalize something along the lines of "use the kid that was in the JWS of the request". Obviously the normal "validate the JWS before you just blindly trust it" still applies.
This way, the account KIDs no longer have to be unique, and I think it's a more general solution to this problem. On Tue, Feb 6, 2024 at 5:35 PM Amir Omidi <[email protected]> wrote: > We are using the `kid` value. And from my understanding in the ACME spec, > when a client is responding with a POST request to the challenge URL, the > KID is included in that JWS payload. > > That's the KID that should be used for constructing the validation domain. > > On Mon, Feb 5, 2024 at 12:22 PM Aaron Gable <aaron= > [email protected]> wrote: > >> And I think the implication here is that, if an ACME server responds on >> multiple URIs and reflects those multiple URIs back to the client in the >> Location header, then that server must also support hashes of those >> multiple URIs when conducting DNS-ACCOUNT-01. Does that make sense? >> >> Aaron >> >> On Sat, Feb 3, 2024 at 1:18 PM Amir Omidi <amir= >> [email protected]> wrote: >> >>> No, the accountURL/URI that new-account returns is the only >>> authoritative path. I'll make sure that it is spelled out in the RFC. If an >>> acme client has an account key, it can use the method described here: >>> https://datatracker.ietf.org/doc/html/rfc8555#section-7.3.1 to find the >>> accountURL for that account. >>> >>> Since ACME does not define "what the ID part of an accountURL is", I'm >>> much more inclined on just keeping the entire accountURL as the ID to be >>> hashed for the challenge label. >>> >>> On Sat, Feb 3, 2024 at 3:59 AM Seo Suchan <[email protected]> wrote: >>> >>>> if it's stable but has multiple valid path (ex: acme-v1.ca.com and >>>> acme-v2.ca.com) , would server need try for both subdomain and lookup >>>> every possible valid path? >>>> 2024-02-03 오전 1:35에 Amir Omidi 이(가) 쓴 글: >>>> >>>> From my understanding, under ACME we treat that entire accountURL as >>>> the userID. So I think that URL will need to be stable. >>>> >>>> On Fri, Feb 2, 2024 at 2:36 AM Seo Suchan <[email protected]> wrote: >>>> >>>>> for some ACME servers they have multiple allowed acme endpoint >>>>> domains, >>>>> and server doesn't know what domain name client used to access its API >>>>> duce don't have full accounturl that used to craft challenge subdomain: >>>>> >>>>> like boulder (what Let's encrypt uses) allows to accessed from >>>>> mulitple >>>>> path ex: >>>>> >>>>> "accountURIPrefixes": [ >>>>> "http://boulder.service.consul:4000/acme/reg/";, >>>>> "http://boulder.service.consul:4001/acme/acct/"; >>>>> ] >>>>> >>>>> , and pebble and smallstep do not have host in config but allow any >>>>> ip >>>>> or domain pointed to them and reflect them to create link to >>>>> account/order/ect >>>>> >>>>> would only using userid part of accountURL (ExampleAccount) from >>>>> https://example.com/acme/acct/ExampleAccount have problem? while it's >>>>> trivial to extract from hash to accounturl as accountID was >>>>> autoincrementing counter, but was there are so few large acme provider >>>>> it was trivial to make rainbow table anyway. >>>>> >>>>> _______________________________________________ >>>>> Acme mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/acme >>>>> >>>> _______________________________________________ >>> Acme mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/acme >>> >>
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
