Planning Your Public Key Infrastructure
Planning Your Public Key Infrastructure |
|
The certificate life cycle includes the following events:
You normally define the certificate life cycle to require periodic renewal of issued certificates. Issued certificates expire at the end of their lifetime and can be renewed in a cycle until revoked or expired, or until an issuing CA is unavailable. Each CA can issue certificates through several certificate renewal cycles until the CA approaches the end of its lifetime. At that time, the CA would either be retired because its keys are no longer useful, or the CA would be renewed with a new key pair.
You should define certificate life cycles that meet your business goals and security requirements. The life cycles you choose depend on various considerations, such as the following:
Length of private keys for CAs and issued certificates. In general, longer keys support longer certificate lifetimes and key lifetimes.
Security provided by the CSP. Typically, a hardware-based CSP is more difficult to compromise than a software-based CSP, and thus can support longer certificate lifetimes and key lifetimes.
Strength of the technology used for cryptographic operations. Some cryptographic technologies provide stronger security as well as support for stronger cryptographic algorithms. You can also use FORTEZZA Crypto Cards to provide stronger security than standard smart cards. Generally, cryptographic technology that is harder to break supports longer certificate lifetimes.
Security provided for CAs and their private keys. In general, the more physically secure the CA and its private key, the longer the CA lifetime.
Security provided for issued certificates and their private keys. For example, private keys stored on smart cards can be considered more secure than private keys stored as files on local hard disks because smart cards cannot be coerced to export the private key.
Risk of attack. The risk of attack depends on how secure your network is, how valuable the network resources protected by the CA trust chain are, and the cost of starting an attack.
How much trust you have for users of certificates. In general, lower trust requires shorter lifecycles and shorter key lifetimes. For example, you might trust temporary users less than normal business users, so you might issue temporary users' certificates with shorter lifetimes; you can also require stricter controls for renewal of temporary users' certificates.
The amount of administrative effort you are willing to devote to certificate renewal and CA renewal. For example, to reduce the administrative effort required to renew CAs, you can specify long, safe lifetimes for your certification trust hierarchies.
Give careful consideration to how long you want CAs and issued certificates and keys to be trusted. The longer the certificates and private keys are valid, the greater the risk and potential for a security compromise.
You should define certificate life cycles that realistically balance your business goals with your security requirements. Unrealistically short life cycles can result in excessive administrative efforts required to maintain the life cycles. Unrealistically long life cycles increase the risk of security compromises.
When you renew certificates using Microsoft CSP, you can also renew the certificate's key pair. In general, the longer the key pair is in use, the higher the risk of the key becoming compromised. You should establish maximum allowable key lifetimes and renew certificates with new key pairs before these limits are exceeded.
After you define a life cycle, you can change it later by renewing CAs, certificates, or keys at different periods than you originally specified. For example, if you later decide that the lifetime of the root CA places the CA at greater risk of compromise than you originally estimated, you can renew the CA chain and adjust the life cycle as necessary to mitigate risks.