On Fri, May 12, 2023 at 10:53:51PM +0200, Antonios Chariton wrote: > Thanks for the e-mail Corey! > > > On 12 May 2023, at 15:35, Corey Bonnell <[email protected]> wrote: > > > > 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?
I would think that would make interoperability issues way worse. > 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. ACME already requires backechoing location (kid in requests). One interop failure mode I have have heard about was some unnamed ACME server puking if slashes were escaped in JSON (escaping slashes is not a good idea, but JSON requires supporting that). And it is good idea for ACME server to avoid using percent encodes or putting any weird characters into the account URL. > 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 :) Besides thinking that normalization would cause worse interoperability issues, I don't think this is even technically implementable, because section 6.2.2. does not precisely define normalization used (observe the words "includes such techniques as"). > 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. I don't think anything except raw UTF-8 serialization of location header value (as the value is formally unicode) is supported enough. > 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. If ACME server changes how it calculates Location, it better be prepared to receive old format account URLs, as clients may have stored those. And besides, given that accounts are security-critical function, I think that applying any sort of "normalization" to those is extremely bad idea. -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
