[Python-Dev] frozenset C API? (original) (raw)

glyph at divmod.com glyph at divmod.com
Thu Sep 6 19:45:18 CEST 2007

On 05:15 pm, janssen at parc.com wrote:

RFC 2818

"""If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. """

Yes, subjectAltName is a big one. But I think it may be the only extension I'll expose. The issue is that I don't see a generic way of mapping extension X into Python data structure Y; each one needs to be handled specially. If you can see a way around this, please speak up!

Well, I can't speak for Chris, but that will certainly make me happier :).

I intend to "include it all", by giving you a way to pull the full DER form of the certificate into Python. But a number of fields in the certificate have nothing to do with authorization, like the signature, which has already been used for validation. So I don't intend to try to convert them into Python-friendly forms. Applications which want to use that information already need to have a more powerful library, like M2Crypto or PyOpenSSL, available; they can simply work with the DER form of the certificate.

When you say "the full DER form", are you simply referring to the full blob, or a broken-down representation by key and by extension?

This begs the question: M2Crypto and PyOpenSSL already do what you're proposing to do, as far as I can tell, and are, as you say, "more powerful". There are issues with each (and issues with the GNU TLS bindings too, which I notice you didn't mention...)

Speaking of issues, PyOpenSSL, for example, does not expose subjectAltName :).

This has been a long thread, so I may have missed posts where this was already discussed, but even if I'm repeating this, I think it deserves to be beaten to death. Why are you trying to bring the number of (potentially buggy, incomplete) Python SSL bindings to 4, rather than adopting one of the existing ones and implementing a simple wrapper on top of it? PyOpenSSL, in particular, is both a popular de-facto standard and almost completely unmaintained; python's standard library could absorb/improve it with little fuss.

More information about the Python-Dev mailing list