Table of Contents
This appendix gives an overview of the current strategic direction of the OpenCA development. As all things it is subject 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 in time after which no usable end entity certificates can be issued whose desired validity fully fits into the CA certificates validity.
To address this problem an automated CA Rollover is implemented. The basic idea is to have multiple issuing CAs (with overlapping certificate validity) that are logically responsible for the same set of certificates. OpenCA will automatically detect which CA to use for a given operation.
An OpenCA installation consists of the program installation, including the binaries, web frontends, configuration files, etc.
An OpenCA installation may provide one or more externally visible CA instances or External CAs. A unique External CA Identifier is assigned to each External CA that is used to distinguish between the individual instances. Each External CA provides its own independent name space in terms of profile, common name, serial number, access control etc. This makes it possible to run different and completely independent CAs in one single installation without having to install multiple program installations. Selection between instances for end users and administrator staff is delegated to either the web server running the CA installation (e. g. by using different URLs or port numbers for instance distinction) or may be performed by some kind of selection method on the CA login screen. An External CA (or CA instance) encompasses a complete OpenCA configuration set.
Each External CA may consist of an arbitrary number (zero or more) of Internal CAs. All these Internal CAs should be capable of issuing certificates for the namespace defined by the External CA. Internal CAs will usually use the same Certificate Profile and very similar configuration, but this is neither mandatory nor technically enforced by the OpenCA framework. In particular, each Internal CA uses its own CA certificate and private key. Each Internal CA is given a unique internal identifier that is used internally by OpenCA to distinguish between internal CAs. It is not allowed to change the internal identifier after it has been assigned to the Internal CA.
For convenience it is possible to assign symbolic names to each Internal or External CA. The symbolic name is only used for display purposes and may be changed at any time by the administrators. All references (database, configuration) to External and Internal CAs are only done by using the external and internal CA identifiers.
On startup the OpenCA system examines all External CAs that are configured. For each External CA OpenCA determines which Internal CAs belong to this CA instance and analyzes the corresponding Internal CA certificate. The validity information of each CA certificate is stored internally for later use by the CA request dispatcher.
In order to make CA rollover work, administrators must make sure that an Internal CA exists that is capable of taking over the certificate issuance duties of the expiring Internal CA. If no Rollover CA exists, the CA system will not be able to find a suitable candidate Internal CA for the requested operation and will stop working after the last Internal CA exceeds a certain point in time after which it is not possible to issue end entity certificates with the required validity.
In the following sections a request is any operation that must be performed by a CA, e. g. CRL generation, certificate issuance, certificate revocation or certificate renewal.
Whenever a CA operation is requested the OpenCA system first determines the External CA the request belongs to. The request should contain an indication of the External CA it should be applied to, e. g. when originating from a web frontend the CGI script will include information about the originating CA Instance in the request. This indication must be the External CA Identifier as defined above.
In some cases it is possible that requests arrive at the system without an explicit indication of the responsible External CA. To handle such cases it should be possible to configure a single External CA that should act as the default CA. If no default defined, incoming requests without an explicit reference to an External CA must be discarded. An error should be delivered to the requester if possible.
After the OpenCA system has identified the responsible External CA for a request it must determine the Internal CA that should process the request. All valid Internal CAs that are configured for an External CA are possible candidates for processing the request (unless they are explicitly disabled in the configuration).
Requests will only be processed by an Internal CA if this Internal CA is suitable for the requested operation. This means that an Internal CA whose validity is not a superset of the requested end entity certificate validity is not considered for request processing at all.
After determining the Internal CAs that are candidates for request processing, the system tries to identify which of the remaining CAs should actually process the request.
The handling is differs depending on the individual request type:
After a request for CRL issuance has been received for an External CA, the request is dispatched to all configured and operational Internal CAs for this External CA. This means that all CAs that are available should issue CRLs.
In order to determine the responsible Internal CA for a given certificate request the following algorithm is used:
Determine requested end entity certificate validity (NotBefore and NotAfter dates)
From all possible Internal CAs determine the ones whose CA certificate validity allow to issue the requested end entity certificate
From the remaining Internal CAs determine the one with highest NotBefore date
Dispatch the request to the Internal CA that was determined. Report an error if no possible CA candidate was found.
Determine the Internal CA that issued the certificate that is to be revoked. Dispatch the revocation request to this Internal CA.
The following section describes a proposal for certificate renewal (reissuance of a certificate for an end-entity that has been granted a certificate before). The actual decision if a certificate may be renewed depends on the policy for the External CA and should be configurable.
The following algorithm is proposed for certificate renewal:
Reject request if no previous certificate exists for the requested Common Name.
Reject request if already more than one valid certificate exists for the requested Common Name (allow a maximum number of two valid certificates for one single CN).
Determine the NotBefore and NotAfter date of the requested end entity certificate (proposed method: use NotAfter of existing certificate as NotBefore of renewal certificate. To determine the NotAfter date of the renewal certificate add default end entity validity period to NotAfter date of existing certificate)
Proceed with the algorithm outlined in "Cerficate Issuance"
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.
Sometimes it is difficult to figure out which functions are called by the system. Currently debugging is enabled in various configuration sections.
Sometimes OpenCA reports 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.
Document generated: 2005-08-05T17:53+0200