2.1.1. Certificate System Sub-systems
To meet the widest possible range of configuration requirements, the Certificate System permits independent installation of five separate subsystems, or managers, that play distinct roles:
A Certificate Manager (CM) functions as a root or subordinate CA. This subsystem issues, renews, and revokes certificates and generates certificate revocation lists (CRLs). It can also publish certificates, files, and CRLs to an LDAP directory, to files, and to an Online Certificate Status Protocol (OCSP) responder.
The CM can process requests manually (with agent action) or automatically (based on customizable profiles). Publishing tasks can only be performed by the CM.
The CM also has a built-in OCSP service, enabling OCSP-compliant clients to query the CM directly about the revocation status of a certificate that it has issued. In certain PKI deployments, it might be convenient to use the CM's built-in OCSP service, instead of an OCSM.
Because CAs can delegate some responsibilities to subordinate CAs, a CM might share its load among one or more levels of subordinate CMs.
Subsystems can also be cloned. All clones use the same keys and certificates as the master, which means that the master and clones essentially all function as a single CA. Many complex deployment scenarios are possible.
A Data Recovery Manager (DRM) oversees the long-term archival and recovery of private encryption keys for end entities. A CM or TPS can be configured to archive end entities' private encryption keys with a DRM as part of the process of issuing new certificates.
The DRM is useful only if end entities are encrypting data, using applications such as S/MIME email, that the organization may need to recover someday. It can be used only with client software that supports dual key pairs; two separate key pairs, one for encryption and one for digital signatures. It is also possible to perform server-side key generation using the TPS server when enrolling smart cards.
The DRM archives encryption keys. It does not archive signing keys, since archiving signing keys would undermine the non-repudiation properties of dual-key certificates.
An Online Certificate Status Manager (OCSM) works as an online certificate validation authority and allows OCSP-compliant clients to verify certificates' current status. The OCSM can receive CRLs from multiple CMs; clients then query the OCSM for the revocation status of certificates issued by all CMs. For example, in a PKI comprising multiple CAs (a root CA and many subordinate CAs), each CA can be configured to publish its CRL to the OCSM, allowing all clients in the PKI deployment to verify the revocation status of a certificate by querying a single OCSM.
An online certificate-validation authority is often referred to as an OCSP responder.
The Token Key Service (TKS) manages the master and transport keys required to generate and distribute keys for smart cards. The TKS provides security between tokens and the TPS because it protects the integrity of the master key and token keys.
The Token Processing System (TPS) acts as a registration authority for authenticating and processing smart card enrollment requests, PIN reset requests, and formatting requests from the Enterprise Security Client.