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

Reply via email to