On 05:15 pm, [EMAIL PROTECTED] 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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
