twisted.internet.interfaces.ISSLTransport should be complete enough to implement twisted.internet.ssl.Certificate.{peer, host}fromTransport in terms of it

New submission from exarkun <[email protected]>:

`Certificate.peerFromTransport` and `Certificate.hostFromTransport` provide an API for getting the `Certificate` object used by one side or the other of an SSL connection.  `ISSLTransport.getPeerCertificate` is a good method to use for `peerFromTransport`, since it is closer to the underlying SSL code and knows how to do what's needed.  There's no `ISSLTransport.getHostCertificate`, but one should probably be added.

Using `ISystemHandle` isn't as good as using `ISSLTransport`, since that pushes the requirement to know how SSL is implemented into the implementation of `Certificate` - this is further from the actual SSL implementation, which is bad, but even worse, it makes it harder to support different SSL implementations (eg, as might perhaps be used by different reactors): `Certificate` would have to know about all of them, instead of just knowing about `ISSLTransport`.

What's currently lacking in `ISSLTransport` is:

  * `getHostCertificate`
  * documentation about the object returned by `getPeerCertificate` - right now it's a pyOpenSSL X509 object.  We need to define the interface of this object, possibly wrapping the pyOpenSSL object in something else, so that other implementations of `ISSLTransport` know what they need to return.

This came up as part of #593, when I wasn't implementing `ISystemHandle` in the TLS protocol-level implementation.  I almost decided to change `Certificate` to use `ISSLTransport`, but since that would only be a partial fix, I decided to implement `ISystemHandle` in the new code, instead.  This worked fine, since the TLS implementation is still based on pyOpenSSL, so the same objects turn up.


----------
Type     : enhancement
Component: core
Keywords : 
Priority : low
Nosy     : 
----------
http://twistedmatrix.com/trac/ticket/3818