[Cryptography-dev] TLS-API update

Glyph glyph at twistedmatrix.com
Sat May 3 21:58:08 CEST 2014


On May 3, 2014, at 12:33 PM, Christopher Armstrong <radix at twistedmatrix.com> wrote:

> - This made ClientSession and ServerSession identical, so I merged them into one class, “Session”.

Woot.  This was sticking out for me.

> I specifically want to call into question the existence of the “alert” method. I think it’s too low level for the common use case, and we should just relegate TLS alerts to an implementation detail. If necessary, we can add some contract to verify_callback to make e.g. certain exceptions raised translate to TLS alerts sent to the peer. Any thoughts?

If this is a library that is designed to expose the TLS specification to application code in a way which faithfully respects the spec's intent, then you can't relegate "alert" to an "implementation detail"; it's a part of the spec and therefore a part of the interface in some way.

If this is a library that is designed to provide transport security (which might also use, say, NaCl) and not particularly expose all of the TLS specification, then it should have a layer which faithfully exposes the TLS specification below it and then have an abstract API which might paper over things like alerts.

In either case you can't call an alert an implementation detail unless you are trying to construct a deliberately incomplete API. ;-)

And you can't just stuff it into verify_callback because alerts can be sent later in the stream than the handshake, right?

> Another thing is we need to figure out some more APIs around certificates, like what methods “Certificate” should have, and how we should allow the user to construct Certificates. (I need to spend some time looking at the new Python “pem” module). Any input here will help.

The 'pem' module is for splitting up strings in one particular format and thus would not be a great rubric for a generalized constructing/loading/saving API for certificates.  The thing you want to look at is the "Certificate" object in Twisted's API, which is what pem uses for building something that looks like an object.  Remember Twisted, it's a library you used to work on? :-)

In case I haven't been clear about this, I would very much like the stuff in twisted/internet/_sslverify.py to align as much as possible with the API being specified here.  First off, it would be great to get rid of as many OpenSSL-isms as possible, and secondly, the more that our existing implementation can be made to approximate this, the easier it should be for Twisted to get out of the business of doing TLS at all (eventually).

-g

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140503/d5627fe9/attachment-0001.html>


More information about the Cryptography-dev mailing list