On Mon, Sep 26, 2016 at 05:53:26AM +0100, Hugo Landau wrote: > > I don't see a problem with having the directory show that the current > > ToS is "version 3", and the registration object show that explicit > > assent was obtained for "version 1", and leaving it up to the legal > > acrobatics in the text of version 1 to say that explicit assent isn't > > required for the "or later version" terms to apply automatically at > > some point in time. > > In this case a client should have some way to determine if explicit > re-agreement is required. An "agreement-valid": bool field would > suffice for this.
Or just a suitable error code returned for the operation that actually failed? Since that won't likely be a query of the registration object, it's more likely to be noticed when a cert renewal is requested if the server won't honor that without re-agreement. > > Yes, but this was an issue with Boulder's implementation, not the > > protocol per-se. I personally found it surprising that it allowed > > this, but the protocol didn't force it to[1] - it could have refused > > any new-reg request without an acceptance instead of just disallowing > > later operations until one was received. > > > > There were at least some clients that were submitting the acceptance > > with the initial new-reg request. > > Fairly sure the only way to determine the ToS URI is by registering > first so you can get it from the Link header. The ToS URI still isn't > available in boulder's directory: > https://acme-v01.api.letsencrypt.org/directory Ah yes, you're correct about that. I even have a very special warning in my code for the case where a user passes --accept-tos when it hasn't yet been seen, to cover the case of current Boulder. I do cache it on a per-CA basis though, so that would work if you'd registered at least one account previously and the ToS hadn't changed. (it's cached precisely so that the user can be warned if/when it does ever change). Unless I've forgotten something else, it is still a glitch in Boulder rather than the protocol spec though. > So if any clients were submitting the ToS URI they must have been > hardcoding it, which is a terrible practice. At least one (very popular one) definitely was/is, and yes it is. I didn't start writing a client of my own because I thought Good Practice (for my use case) was already a solved problem :) _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
