On Sat, Sep 10, 2016 at 07:13:23PM -0400, Richard Barnes wrote: > OK, let me clarify my invariants here: I think we can't get away with not > supporting the case where the CA updates the terms and needs clients to > re-agree. I also feel like the current proposal in #167 is semantically > incomplete, like just saying "I agree" ... to what?
That was the major problem I hadn't liked about this too. > I think both of these issues can be addressed with a few tweaks to this > Jacob's proposal: > > - Clarify that having the agreement flag set means that the client has > agreed to whatever is in directory["terms-of-service"] > - Note that that implies that if the CA changes the terms in a breaking > way, then it needs to clear the flag in the registrations > - Add an error code "agreementRequired" (as in #182) so that the CA can > tell the client when this has happened I'd still be happier if the "terms-of-service" field actually reflected exactly what was agreed to (ie. what was in the directory at the time of agreement) rather than being a potentially ambiguous flag. I don't really see how the possible failure modes for that are different, and it does remove any doubt if a client needs to query what had been agreed to previously. I think Richard's suggestion would be equivalent to that if the spec mandated that interpretation with MUSTs, _and_ server implementors didn't screw up that seldom-exercised code path, _and_ server admins updating a ToS don't screw up indicating that flag must be cleared ... which is why I prefer the more explicit semantics in the protocol. A real screw up _should_ result in early and loud failure rather than being swept under the rug. That's the only way they get found and fixed. > I agree that this will still be a seldom-exercised code path -- a lazy > implementer might still fail to properly handle the "agreementRequired" > error code. But at least (1) it gives a conscientious implementer a clear > signal and (2) if the client does screw it up and complains to the CA, it > gives the CA something they can point to and say "you didn't do this > properly". There is an easy way to fix that ... LE has a staging server (and any other CA wanting to implement this would likely want to have one too). And there's no reason the staging server need to have the same ToS as the live service. So it can just update its ToS once a day or so, even if it's just to change a single line "The is the staging ToS for Sep 13, 2016". Anything that isn't tested Will be broken. We can't fix that in the protocol, but we can fix it by adding tests :) Ron _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
