Lesson 5: Understanding Certificate Life Cycle and Key Management

Lesson 5: Understanding Certificate Life Cycle and Key Management

The certificate life cycle defines the processes by which a CA requests, issues, revokes, renews, and audits certificates. The CA that issues a certificate defines what the certificate life cycle is. Key management involves determining how keys are stored and whether key management is centralized or distributed.


After this lesson, you will be able to

  • Explain what a key life cycle is

  • Identify the stages of a key life cycle

  • Explain what key management is

Estimated lesson time: 10 minutes


Key Life Cycle

For keys to be effective there must be a mechanism in place to track and manage keys, remove keys when necessary, and validate that a key is still viable. You must secure keys throughout the key life cycle. The key life cycle of a certificate can be broken into five distinct stages, as discussed in the following sections.

Certificate Enrollment

Certificate enrollment procedures vary, but typically users requesting certificates from a CA initiate a request. This is a cooperative process between a user (or a user's PKI software, such as an e-mail or Web browser application) and the CA. The enrollment request contains the public key and enrollment information. Once a user requests a certificate, the CA verifies information based on its established policy rules, creates the certificate, posts the certificate, and then sends an identifying certificate to the user.

Certificate Distribution

Certificate distribution occurs when the CA distributes the certificate to the user. This is considered a separate process because it might require management intervention from the CA. During this stage, the CA sets policies that affect the use of the certificate.

Certificate Validation

When a certificate is used, the certificate status is checked to verify that the certificate is still operationally valid. (Certificate validation is also know as status checking.) During the validation process, the CA checks the status of the certificate and verifies that the certificate is not on a CRL. Applications can also check on the status of certificates before they are used, if configured to do so. Currently, few applications automatically check for certificate revocation status due to the overhead involved in contacting the CRL distribution point.

Certificate Revocation

A certificate issued by a CA includes an expiration date that defines how long the certificate is valid. If a certificate needs to be revoked before that date, the CA can be instructed to add the certificate to its CRL. Reasons a certificate might need to be revoked include the certificate being lost or compromised, or the person the certificate was issued to leaving the company. When a certificate is revoked, the CA administrator must supply a reason code. The revocation codes are as follows:

  • Unspecified reason (0)

  • Private key compromise (1)

  • CA compromise (2)

  • Certificate user's affiliation changed (3)

  • Certificate or private key has been superseded by a new certificate or private key (4)

  • The issuing CA is no longer in operation (5)

  • The certificate has been placed on hold (6)

  • CA has withdrawn the certificate user's privileges to use the certificate or private key (9)

  • AIA compromise (10)

PKI-enabled applications are configured to check CAs for their current CRL, and do not operate if they cannot verify that the certificate has not been added to the CRL.

M of N control can be used to manage certificate revocation. Using M of N, you can specify that two different managers are needed to perform certificate revocation. This is very similar to the safeguard added to firing a nuclear missile, which requires two different keys (held by two different people) to activate and fire a missile.

Certificate Renewal

When a certificate reaches its expiration date, if the certificate is allowed to be renewed, a user can ask the CA to renew the certificate. This might happen automatically, or it might require user intervention. When renewing a certificate you must choose whether or not to generate new public and private keys.

Certificate Destruction

When a certificate is no longer in use, the certificate and any backup copies or archived copies of the certificate should be destroyed, along with the private key associated with the certificate. This helps ensure that the certificate is not compromised and used.

Certificate Auditing

The CA performs certificate auditing, and the process varies depending on the CA and the management tools available to it. Certificate auditing involves tracking the creation, expiration, and revocation of certificates. In certain instances, it can also track each successful use of a certificate.

Key Management

One of the concerns with keys is that someone will break the encryption and compromise a key. Unless you are using an encryption algorithm that is known to be weak, chances are much better that the attack will come from the key being compromised due to poor key management rather than the encryption being compromised. To make sure that your encryption solution is not compromised, you must make sure the encryption used is strong, but also ensure the key management is done in a secure manner.

Read more about preferred key management techniques in, "Key Management Guidelines (Workshop Document)" which can be found on the NIST Web site at http://csrc.nist.gov/encryption.

Before a key is created and distributed, you must determine whether the key will be stored with a software solution or hardware solution, and whether centralized or distributed key management will be used.

Software Storage

With software storage of an archived key, the key can be stored on a floppy disk or other type of removable media and placed in a safe or electronic vault. When you need to provide a user with a key, you can copy the key to a floppy disk and use the copy of the key to perform the operation. When the key is in use, it is loaded into active memory on the computer. To ensure the integrity of the key, it can be stored in an approved cryptographic module, an approved and properly configured operating system, a secured, limited-access environment, or split into multiple components. When you are finished using the copy of the private key, you must destroy the media it was copied to in a secure manner. With this type of storage, distribution is relatively simple and cost effective, but it is also somewhat easier to compromise than a hardware solution.

Hardware Storage

With hardware storage of a key, the key is placed on a hardware storage medium, such as a smart card or hardware security module (HSM). Additionally, HSMs also generate the keys on the hardware device to prevent the need to transmit the private key over a network connection or other medium. When you need to provide a user with a key, you program the smart card with the key and give the key to the user. With this type of storage, distribution requires you to distribute the smart card to the user and requires that the computers that are used be equipped with smart card readers. This is a secure way to store keys and is difficult to compromise, but it requires specialized equipment and is more costly than the software storage solution.

Centralized Key Management

With centralized key management, one group controls all of the CAs in the organization. This has many advantages when it comes to security, both physical and logical, because you can provide a single CA management infrastructure and a reliable key distribution system that can be used by the entire organization, rather than maintaining many such points. Using a centralized key management solution can be less efficient than a decentralized key management solution, but will be more secure.

Decentralized Key Management

With decentralized key management, you create your own key management and distribution solution. It is your responsibility to maintain secure keys that are not compromised and maintain a CRL on your CAs. For a large number of certificates that are used only by your company, this might be a cost-effective key management solution. In a decentralized key management model, there is a root CA, several subordinate CAs, and several issuing CAs. Collectively, they are called a CA hierarchy. The root CA is the top of the hierarchy and is only used to issue certificates for the subordinate CAs. The subordinate CAs are created for each area of the organization. For example, you might have a subordinate CA for the finance department, IT department, and research department. Each subordinate CA creates certificates used to create issuing CAs, which are usually created for use with a specific application, such as the e-mail CA and the Web server CA. Thus each group in the organization is responsible for managing its own certificates. Because many groups will use management CAs, decentralized management is less secure than centralized management, but more efficient.

Key Recovery

When a key is lost or corrupted, the data that is encrypted is no longer accessible. To recover access to that data, a key recovery technique must be used. Your organization should have a key recovery process in place to recover lost keys.

Key Escrow

One way to perform key recovery is known as key escrow. With key escrow, you split a decryption key into one or several parts and distribute these parts to escrow agents or trustees. To recover, the trustees can use their portion of the key to either to reconstruct the missing key or decrypt the communications. Key escrow is rarely implemented because of the privacy concerns that the key escrow agent will use the escrowed key.

Key Encapsulation

With key encapsulation, you encrypt data in a communication with a session key and encrypt that session key with a trustee's public key. The encrypted session key is sent with the encrypted communication, and the trustee is able to decrypt the communication when necessary.

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson and then try the question again. Answers to the questions can be found in Appendix A, "Questions and Answers."

  1. Match each portion of the certificate life cycle with the answer that best describes it.

    1. Enrollment

    2. Distribution

    3. Validation

    4. Revocation

    5. Renewal

    6. Destruction

    7. Auditing

    1. CA distributes the CA to the user

    2. Involves tracking the creation, expiration, and revocation of certificates

    3. A request is initiated by users requesting certificates from a CA

    4. Occurs when a certificate reaches the expiration date

    5. CA adds the certificate to its certificate revocation list

    6. Verifying that the signature is valid, that a trusted CA has issued the certificate, that the certificate can be used for its intended purpose, and determining if the certificate has been revoked.

    7. The process of deleting the certificate after it has been published on the CRL.

Lesson Summary

  • The key life cycle of a certificate is broken into seven distinct stages: certificate enrollment, certificate distribution, certificate validation, certificate revocation, certificate renewal, certificate destruction, and certificate auditing.

  • During certificate enrollment, a user requests a certificate from a CA.

  • Once the CA is satisfied with the credentials presented by the user requesting the certificate, the CA distributes the certificate to the user.

  • If anything occurs before the expiration of the certificate that warrants the cancellation of the certificate, it is added to the CA's certificate revocation list (CRL).

  • If the certificate is not revoked and reaches the expiration date, it can be renewed.

  • To better manage and control certificates, CAs track various events, such as creations, revocations, renewals, and in some cases, successful usage.



Security+ Certification Training Kit
Security+ Certification Training Kit (Pro-Certification)
ISBN: 0735618224
EAN: 2147483647
Year: 2002
Pages: 55

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net