The initial goal in my mind would be to have transparent (or nearly so) SSL session management, but the X.509 manipulation and general crypto interface could wait until later. While they are both useful, the SSL side is the really critical part.
Which is of course exactly the goal of the existing socket.ssl support, primitive though it is. This was paid for in part by HP; their goal was to let urllib support the HTTPS protocol, nothing more, nothing less. And it does that well enough.
(Note that, alas, the DB-API never made it this far -- we still haven't been able to find the time to do the tedious work of moving the various database adapters in the core distribution. :-( )
Actually what this looks more like is not just SSL, but a "crypto" collection for Python, dependent on the excellent work in OpenSSL. I can start outlining some stuff if that would be a good start, though obviously if there's an existing library that could be integrated, that would be excellent.
I think it would be a big mistake to start from scratch. Remember the GUI SIG? PS. One issue with adding more crypto to Python could be US export issues. It's possible that new export limitations for crypto software are made law by a congress that doesn't understand the issues, and then the US Python distribution could be in trouble (even though our site in the the Netherlands, we build the distributions here in the US). Back at CNRI, we couldn't release the SSL wrappers, which don't contain any crypto code but enable linking with it, before an extensive and expensive legal review, and then we had to wait until after a certain date, at which some of the crypto export restrictions were lifted. --Guido van Rossum (home page: http://www.python.org/~guido/)