OpenSSL STATUS Last modified at
- ______________ $Date: 1998/12/31 12:52:23 $
+ ______________ $Date: 1999/02/10 09:47:05 $
DEVELOPMENT STATE
IN PROGRESS
- o Ben is folding in his patches
+ o Steve is currently working on:
+ X509 V3 extension code including:
+ 1. Support for the more common PKIX extensions.
+ 2. Proper (or at least usable) certificate chain verification.
+ 3. Support in standard applications (req, x509, ca).
+ 4. Documentation on how all the above works.
+ Next on the list is probably PKCS#12 integration.
+
+ o Mark is currently working on:
+ Folding in any changes that are in the C2Net code base that were
+ not in the original SSLeay-0.9.1.b release. Plus other minor
+ tidying.
+
+ o Ralf is currently working on:
+ 1. Support for SSL_set_default_verify_paths(),
+ SSL_load_verify_locations(), SSL_get_cert_store() and
+ SSL_set_cert_store() functions which work like their existing
+ SSL_CTX_xxx() variants but on a per connection basis. That's needed
+ to let us provide full-featured per-URL client verification in
+ mod_ssl or Apache-SSL.
+ 2. The perl/ stuff to make it really work the first time ;-)
+ 3. The new documentation set in PID format under doc/
+ 4. More cleanups to get rid of obsolete/old/ugly files in the
+ source tree which are not really needed.
NEEDS PATCH
OPEN ISSUES
+ o The Makefile hierarchy and build mechanism is still not a round thing:
+
+ 1. The config vs. Configure scripts
+ It's the same nasty situation as for Apache with APACI vs.
+ src/Configure. It confuses.
+ Suggestion: Merge Configure and config into a single configure
+ script with a Autoconf style interface ;-) and remove
+ Configure and config. Or even let us use GNU Autoconf
+ itself. Then we can avoid a lot of those platform checks
+ which are currently in Configure.
+
+ 2. The xxx.org -> xxx.h generation:
+ It's not obvious for which file xxx.org is the source.
+ Suggestion: Rename xxx.org to xxx.h.in (Autoconf style), this way
+ one sees that xxx.h.in is the input for xxx.h
+
+ Status: Mark +1
+
o The installation under "make install" produces a very
installation layout: $prefix/certs and $prefix/private dirs. That's
not nice. Ralf suggests to move the two certs and private dirs either
Status: Ralf +1 for both not installing the certs at all and
moving it to $prefix/etc/. +0 for $prefix/lib/
and $prefix/share.
+ Paul: why is it not nice?
+ Ralf: because it messes up the install dir when
+ $prefix is not a dedicated area like /usr/local/ssl.
+ When we move them to a standard subdir like
+ etc/ lib/ or share/ we don't mess up things
+ when $prefix is /usr or /usr/local, etc.
+ Additionally it makes package vendors life
+ easier....
o Support for Shared Libraries has to be added at least
for the major Unix platforms. The details we can rip from the stuff
Status: Ralf thinks we should both contact the author of Net::SSLeay
and look how much effort it is to bring Eric's perl/ stuff up
to date.
+ Paul +1
+
+ o The EVP and ASN1 stuff is a mess. Currently you have one EVP_CIPHER
+ structure for each cipher. This may make sense for things like DES but
+ for variable length ciphers like RC2 and RC4 it is NBG. Need a way to
+ use the EVP interface and set up the cipher parameters. The ASN1 stuff
+ is also foo wrt ciphers whose AlgorithmIdentifier has more than just
+ an IV in it (e.g. RC2, RC5). This also means that EVP_Seal and EVP_Open
+ don't work unless the key length matches the fixed value (some vendors
+ use a key length decided by the size of the RSA encrypted key and expect
+ RC2 to adapt).
+
+ WISHES
+
+ o Damien Miller:
+ "How about making the each of the locations compile-time defined. I
+ would like to (for example) put binaries in /usr/bin, configuration
+ data, certs and keys in /etc/openssl/certs and /etc/openssl/keys, etc.
+ This would also be a great boon to binary package makers. The
+ SSLeay-0.9.1b RPM already includes some patches which do some of this.
+ I can forward them if you wish."
- o Ralf has ported Stephen's pkcs12 program to OpenSSL (the
- ASN.1 stuff Eric recently changed :-( ), but needs some help from
- Stephen at two source locations. Stephen itself also has ported his
- internal pkcs12 0.53 version to OpenSSL, but thinks we still shouldn't
- incorporate it into OpenSSL because it needs more cleanups. Ralf still
- thinks pkcs12 should be incorporated better now than later because it's
- nasty to not have it in the core - one always has to install it
- manually and a lot of people use it. So, should we incorporate it?
- BTW, we have to be carefully because of the pkcs12 license: There are
- some things which don't match the OpenSSL license, so Stephen has to
- change it for us when we want to incorporate the code.
-
- Status: Ralf +1, Stephen -0
-