Planning For Lost Keys: Key Archival And Recovery; Balancing Certificate Request Processing - Red Hat CERTIFICATE SYSTEM 8 - DEPLOYMENT Deployment Manual

5.1.2. Planning for Lost Keys: Key Archival and Recovery

One operation the CA cannot perform, though, is key archival and recovery. A very real scenario is
that a user is going to lose his private key — for instance, the keys could be deleted from a browser
database or a smart card could be left at home. Many common business operations use encrypted
data, like encrypted email, and losing the keys which unlock that data means the data itself is lost.
Depending on the policies in the company, there probably has to be a way to recover the keys in order
to regenerate or reimport a replacement certificate, and both operations require the private key.
That requires a DRM, the subsystem which specially archives and retrieves keys.
Figure 5.2. CA and DRM
The Data Recovery Manager stores encryption keys (key archival) and can retrieve those keys so that
the CA can reissue a certificate (key recovery). A DRM can store keys for any certificate generated by
Certificate System, whether it is done for a regular certificate or when enrolling a smart card.
The key archival and recovery process is explained in more detail in
Recovery Manager (DRM)".
NOTE
The DRM is intended for archival and recovery of private encryption keys only. Therefore,
end users must use a browser that supports dual-key generation to store their public-
private key pairs.

5.1.3. Balancing Certificate Request Processing

Another aspect of how the subsystems work together is load balancing. If a site has high traffic, then it
is possible to simply install a lot of CAs, as clones of each other or in a flat hierarchy (where each CA
is independent) or in a tree hierarchy (where some CAs are subordinate to other CAs); this is covered
Section 5.2, "Defining the Certificate Authority
more in
Planning for Lost Keys: Key Archival and Recovery
Section 2.1.4, "About the Data
Hierarchy".
57