While ZOPE with Apache-SSL is certainly possible , I personally would prefer a more tightly coupled structure than the lightweight server to server protocols provide(such as the certificate if available of the client ) .
I'll probably step on a few toes, but since this is my background and what I did before I came to work for DC, I'll put some of this to rest for the "foreseeable future"... It is possible to get access to the entire certificate via CGI from both Apache and Netscape (I can't and would rather not speak of IIS), and therefore you can garner whatever pieces you need out of it. In addition, mod_ssl allows for a nice ability to grab pre-parsed sections of the certificate without having to implement ASN.1/BER, which my dear friends, is a Good Thing. ASN.1 makes perl look readable, and is vague in the utmost and pedantic in the extreme. (Yes, I know that's contradictory, but Anthony Baxter I'm sure would agree with his interactions with SNMP). In addition, "tight integration" in this context is being used to imply "more security" I believe, which is a red herring, and implies that we as a company, are more focused on the cryptographic implications of what we do. While I might have a background in cryptography, most people around here don't, nor do they want it. For more information please read: http://www.counterpane.com/whycrypto.html This is Bruce Schneier's quite lucid essay on why crypto is harder than it appears on the outset. I'm not sure I wish to dedicate my entire time and resources to focusing on this, I would rather find someone else who has done an excellent job and allow us to leverage our own unique capabilities. The second aspect would be performance, however, anyone who has dealt with SSL, much less client-certificates and the overhead of dealing with them, understands that these are not generally solutions for high-transaction situations. If they are, then you are getting involved in hardware cryptographic accelerators (IBM's ISCF, Crysalis, Rainbow, etc.) and these are a bag into and of themselves. This would be a rather nasty Pandora's box to open, having stepped into interoperability before with a previous employer. I have spent literally months debugging PKCS-11 interface issues that change between revs of hardware. Just don't go there :-)
Tight integration of the SSL-Crypto extention with the zserver would allow security/permission capatibilities to be set on objects based upon a closed verification chain via client certificates
Well, if you've violated the system integrity of any commercially available server (i.e. NT, UNIX, etc), then you've basically violated the chain of verification. So passing this information through CGI isn't that much less secure in the overall scheme of things. I would like to see this handled through a module, as it is better there than through ZServer.
If encryption and X609v3 are available then zope becomes a FAR more interesting possibility for ecommerce.
This is somewhat true, however, X.509 certificates are only in use in intranets at this point, and in some extranet applications. It is certainly not a dominant form of authentication at this point, nor probably will it be until some UI issues are resolved. Currently, there are divergent camps about how to deal with multiple authorities, and whether someone should have multiple certificates for different purposes, or if authority should be designated through arbitrary v3 extensions. This is a MAJOR ideological issue that is much harder than it seems. Today, 99.99% of e-commerce sites only require SSL integration, which we can accomplish today by using Netscape, Apache/SSL, Stronghold or IIS, and in fact we have several customers who use this exact situation. Integration with PKI is a speculative issue today.
And besides its on the TODO list for the Zserver...
It should be removed, and will be. I will categorically state that integration into ZServer is not on the horizon in any form of "near future" for both resource and export issues.
Pyhon SSL modules ARE available in source...
This is a non-issue.
the question is where and how...(and preferably offshore i.e. NON US developement).
Not today, not by us. If someone else wishes to do this, deal with all export (and import in some countries) issues, etc., and deal with the multitude of crypto issues which again, are not trivial, then they are more than welcome to do so. Our "roadmap" is based on integration with well know, well tested servers which implement SSL in a known way. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com