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
