There are as many as five ways to specify the locations of various significant
files to openSSL:
1. Command line arguments to ca and req,
2. Configuration file entries for ca and req,
3. Environment variable values to ca, req and the X509 subsystem,
4. Programmatic defaults for ca, req and the X509 subsystem,
5. Explicit application settings for the X509 subsystem.
Broadly, there are two distinct configurable components to openSSL:
* Certificate maintenance (ca and req) which uses 1, 2, 3 and 4 above.
* Certificate use (X509 subsystem) which uses 5, 3 and 4 above.
It seems as if the two major subsystems were written at different times, by
different people, and the integration of 1-2 with 3-5 above was never fully
attempted.
The result is that a user who is also a CA has too many possibly conflicting
ways to specify the characteristics of their CA.
Problems:
* It is impossible to make use of the generality of 1 and 2 when one is
dealing with clients which will prefer 5-3, and may not provide any way to
externally specify locations, and almost certainly will not provide a means of
specifying them in accord with 1 and 2 (necessitating error-prone duplication
of any values entered into 1 and 2.)
* Methods 5-3 above have the advantage of speed and relative simplicity of
implementation, however they do not have sufficient power to represent a fully
configurable CA for the purpose of certificate maintenance.
* Since the purpose of 1 and 2 could only be to ease configuration, and
since 1 and 2 cannot readily configure certificate use, they fail in their
general purpose by being inaccessible to certificate use.
It's necessary to decide upon the role of methods 1 and 2 above:
Method 2 is used to define some things which can never be defined by another
of the existing methods (such as details of X509 extensions, CA policies and
Distinguished Name values) but which are of no interest to certificate use
applications.
Methods 1 and 2 are also used to define the CA's directory structure in a
manner which cannot be communicated to certificate use applications.
Either Methods 1 and 2 should permit no such definition, and be hard-coded
(which would not work, as the certificate use applications can change this
definition ad lib.)
Or Method 2 access should be provided to certificate use applications.
Suggestions:
* The client and server applications (certificate use applications relying
on the X509 subsystem) should be provided with a higher level API which allows
locations to be specified by reference to the configuration file (method 2
above.)
* Client and Server examples (and other certificate use applications) should
be provided which utilise the new higher level API.
* The interfaces 1 and 2 above should be made more regular, removing
anomalies such as the inability to specify $ca::serial from the command line,
when one can specify the $ca::new_certs_dir.)
* ::oid_file's contents should be made a configuration Section, and the file
should disappear.
Colin.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
