Certificates are associated with PKI, but Certificates are not the end of PKI. PKI is an enterprise service comprised of several layers of services that conspire to provide a coherent authentication and protection suite.
Public Key Certificates. Certificates ensure that the keys and identity of the bearer are valid by means of a third-party trust. CAs are people who and systems that create Certificates and bind them to the identified user. Certificates are a digitally signed collection of specific information. That information consists of the distinguished name of the user, the user’s public key, the lifetime of the Certificate and associated keys, and what the supported operations of the Certificate are. Certificates can be used to encrypt data, digitally sign data, or provide both. Given the implementation and support for Certificates within an organization, nearly anything is possible with Certificates. An example is W2K PKI and the use of certificates or anything from Encrypted File System (EFS) control and recovery to authenticating clients, servers, and domain controllers. The ability to securely align an entity with specific information represents unlimited possibilities in the information age.
Certificate Repository. A Certificate repository is where the Certificate information is maintained and verified. The repository can be a database such as Micro Active
Exhibit 4-4. Third-party trust
Certification Authority trust trust
Alice Bob
Directory by Microsoft or Novell’s Directory Services. The repository is a combination of services, databases, and directories to provide a distributed authentication environ- ment. The directory is typically LDAP compliant due to the various attributes of LDAP. LDAP is scalable, provides fast lookups and data retrieval, is an accepted standard, and works well with distributed environments.
Certificate Revocation (CRL). The most overlooked and underrated aspect of PKI is the Certificate revocation process. During the verification of a Certificate, there are several points of interest; of course, one of them is ensuring that the CA has not revoked the Certificate. If the Certificate has been revoked by the issuer, then trusting the Certificate should be avoided.
A Certificate revocation list is simply a list of the Certificates that the CA no longer supports or recognizes. As one can imagine, in the lifetime of a PKI solution, there will be many revoked Certificates. Managing the list and ensuring it is available for anyone attempting to validate a Certificate is paramount.
There are several reasons for revoking a Certificate: the validity time expired, the key was compromised, or employee dismissal.
Key Backup and Recovery. Certificate and key backup and recovery are necessary in the event the originals are lost or used and disposed. If a user loses a key or Certificate, and there is data encrypted with information, recovering the key can be very important. This is also important for a darker purpose. Information security is more than just fighting vulnerabilities; it includes ensuring the availability of data and ensuring its integrity. With the advent of encryption, there have been situations in which individuals have encrypted data and disposed of the keys. At that point, if there is no copy of the key for decryption, the data is lost. This is a reality that organizations must take into consideration; and therefore, a proper PKI solution must contain a key backup and recovery process.
Some people associate key backup with key escrow. A key escrow is where a third party, which was not involved with the creation of the Certificates or keys, is provided with a copy. Most people associate this process with the government and encryption laws and restrictions. A recovery and backup process on the issuing CA is necessary for proper enterprise security management. For that reason, the CA must maintain a backup. This is another reason for properly securing the CA system.
However, keys and Certificates used for signing purposes only are not backed up. The entire premise of digitally signing data is that no one else has a copy of the signing key. If the key is lost, a new one is simply issued and the user continues with the new keys. This has no effect on the availability of data, because signing keys cannot be used for encryption; as a result, there is no threat to the organization’s data.
Non-repudiation. Non-repudiation is when the user who signed the data cannot successfully deny signing that data. Similarly, a CA cannot deny issuing the CA. Non- repudiation includes that someone cannot deny involvement in a transaction. The entire process is established by the privacy of the signing key.
Automatic Update of Certificates and Key Pairs. Keys should not be used for extended periods of time. The longer the key is in use, the greater the exposure to
vulnerabilities. Periodic automatic update of keys and Certificates is the role of the PKI solution. Users should be unaware of the process and not be adversely affected by the process.
Key History. When keys are renewed, the keys that were replaced must be maintained for a period of time, due to the existence of data associated with the replaced keys. This is not the same as the backup and recovery of keys, which are geared toward the current keys being used. Key history is concerned with valid keys that have expired.
Cross-certification. Cross-certification extends certification domains beyond originat- ing organization. This allows a trusted Certificate from another domain to be used. As shown in Exhibit 4-5, CAs can establish a trust that will extend the capabilities of the Certificate from either of the domains to the other.
The process requires specific steps. Basically, the trusting CA must provide a verifi- cation key to the trusted CA to be signed. Once the verification key is signed, the trust is established (one-way in this example; if two-way trust is desired, execute the process again in reverse).
There are examples in which trust can be established between two individuals from different domains. This is called a direct trust, as detailed in Exhibit 4-6. Two users can establish a relationship without the involvement of the trust domain’s CAs.