On Thu, Jul 07, 2016 at 06:27:48PM -0400, Richard Barnes wrote: > So to be blunt: You're saying that some of what we want could be achieved > by hacks within the existing model, rather than getting all of what we want > by changing the model :) > > I really think it's cleaner at this point to change the model. There's not > that much deployed code yet, so we should go ahead and get things right.
There are dozens of projects that will need to rework their code if we restructure the protocol, including most of these and probably a lot that aren't listed: https://letsencrypt.org/docs/client-options/ That means we do unforuntately face some pretty painful tradeoffs between trying to optimize the protocol for elegance vs forcing ACME servers to speak multiple protocol versions simultaneously vs avoiding disruption to developer and user populations. For that reason, I think we should strongly prefer solutions that preserve the existing semantics and flows through the protocol. That seems possible by having the new flow use new endpoints that strictly expand upon the existing ones, or by following Brad's approach and allowing the results we want with existing flows. Or perhaps both: aim to allow existing clients to get wildcards (if they can request authz for them and solve a new challenge type) and add /submit-csr as an endpoint that makes it easier to get through the existing flow in an efficient way. -- Peter Eckersley p...@eff.org Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
