[Python-Dev] frozenset C API?

[glyph at divmod.com]

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.