Re: [Python-Dev] frozenset C API?
> I very much doubt that, at least if you want to report decoded > information. Conceptually, there is an infinite number of extensions, > and when you are done, I can show you lots of certificates that > have extensions that you don't support. I'm not going to decode anything; I'm just using the OpenSSL functionality and providing whatever it provides. > Hmm. In this certificate, none of the extensions you report have been > marked critical; they are all non-critical. That's what I meant by "simpler to show everything". > Also, you are reporting the logotype (1.3.6.1.5.5.7.1.12) incorrectly; > it's defined in RFC 3709, and it's definitely not an empty string in > the certificate you've used. Yes, I see. I'll poke at the OpenSSL code harder :-). Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
On 9/5/07, Bill Janssen <[EMAIL PROTECTED]> 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/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> I really don't understand why you would not expose all data in the > certificate. You mean, providing the entire certificate as a blob? That is planned (although perhaps not implemented). Or do you mean "expose all data in a structured manner". BECAUSE IT'S NOT POSSIBLE. Sorry for shouting, but people don't ever get the notion of "extension". > 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. That's not possible. You can get the whole thing as a blob, and then you have to decode it yourself if something you want is not decoded. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> 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! > 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. 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. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
By the way, I think the hostname matching provisions of 2818 (which is, after all, only an informational RFC, not a standard) are poorly thought out. Many machines have more hostnames than you can shake a stick at, and often provide certs with the wrong hostname in them (usually because they have no way to determine what the *right* hostname is, from inside that machine). Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
On 05:03 pm, [EMAIL PROTECTED] wrote: >>I really don't understand why you would not expose all data in the >>certificate. > >You mean, providing the entire certificate as a blob? That is planned >(although perhaps not implemented). > >Or do you mean "expose all data in a structured manner". BECAUSE >IT'S NOT POSSIBLE. Sorry for shouting, but people don't ever get the >notion of "extension". "structure" is a relative term. A typical way to deal with extensions unknown to the implementation is to provide ways to deal with the *extension-specific* parts of the data in question, c.f. http://java.sun.com/j2se/1.4.2/docs/api/java/security/cert/X509Extension.html Exposing the entire certificate object as a blob so that some *other* library could parse it *again* seems like just giving up. However, as to the specific issue of subjectAltName which Chris first mentioned: if HTTPS isn't an important specification to take into account while designing an SSL layer for Python, then I can't imagine what is. subjectAltName should be directly supported regardless of how it deals with unknown extensions. >>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. >That's not possible. You can get the whole thing as a blob, and then >you have to decode it yourself if something you want is not decoded. Something very much like that is certainly possible, and has been done in numerous other places (including the Java implementation linked above). Providing a semantically rich interface to every possible X509 extension is of course ridiculous, but I don't think that's what anyone is actually proposing here. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> 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? The full blob. > 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". I'm trying to give the application the ability to do some level of authorization without requiring either of those packages. Like being able to tell who's on the other side of the connection :-). Right now, I think the right fields to expose are "subject" (I see little point to exposing "issuer"), "notAfter" (you're always guaranteed to be after "notBefore", or the cert wouldn't validate, so I see little point to exposing that, but "notAfter" can be used after the connection has been established), subjectAltName if present, and perhaps the certificate's serial number. I don't see how the other fields in the cert can be profitably used. Anything else you want, you can pull over the DER blob and look into 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. Good idea, go for it! A full wrapper for OpenSSL is beyond the scope of my ambition; I'm simply trying to add a simple fix to what's already in the standard library. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
On 9/6/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > You mean, providing the entire certificate as a blob? That is planned > (although perhaps not implemented). > > Or do you mean "expose all data in a structured manner". BECAUSE > IT'S NOT POSSIBLE. Sorry for shouting, but people don't ever get the > notion of "extension". > > > 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. > > That's not possible. You can get the whole thing as a blob, and then > you have to decode it yourself if something you want is not decoded. Sorry, I guess I thought it was obvious. Please let me get at the bytes of just the unknown-to-ssl-module extension without forcing me to write an entire general ASN.1 certificate parser or use another (incomplete) one. Many extensions have simple data in them that is trivial to parse alone. -- Christopher Armstrong International Man of Twistery http://radix.twistedmatrix.com/ http://twistedmatrix.com/ http://canonical.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Google spreadsheet to collaborate on backporting Py3K stuff to 2.6
I've transferred everything from my spreadsheet to Neal's. On 9/5/07, Brett Cannon <[EMAIL PROTECTED]> wrote: > Neal, Anthony, Thomas W., and I have a spreadsheet that was started to > keep track of what needs to be done in what needs to be done in 2.6 > for Py3K transitioning: > http://spreadsheets.google.com/pub?key=pCKY4oaXnT81FrGo3ShGHGg . I am > opening the spreadsheet up to everyone so that others can help > maintain it. > > There is a sheet in the Python 3000 Tasks spreadsheet that should be > merged into this spreadsheet and then deleted. If anyone wants to > help with that it would be great (once something has been moved from > "Python 3000 Tasks" to "Python 2 -> 3 transition" just delete it from > "Python 3000 Tasks"). > > Because Neal created this spreadsheet he is the only one who can open > editing to everyone. If you would like to have edit abilities to the > spreadsheet just reply to this email saying you want an invite and I > will add you manually (and if you want a different address added just > say so). > > -Brett > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python access to data fields of SSL connection peer certificate
After a great deal of discussion, under the Subject line of "frozenset
C API?" (you may have missed it :-), I'm coming to the conclusion that
in revealing the fields of an SSL certificate, less is more.
>From one of the messages in that thread:
I'm trying to give the application the ability to do some level of
authorization without requiring either of those packages. Like being
able to tell who's on the other side of the connection :-). Right
now, I think the right fields to expose are
"subject" (I see little point to exposing "issuer"),
"notAfter" (you're always guaranteed to be after "notBefore", or the
cert wouldn't validate, so I see little point to exposing that, but
"notAfter" can be used after the connection has been established),
subjectAltName if present,
and perhaps the certificate's serial number.
Remember that the cert has already been validated, so I don't see how
the other fields in the cert can be profitably used for authorization
and/or accounting, which is the purpose of this interface. Anything
else you want, you can pull over the DER blob and look into it with
some other crypto package; I'll provide a way to pull the full binary
form of the certificate into Python as a bytes string (as soon as the
bytes API gets backported into the trunk).
Under those rules, the samples in the current documentation would look
like
{'notAfter': 'May 8 23:59:59 2009 GMT',
'serialNumber': '6A4AC31B3110E6EB48F0FC51A39A171F',
'subject': ((('serialNumber', u'2497886'),),
(('1.3.6.1.4.1.311.60.2.1.3', u'US'),),
(('1.3.6.1.4.1.311.60.2.1.2', u'Delaware'),),
(('countryName', u'US'),),
(('postalCode', u'94043'),),
(('stateOrProvinceName', u'California'),),
(('localityName', u'Mountain View'),),
(('streetAddress', u'487 East Middlefield Road'),),
(('organizationName', u'VeriSign, Inc.'),),
(('organizationalUnitName', u'Production Security Services'),),
(('organizationalUnitName',
u'Terms of use at www.verisign.com/rpa (c)06'),),
(('commonName', u'www.verisign.com'),))}
and
{'notAfter': 'Feb 16 16:54:50 2013 GMT',
'serialNumber': 'FFAA4ADBF570818D',
'subject': ((('countryName', u'US'),),
(('stateOrProvinceName', u'Delaware'),),
(('localityName', u'Wilmington'),),
(('organizationName', u'Python Software Foundation'),),
(('organizationalUnitName', u'SSL'),),
(('commonName', u'somemachine.python.org'),))}
The server cert at https://www.dcl.hpi.uni-potsdam.de/ would look like
{'notAfter': 'Mar 17 13:02:27 2008 GMT',
'serialNumber': '2567F16800030678',
'subject': ((('countryName', u'DE'),),
(('stateOrProvinceName', u'Brandenburg'),),
(('localityName', u'Potsdam'),),
(('organizationName', u'Hasso-Plattner-Institut'),),
(('organizationalUnitName', u'Operating Systems & Middleware'),),
(('commonName', u'www.dcl.hpi.uni-potsdam.de'),)),
'subjectAltName': ('DNS:www.dcl.hpi.uni-potsdam.de',
'DNS:www',
'DNS:dfw',
'DNS:dfw.dcl.hpi.uni-potsdam.de',
'IP Address:141.89.224.164')}
Thanks to Martin for suggesting it.
Bill
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 362: Signature objects
Neal Becker over on python-3000 said that the Boost people could use this. Figured it was time to present it officially to the list to see if I can get it added for 2.6/3.0. The implementation in the sandbox works in both 2.6 and 3.0 out of the box (no 2to3 necessary) so feel free to play with it. - Abstract Python has always supported powerful introspection capabilities, including that for functions and methods (for the rest of this PEP the word "function" refers to both functions and methods). Taking a function object, you can fully reconstruct the function's signature. Unfortunately it is a little unruly having to look at all the different attributes to pull together complete information for a function's signature. This PEP proposes an object representation for function signatures. This should help facilitate introspection on functions for various uses (e.g., decorators). The introspection information contains all possible information about the parameters in a signature (including Python 3.0 features). This object, though, is not meant to replace existing ways of introspection on a function's signature. The current solutions are there to make Python's execution work in an efficient manner. The proposed object representation is only meant to help make application code have an easier time to query a function on its signature. Signature Object The overall signature of an object is represented by the Signature object. This object is to store a `Parameter object`_ for each parameter in the signature. It is also to store any information about the function itself that is pertinent to the signature. A Signature object has the following structure attributes: * name : str Name of the function. This is not fully qualified because function objects for methods do not know the class they are contained within. This makes functions and methods indistinguishable from one another when passed to decorators, preventing proper creation of a fully qualified name. * var_args : str Name of the variable positional parameter (i.e., ``*args``), if present, or the empty string. * var_kw_args : str Name of the variable keyword parameter (i.e., ``**kwargs``), if present, or the empty string. * var_annotations: dict(str, object) Dict that contains the annotations for the variable parameters. The keys are of the variable parameter with values of the annotation. If an annotation does not exist for a variable parameter then the key does not exist in the dict. * parameters : list(Parameter) List of the parameters of the function as represented by Parameter objects in the order of its definition (keyword-only arguments are in the order listed by ``code.co_varnames``). * bind(\*args, \*\*kwargs) -> dict(str, Parameter) Create a mapping from arguments to parameters. The keys are the names of the parameter that an argument maps to with the value being the value the parameter would have if this function was called with the given arguments. The Signature object is stored in the ``__signature__`` attribute of a function. When it is to be created is discussed in `Open Issues`_. Parameter Object A function's signature is made up of several parameters. Python's different kinds of parameters is quite large and rich and continues to grow. Parameter objects represent any possible parameter. Originally the plan was to represent parameters using a list of parameter names on the Signature object along with various dicts keyed on parameter names to disseminate the various pieces of information one can know about a parameter. But the decision was made to incorporate all information about a parameter in a single object so as to make extending the information easier. This was originally put forth by Talin and the preferred form of Guido (as discussed at the 2006 Google Sprint). The structure of the Parameter object is: * name : (str | tuple(str)) The name of the parameter as a string if it is not a tuple. If the argument is a tuple then a tuple of strings is used. * position : int The position of the parameter within the signature of the function (zero-indexed). For keyword-only parameters the position value is arbitrary while not conflicting with positional parameters. The suggestion of setting the attribute to None or -1 to represent keyword-only parameters was rejected to prevent variable type usage and as a possible point of errors, respectively. * has_default : bool True if the parameter has a default value, else False. * default_value : object The default value for the parameter, if present, else the attribute does not exist. This is done so that the attribute is not accidentally used if no default value is set as any default value could be a legitimate default value itself. * keywor
Re: [Python-Dev] Google spreadsheet to collaborate on backporting Py3K stuff to 2.6
Brett Cannon wrote: > Neal, Anthony, Thomas W., and I have a spreadsheet that was started to > keep track of what needs to be done in what needs to be done in 2.6 > for Py3K transitioning: > http://spreadsheets.google.com/pub?key=pCKY4oaXnT81FrGo3ShGHGg . I am > opening the spreadsheet up to everyone so that others can help > maintain it. > > There is a sheet in the Python 3000 Tasks spreadsheet that should be > merged into this spreadsheet and then deleted. If anyone wants to > help with that it would be great (once something has been moved from > "Python 3000 Tasks" to "Python 2 -> 3 transition" just delete it from > "Python 3000 Tasks"). > > Because Neal created this spreadsheet he is the only one who can open > editing to everyone. If you would like to have edit abilities to the > spreadsheet just reply to this email saying you want an invite and I > will add you manually (and if you want a different address added just > say so). I would like an invite. Thanks. -Travis ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
