I am inclined to think that this is a good change, on the basis that it means that the server is minting the identifiers that the client uses. I think that Jacob is probably understating the potential for bugs here. And key canonicalization is a bad smell.
On 27 September 2016 at 14:51, Jacob Hoffman-Andrews <j...@eff.org> wrote: > I understand the concern, but I think that clients already have to store > a significant amount of state: the ACME directory URL, the private key, > and the domain names, certificates, and private keys of existing > certificates. I think that one more item, the account URL, is not a > heavy burden, especially when weighed against a real flaw in the > protocol. You could consider it akin to storing a username and password > for a more traditional login. > > All that said, for clients that find it to be a big savings, there is > always the method of finding the account URL by POSTing again to new-reg > with the same key. > > On 09/24/2016 06:16 PM, Hugo Landau wrote: >> I'm somewhat against this on the grounds that it introduces unnecessary >> state into clients (the registration URI), increasing their complexity. >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
