[Python-Dev] frozenset C API?
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:
>>"""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
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
>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
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