Table of Contents
This appendix gives an over view of the current strategic direction of the OpenCA development. As all things it is liable to change, but this is the current thinking.
A statement from the OpenCA team to say that for a given server and database environment what is the expected volume of certificates. This is important for users planning installations.
This would allow for complex scripts to be written around the OpenCA environment, hopefully paving the way for future modifications. This would also lead to the posibility of XKMS, CMS, SOAP based clients.
This would inlcude a fully documented PERL API scripting interface.
Automation of regular operations like: CRL production, certificate signing. This is important in production environments where you do not want Operations staff to have to manually produce regular CRLs, etc.
To accommodate an on-line CA model. i.e. a user can request a certificate and in the same session get the requested cert back. This can be used for "free email certs" or in closed user groups where only certain people have access to the public interface. It may be that this would only work with CA root key in hardware, or a special CA user logged on on a secure terminal to give the environment access to the CA password. In addition to this, the CA may keep a log of the number of times it was accessed.
A high risk environment mode, which is based on a cd-rom or some similar write protected media, changeable configuration data and exchange data are hold on writeable media (like usb-based-hardware, maybe encryptable), and the ossupports something like se-linux or similar.
Audit of RA and CA operations to a tamper proof signed log. This is possibly a requirement to achive any form of accreditiation.
A function that ensures OpenCA is running in a "known" environment. Perhaps md5 signature creation (after installation) and run time validation.
When reaching the end of the CA certificate lifetime, there is a certain point after which no usable end entity certificates can be issued whose desired validity *fully* fits into the CA certificates validity.
OpenCA could introduce the idea of "certificate profiles" where a user "requests" once but gets a "Profile" of certificate types". Secure storage and recovery of encryption keys would be part of this mechanism. The start of this is in the new Batch processes in the form of the "Process".
A function to provide (optional) key backup and recovery.
Enhancing the existing management screens to allow management of certificate roles and extensions, access control settings and node management i.e. a front end to the OpenSSL config files.
Screens to allow users to renew their certificates, modify DN's etc.
The ability to allow a user to request a certificate and authenticate themselves the authentication token is then checked against an independent directory.
I frequently get lost in the system when trying to debug things, often I wonder what functions get executed by OpenCA, the CGI system seems very opaque to me (and I consider myself an experienced Perl hacker)
I have seen OpenCA report crude error messages on seemingly harmless error conditions. When checking the code it was often something like an uninitialized variable that was used to call a method on.