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. > 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. > 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. > 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. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
