Figure 7.5
|
We have seen the importance of a CA; now we need to discuss the services that the CA provides, which apply to both open and closed systems. We need to look at the practices of the CA, including the actual services, the legality of the CA, and the trustworthiness of the CA. The concept that drives this is the "Certification Practice Statement," or CPS.[1]
This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy definition or a certification practice statement.[2]
A CPS is valuable for most CAs. You can see the importance of having one for a public CA. Using the CPS from a public CA, your company could review the practices and then determine if you "trust" the CA to manage your PKI. The CPS should also dictate legal responsibilities, roles, policies, and procedures. Following is a list of what should be covered in most any CPS:
Introduction
What is a certification practice statement? (or, What is a CPS in our organization?)
Legal obligations (the company and CAs)
Detailed practice specifications
Privacy
Confidence and reliability (including nonrepudiation)
Statement regarding trustworthiness
Statement regarding audits
Statement regarding root key certificate
Statement regarding identification and authentication practices
Statement regarding certificate revocation
Management of the certificate life cycle
Let's look at each item.
The introduction should include the scope and basic responsibilities of the document.
Overall, we have described it here in this book. What this section needs is a definition of what it means to your organization. Or, if you are using a service provider, make sure that they have documented this definition.
This section needs to define the rights, duties, and expectations of each party.
This refers to various actions taken by the CA to validate the certificate applicants' identities and confirm the information they provide during the application process. The type, scope, and extent of confirmation depends on the class of certificate, the type of applicant, and other factors. This also includes processes to manage expired certificates.
This section determines the privacy information and how to deal with each customer or user, and which directories public keys are placed in.
One of the most important factors of PKI is nonrepudiation. This can be used in various applications, including but not limited to messaging. The recipient of an electronic message needs to be confident of a sender's integrity. Nonrepudiation is concerned with binding the sender to the message. The sender should not be able to deny having sent the communication if in fact it was sent.
The reliability of any PKI system has much to do with the security and authentication practices of each party involved. These practices establish the "trustworthiness" of the system, which is based on good security practices. A very important factor in the trustworthiness of any public key infrastructure is the trust in a "trusted third party," or, the CA. The CA will need to provide a trustworthy infrastructure. This definition of trustworthiness should include (1) administrative personnel (2) employees, and (3) systems and networks.
Audits should be defined and scheduled. Also, the systems for reporting the audits should be defined. (Note: Keep in mind that your CPS may become a public document. In that case, you cannot provide details about the internal workings of the organization. Most CPS statements are not this granular regarding auditing, so be careful about providing too much information, which could be used in security penetration.)
The following items should be considered for this section:
Root certificate and public-private key pair creation. (the procedure for root certificate and public-private keys.)
Private key security. Describe how the CA will protect access to the private keys after they have been generated.
Physical security. Describe the security of the environment and access to the environment, including (1) card key access, if any (2) network firewalls, and (3) physical access audit logs.
Backup and storage facilities. Describe the mechanism that will provide backup and recovery of the root keys.
Root key compromise. Describe the steps taken to keep the root keys from being compromised and include the plan in the event a compromise does occur.
The identification and authentication process requires that the certificate applicant provide specific information in order to receive certificates. This could include the following (or be a combination of several identifications):
PIN assigned by an external entity
Driver's license
Passport
Employee ID
Other type of recognized ID
This is the process of publishing and managing a Certificate Revocation List (CRL). We will be discussing the CRL in the next section.
The life cycle of a certificate will in most cases follow the diagram in Figure 7.5.
Figure 7.5
[1]This term originated in the American Bar Association Digital Signature Guidelines (http://www.abanet.org/scitechhome.html). Another source of information is RFC 2527.
[2]http://www.ietf.org/rfc/rfc2527.txt
|
