Thanks for the e-mail Corey! > On 12 May 2023, at 15:35, Corey Bonnell <[email protected]> wrote: > > > ACME Clients need to calculate the correct label. Although we provide the > > algorithm, a bash script, and test vectors, anecdotal data from ISRG > > suggest that some clients still mess things up (implementing RFC 8555), so > > this is another value where this may happen. An easy solution here would be > > to share the expected label with the client, but we decided against this to > > protect against cross-protocol attacks, and also to protect the client > > against an ACME server giving it arbitrary DNS records to change. If > > clients calculate this independently, they don’t need to trust the server. > > I agree that the server shouldn’t be providing the label. Perhaps requiring > that the account URL be normalized according to RFC 3986, section 6 prior to > hashing would alleviate some of the interoperability issues?
You brought this up again, sorry I didn’t address this. We chose to define this as the value returned in the “Location" header *because* URI normalization exists (and therefore there could be many equivalent URLs). It’s now up to the server and whatever it returns, which we assume is constant through time. Perhaps we can change this to use RFC 3986 section 6.2.2 *and require* normalization: you convert everything to uppercase, you remove the dot paths, etc. We’d perhaps have to also make some decisions there for the paragraphs that are leaving this up to the end user. That’s the main reason we used the “Location” header — we couldn’t find a very clear definition that’s opinionated enough :) Two more points I see here are: 1) We’d have to make sure whatever definition we use and whatever choices we make is supported in enough libraries already to make adoption easier. I could see two libraries implementing RFC 3986 and not producing the same canonical URI. 2) We may break whoever is currently using this challenge already and require them to change their DNS records. I think there are a few tens of organizations out there using DNS-ACCOUNT-01 in production already, but I don’t remember if the “Location” header value fits the RFC equivalence definition. If we don’t make this change, the only issue I see is with an ACME server changing how it calculates the “Location” value over time (maybe now they remove the trailing / and they didn’t before), but a lot of these changes would still pass the equivalency normalization of section 6.2.2. Anyone has more thoughts? Antonis
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
