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

Christopher Armstrong radix at twistedmatrix.com
Thu Sep 6 18:50:57 CEST 2007

On 9/5/07, Bill Janssen <janssen at parc.com> wrote:

> It's actually easier to do all or nothing. I'm tempted to just report > 'critical' extensions.

Simpler to provide them all, though I should note that the purpose of the information provided here is mainly for authorization/accounting purposes, not for "other" use of the certificate. If that's desired, they should pull the binary form of the certificate (there's an interface for that), and use M2Crypto or PyOpenSSL to decode it in general. This certificate has already been validated; the issue is how to get critical information to the app so it can make authorization decisions (like subjectAltName when the subject field is empty). Reporting non-critical extensions like "extended key usage" is nifty, but seems pointless.

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. """

This is from an explanation of how to do hostname verification when doing HTTPS requests. HTTPS clients MUST do this in order to be compliant. Is an HTTPS client not in your list of use cases?

"""In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known to the client. If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks."""

I really don't understand why you would not expose all data in the certificate. It seems totally obvious. The data is there for a reason. I want the subjectAltName. Probably other people want other stuff. Why cripple it? Please include it all.

-- Christopher Armstrong International Man of Twistery http://radix.twistedmatrix.com/ http://twistedmatrix.com/ http://canonical.com/

More information about the Python-Dev mailing list