On Fri, Aug 19, 2016 at 09:58:42AM -0700, Jacob Hoffman-Andrews wrote: > On 08/18/2016 07:18 PM, Ron wrote: > > It's more that I don't see what we gain from replacing the rich > > interface of: > > I'm specifically saying that we should strictly avoid rich interfaces > whenever we don't need them. Complexity is always where brokenness > creeps in.
Ok, forget the word 'rich' then, because I'm not arguing for needless complexity here either. What I'm saying is that if we are going to provide _an_ interface for this, it should actually *be* an interface. "terms-of-service":"agreed" is not an interface. If the only possible use for it is to include exactly that string, then it's just useless verbiage, not an interface. We might as well just say that sending a request which would fail if you didn't include that string indicates acceptance - because doing anything else just wouldn't work anyway if acceptance isn't optional. That's the logical conclusion if pruning dead-wood is the goal here. > > while we would lose the ability to have explicit agreement to an explicit > > ToS. You say "most" CA's don't need that, but this change would ignore > > the needs of the 'few' who might, and the users who would prefer (or > > even have a hard requirement) that the ToS does not change without their > > explicit knowledge. > > We shouldn't engineer a more complex solution for some CA that "might" > need it without good evidence that they actually do. Sure, but I'm saying that as a user I _do_ want to declare explicitly what I am agreeing to. And if we're talking about WGLC in November, that doesn't leave a lot of time for most of the extant CAs to tell us what they do or don't need wrt to this. > > We might be able to trust that LE won't ever make some onerous change > > to their ToS 'silently' - but I'm not sure that applies broadly. > > If the problem is a service provider acting in bad faith with regards to > their ToS, that's not a problem we can solve with protocol design. We might not be able to "solve" it. All I'm asking for is that we don't _introduce_ it with a bad protocol design, that implies legally binding acceptance, to uncertain terms, with an ambiguously general nod and wink. > > My understanding of your original problem which prompted suggesting > > this change is that some clients required an additional command line > > option from the user to actually pass the "agreement" field. So they > > fell over when LE changed its ToS. > > There were several different failure modes. Any one of them can be > treated as a client coding error, but in total they indicate that the > existing protocol was over-complex and under-specified in this area. One > fix would be to specify more heavily how ToS upgrades should go. A > better fix, IMO, would be to simplify the protocol itself to avoid this > whole class of bugs. Could you outline at least a few of them, so we can see the specifics of what you are worried about repeating? Because I implemented this, using only common sense, without any statement from LE about if there'd ever be a ToS change, or how things should happen if there was - and in practice that wasn't a source of trouble. I don't think we need to specify how to handle ToS changes in much detail at all. The important part is that the local admin can be notified that the ToS for a CA they use _has_ changed, and that they can explicitly declare exactly which ToS revision they have agreed to. And we already have simple protocol mechanisms for that in the existing draft text. Everything else is outside of the protocol anyway (ie. how clients behave when a ToS change is seen, and what CAs insist on when they do change their ToS). And there's legitimate scope for both of those to have quite a wide range of choices which suit different people and organisations. I don't think you can solve that by 'simplifying' the protocol, but I do think that we can make that problem worse by oversimplifying, and replacing useful information with content-less verbiage, and making too many assumptions about what people "won't ever want to do". I'd rather we have a little flexibility here, than have 20 competing standards emerge because we simplified the protocol overzealously and fundamentally ruled out too many things too quickly. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
