I'm also strongly in favour of this change. I think the minimal increase in client state/complexity is offset by the gain of knowing that the category of potential bugs that Jacob mentions are avoided.
On Tue, Sep 27, 2016 at 1:01 AM, Martin Thomson <[email protected]> wrote: > 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 <[email protected]> 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 > >> [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 >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
