Hi folks, I took the time to describe the procedure for automated CA rollover. I added the documentation to docs/guide/appendix/strategy.xml, but for convenience I am including the docs in this email.
I included requirements for multiple CA instances (aka External CAs) handles by one installation. This is a feature present in many commercial PKI products and should be included in OpenCA as well. When we are going to implement this stuff, it will come at no additional cost. For those who are interested in the proposed procedure please read the following carefully. I am quite confident that the description is accurate, but feel free to correct me... :-) I tried to be as unambigous as possible, making coding easier. Martin ------ 1.8. Automated CA rollover 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. 1.8.1. External and Internal CAs 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. 1.8.2. Request processing 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. Note Although a request may contain an External CA Identifier that makes it possible to select the responsible External CA for the request, the request cannot and must not contain an Internal CA Identifier. Consequently the responsible Internal CA is always automatically determined by the OpenCA system. 1.8.3. Dispatching requests to Internal CAs 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). 1.8.3.1. Rollover requirement 1: automatic consideration of CA validity 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. 1.8.3.2. Rollover requirement 2: request dispatch decision 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: 1.8.3.2.1. CRL issuance 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. 1.8.3.2.2. Certificate issuance 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. 1.8.3.2.3. Certificate revocation Determine the Internal CA that issued the certificate that is to be revoked. Dispatch the revocation request to this Internal CA. 1.8.3.2.4. Certificate renewal 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" ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ OpenCA-Devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/openca-devel