Simon:  I wish I could offer guidance here, but I'm afraid that I too am
reading some of these openssl man pages for the first time.

I agree that writing to a temporary file would be bad.

Accepting file-like objects from python code would be nice, but isn't
really necessary.  Simple strings would suffice.  It's easy enough for
application code to read the strings from the appropriate files.  Of
course, the ssl module (or an underlying library) would need a way to
determine the data format within the strings.  Unfortunately, I didn't
notice an equivalent of SSL_CTX_use_PrivateKey_file() that accepts a
file's contents instead of its path.  SSL_CTX_use_RSAPrivateKey() looks
like the next best thing.

>much of the mechanism of a Certificate object is already there;
>perhaps adding an opaque Key object wouldn't be too bad."

That's encouraging.

From the openssl docs I've read so far, it looks like certificates and
keys have several formats and use patterns.  That seems to me like
another argument in favor of supporting separate Certificate and Key
objects, even if they're only minimally implemented to begin with.  In
other words, I don't imagine the presence of Certificate and Key objects
would muck up the ssl module's api.

In order to keep compatibility with socket.ssl, perhaps any new
certificate and key objects should be accepted as alternatives to the
existing certfile and keyfile args, but the latter should still be allowed?