Cryptography for Network and Information Security

Certification Authorities in the Enterprise

Most digital certificates in use today for open network communication on the Internet are obtained from commercial CAs, which follow a number of standard practices and processes. However, an increasing number of organizations are beginning to deploy certificate services to implement CAs for issuing certificates on their intranets.

Windows 2000 includes Certificate Services, which you can deploy to create CAs in your enterprise. Various third-party vendors also provide certificate service products you can use to deploy CAs in your enterprise. For more information about Windows 2000 Certificate Services, see "Windows 2000 Certificate Services and Public Key Infrastructure" in this book. For more information about a third-party certificate service product, contact the specific vendor.

Services Provided by Certification Authorities

The role and function of CAs are basically the same, whether on an intranet or on the Internet. CAs perform the following basic services during the certificate lifecycle:

Process certificate requests to verify the identity of the requester and then issue a certificate that is prepared according to the policy for that CA.
Manage the certificate audit trail from the enrollment of the certificate to its expiration or revocation.
Renew certificates before they expire.
Revoke certificates as necessary.
Maintain and publish certificate revocation lists (CRLs).

Certificate Policies and Certification Authority Practices

A certificate policy states your organization's requirements for certificates, such as public key lengths, certificate lifetimes, and uses for certificates. A Certificate Practice Statement (CPS) specifies the practices that the CA employs to issue and manage certificates to meet your certificate policies. A CPS also describes the CA's criteria and process for validating and approving certificate requests, revoking certificates, and publishing CRLs.

A commercial CA commonly publishes its CPS on its public Web site, so anyone can read the CPS to find out what practices the CA follows to issue various types of certificates. For example, a CPS might explain that the CA issues a basic type of certificate after it verifies the requester's e-mail address. For software publisher certificates, however, the CA conducts a thorough background check and requires certain collaborating evidence to verify the identity of requesters. Based on the CPS, you might choose to have low trust for basic certificates, but high trust for software publisher certificates issued by that CA.

Certificate policies can include the following types of information:

Purposes for which the certificate can be used (user authentication, digital signing of software, encrypted e-mail, and so forth).
Private key management requirements, such as requiring storage on smart cards or other hardware devices.
Whether the private key can be exported.
Requirements for users of the certificates, including what users must do in case their private key is lost or compromised.
Requirements for certificate enrollment and renewal.
Certificate lifetime.
Cryptography algorithms to be used.
Minimum length of the public key and private key set.

A CPS can include the following types of information:

Positive identification of the CA (including CA name, server name, and DNS address).
Certificate policies that are implemented by the CA and the certificate types that are issued.
Policies, procedures, and processes for issuing and renewing certificates.
Cryptography algorithms and key length used for the CA certificate.
Lifetime of the CA certificate.
Physical, network, and procedural security of the CA.
The certificate lifetime of each certificate issued by the CA.
Policies for revoking certificates, including conditions for certificate revocation such as employee termination and misuse of security privileges.
Policies for certificate revocation lists (CRLs), including CRL distribution points and publishing intervals.
Policies for certificate revocation lists (CRLs), including CRL distribution points and publishing intervals.
Policy for renewing the CA's certificate before its expiration.

Security for Certificate Authorities

In general, it is important to provide high levels of security for CAs and their private keys. Each CA is certified with a CA certificate and uses its private key to sign all of the certificates and the certificate revocation lists it issues. If someone can steal or discover the CAs private key, they can impersonate the CA and issue counterfeit certificates. Likewise, someone who has the CA's private key, can publish counterfeit certificate revocation lists. Therefore, protecting the CA's private key is crucial to ensuring its integrity.

Ways to Trust Certificate Authorities

Many public key infrastructures, including the Windows 2000 public key infrastructure, support a hierarchical trust model where trust is placed in root CAs that are used to certify child CAs also called subordinate CAs. The root CA has a self-signed certificate and is the most trusted CA in an enterprise. Root CAs can issue subordinate CA certificates and these subordinate CAs can, in turn, issue subordinate CA certificates. The resulting CA trust chain or certification hierarchy can be many levels deep. You can choose to trust certificates for security functions based on trust for the root CA of the certification trust hierarchy for the issuing CA. The chain of trust for certificates is called the certification path. For more information about CA hierarchies and trust, see "Windows 2000 Certificate Services and Public Key Infrastructure" in this book.

Many public key infrastructures, including the Windows 2000 public key infrastructure, also include mechanisms for cross-certification trust so you can choose to trust certificates for CAs that are not in your organization's certification trust hierarchies. Windows 2000 certification provides a unique method for trusting third-party certificates and CAs that are called Certification Trust Lists (CTLs). Because certification hierarchies provides a very broad trust for all certificates issued by CAs in the chain, you can often use cross-certification trust to narrow the scope of your trust for certain certificates. For example, in Windows 2000 you can use CTLs to trust specific certificates issued by a business partner's CA to grant access to Web resources on an extranet. Even though the certificate might be valid for many purposes, you can use a CTL to restrict the authorized purposes of the certificates to Web authentication only.