Let's Encrypt support

[mithrandi]

This is in support of twisted/mantissa#40 but the Mantissa component of this is really minimal. Essentially, all Mantissa should be responsible for is providing an object that can:

1. Provide a list of hostnames to respond for.
2. Store a new certificate for a given hostname.
3. Provide a certificate for one of those hostnames on demand.

Interacting with Let's Encrypt requires 1 and 2, serving TLS via txsni requires 3, and the obvious relatedness of these tasks suggests they should be implemented by the same object.
3 is already provided by the mapping argument that SNIMap takes, so this raises a few questions:

• Should 1-3 all be part of the same interface, or should 1-2 be a separate interface?
• If they're a separate interface, should the interface be defined by txsni at all, or by a separate project?
• Should these be zope.interface.Interfaces, or just documentation?
• Even if the interface is defined in txsni, should the actual Let's Encrypt implementation be in txsni, or a separate project?

There's no particular reason the Let's Encrypt stuff needs to be in txsni itself, that just seems like a convenient place to put it: I guess it really depends on where @glyph wants it. If this does end up in txsni, then I'll break the work up into several branches for the independent bits, so this issue itself is more of a "master tracking issue".

[glyph]

This is absolutely something I'm interested in; thanks for writing it up.

[mithrandi]

I thought about it some more, and the MutableMapping interface (as Python calls it) is sufficient here; __iter__ to iterate certificates in the "store", and __setitem__ to insert / replace a certificate.

(EDIT: fix method name)

[glyph]

__setitem__ you mean?

[mithrandi]

Uh, yeah, that :)

[mithrandi]

Oops, there's not actually a Twisted implementation of the Let's Encrypt API yet (for some reason I thought letsencrypt-aws used Twisted, but it doesn't); I guess I'm going to have to implement txacme first.

[mithrandi]

txacme is a thing now, see that repo for further progress on that front. I'll come back here once that's done, to figure out how exactly the integration with txsni should work.

[mithrandi]

I'm now planning to add my own endpoint parsers in txacme, to make things simple. (I'll still be using SNIMap under the hood, though). Most of the other stuff I talked about in the description here is happening in txacme, instead; @glyph should we close this issue, or keep it open?

[glyph]

I'm inclined to say we should close it, although I'm not doing so immediately because it hinges on this one question: how would this be resolved, under your current understanding, @mithrandi ?

[mithrandi]

Almost all of the functionality I discussed originally is now provided in txacme. As far as integration goes, I had originally imagined that the txsni: endpoint parser might provide some ACME functionality, but the design I ended up with has a new le: parser which will just be provided by txacme itself. In fact, since txacme is depending on txsni, adding functionality to txsni that depended on txacme would result in a circular dependency.

We could keep this open until an actual txacme release happens, though? (I'm not quite there, but pretty close)

[glyph]

Feel free to close when txacme is released, then.

[mithrandi]

https://pypi.python.org/pypi/txacme 🎉 🎉 🎉