CPS: Your roadmap to Lotus Notes/Domino and Internet certifiers
There is nothing more relaxing than traveling on some of the old Farm to Market (FM) roads in West Texas. At any point in time, you can see roadrunners, possums, deer, horses, and "Moocows" (see James Joyce's A Portrait of the Artist As a Young Man). Driving around taking the next FM road that you see is a fun activity, but one disadvantage to it is that you can get really lost. One day we were driving out on FM 67 and stopped into a filling station. We asked the 6' 3" attendant Ray, who wore overalls sporting the obligatory oval name tag sewn on, "Can you help with some directions?" Ray put down a large wrench and replied, "Yup." We asked, "Any idea how to get to I 35?" Ray looked up at the rotting wood ceiling and mused, "Um, let's see... you could take FM 67 down to FM 18, but 18 was washed out by the flood last week. But I guess you could take 67 to old FM 48 and cut through Bubba's farm, but he shot the last person who did that." Finally Ray concluded, "Now that I think about it, I guess you just can't get there from here!"
OK, so it's an old story you've probably heard before. But it does have a valid moral: When traveling, it's best to have a roadmap. The map provides you with a mechanism to get from one point to another, to have some fun, and then to find your way back home without relying on advice from folks like Ray to keep you out of trouble.
A roadmap is just as important in security and Public Key Infrastructure (PKI) management. The document that can serve as this map is the certification practice statement (CPS). The CPS document is one component of a holistic set of policies and procedures. As with many policies, it is interlinked with other security and policy activities.
This article explains how you can create a certification practice statement to manage your Lotus Notes and Domino PKI infrastructure. We discuss all the components that you may want to include in your CPS and offer a template CPS that you can modify to meet your organization's requirements. (You can download this template from the Sandbox.) This article assumes that you are familiar with the basics of Notes/Domino security.
Introducing the CPS
The certification practice statement contains the details of the management and systemic practices for a company's PKI systems. This includes the security and issuance of certificates and the management of expired and terminated certificates.
According to RFC 2527, the CPS "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...need to be covered in a certificate policy definition." The Information Security Committee of the American Bar Association adds, "A certification practice statement may take the form of a declaration by the certification authority of the details of its trustworthy system and the practices it employs in...[the] issuance of a certificate."
The following diagram shows some basic enterprise security policies and procedures and the interaction of the CPS between each component:
Figure 1. Security architecture
As you can see, the CPS interacts with most of the other security policy and procedure documents. For more information on policies, see the National Institute of Standards and Technology (NIST) Web page.
The CPS and Domino
So how does this impact you? If you are a Lotus Domino administrator (or are planning to use Domino), then the answer to this question will help you understand Notes support for PKI.
Lotus Notes supports two PKI systems: the internal Notes PKI and the standards-based PKI. Notes internally uses a public and private key system to encrypt and decrypt data and to validate digital signatures. The Lotus Notes certificate system is based on the BSAFE toolkit from RSA Security. The BSAFE toolkit provides the cryptosystem methods and algorithms that Notes uses for encryption.
Each user's Notes.id file contains a public and private key pair that is unique; each of these keys is mathematically related to an ancestral certifier. A public key is stored in your Notes.id file and a directory (the Domino Directory, names.nsf). Each user's private key is stored only in the User.id file. Notes email encryption is executed by using the public key in the directory to encrypt the data. The recipient can read the encrypted data by using a private key in the Notes.id file. (For more information about Notes/Domino security, see the recent developerWorks: Lotus article, "Lessons in secure messaging using Domino 6.")
Unfortunately, some companies have lost control of their certifiers. In one example, a corporation installed Notes during the V3 days. As good corporate citizens, they created an O, then OUs for each division. But that was 15 administrators ago, and each one knew the password to the O and the OU. As a result, the O and OUs must now be considered compromised. This is where the Notes/Domino 6 Certificate Authority (CA) with a CPS can help. Using the CA and CPS together, you can create new Os and OUs, keep each certifier under control, and be assured of your certificate security. (We talk more about the Notes CA in the next section.)
The Notes.id file can also store PKIX (Public Key Infrastructure X.509) certificates that support the Public Key Cryptography Standards (PKCS) architecture. This includes PKCS #12 imports and exports. PKIX keys are also known as Internet keys. In addition to Web server authentication/authorization, these keys can be used to send and receive S/MIME mail messages and to encrypt SSL transactions between Internet servers.
A Domino administrator can add Internet private keys during registration of a Notes ID, or an end user can request the Internet certificate at any time. Also each user has the ability to import and export PKCS #12 certificates. (Some Internet certificates may have a password and may be blocked from import and export.)
The Domino Certificate Authority (CA) and Registration Authority (RA)
The CA process is a server add-in task that manages and executes the issuance of both Notes.id certificates and X.509 certificates. The CA is a trusted authority that issues certificates. In the past, this authority implied that the CA had physical access to the Notes.id certifier. This also implied (but not required) that the CA had access to the Notes.id password. To help maximize security, you can put two or more passwords on the Notes.id certifiers and give only one person access to each password. This can help minimize security risk when an administrator leaves because the person knows only a single password and cannot create certificates even if he or she possesses the certifier file. However, certifying users under this system can be cumbersome because it requires the involvement of two or more people to certify even a single user.
In Notes/Domino 6 and later, the CA process also supports a feature known as the Registration Authority (RA). The RA acts as a proxy for the CA. The RA can register users based on a set of access rules defined by the CA. The primary advantage of the RA role is that the RA does not have physical access to the certifier ID file. It is easy to set up a distributed certifying architecture without having to hand out each certifier ID file. Also the CA/RA process supports multiple passwords on each OU. (For more information, see the article, "Be the authority on the Domino 6 Certificate Authority.")
Prior to Notes/Domino 6, the standard practice was to create the Notes O certifier with two passwords (and lock it in a safe), and then to create each Notes OU with one password. With Notes/Domino 6, you can now do the following:
- Create the Notes O certifier with two passwords and load it into the CA process (and lock it in a safe).
- Create each Notes OU with two passwords and load it into the CA process.
- Define CAs.
- Define RAs.
The CA/RA system brings a new set of tools to any Notes/Domino enterprise. With these tools each enterprise must define the appropriate supporting security documents. How can all of this be managed? This is where the CPS roadmap is needed. The CPS helps you to manage all of these issues and much more.
Each enterprise should define a CPS for both Notes.id files and X.509 certificates. The CPS not only defines the management of the certifiers, but also dictates legal responsibilities, roles, policies, and procedures. The following list covers the basic elements for any CPS (although not necessarily in this order):
- Certification Practice Statement in your company
- Legal obligation
- Detailed practice specifications
- Confidence and reliability
- 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
The following sections discuss each of these elements.
The introduction should include the scope and basic responsibilities of the CPS document.
Certification Practice Statement in your company
This is a definition of where the CPS lives in your enterprise.The CPS should specify where certificates are used in the organization. This section also identifies whether you are using Internet and/or external CAs.
This section defines the rights, duties, and expectations of each party -- CAs, RAs, and individual certificate holders. If needed, include CFR 21 Part 11, HIPAA, or any other similar legal and/or governmental laws and rules that may impact your company.
Detailed practice specifications
This section lists various actions taken by the CA to validate a certificate applicant's identity and confirm the information provided during the application (provisioning) process. Termination and revocation specifications are also included in this section.
This section describes the privacy requirements for your enterprise in respect to certificates. This section should also define how information will be protected as part of the provisioning process. For example, certificate applicants may be asked for personal information as part of the certificate binding process. Also list definitions of directory privacy in this section. Include links to other documents and information for privacy in your company. If needed, include all applicable legal/governmental laws and rules.
Confidence and reliability (including nonrepudiation)
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 helps bind the sender to the message. (For more on nonrepudiation, see the article, "Lessons in secure messaging using Domino 6.")
Statement regarding trustworthiness
The reliability of any PKI system depends on the security and authentication practices of each party involved. These practices establish the "trustworthiness" of the system. 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 cover:
- Administrative personnel
- Systems and networks
Statement regarding audits
Audits should be defined and scheduled. The systems for reporting the audits should also be defined. However, keep in mind that the CPS may be a public document. In that case, you should not provide details about the internal workings of your organization. Most CPS statements are not granular regarding auditing, so take care not to provide too much information (which could aid in security penetration). Some enterprises may publish two version of the CPS, a public copy and an internal copy.
Statement regarding root key certificate
The following items should be considered for this section: The procedure for creating the root certificate and public/private keys. How the CA will protect access to the private keys after they have been generated. The security of the environment and access to the environment. This includes physical access to audits logs, the mechanism that will provide backup and recovery of the root keys, and the steps taken to keep the root keys from being compromised. Also include a plan in the event a compromise occurs.
Statement regarding identification and authentication practices
The identification and authentication process requires that the certificate applicant provides specific information in order to receive certificates. This could include one or more of the following: personal identification number (PIN) assigned by an external entity, driver's license, passport, employee ID, or other type of ID. Also reference the privacy section of the CPS for how this personal information will be protected.
Statement regarding certificate revocation
This is the process of publishing and managing a Certificate Revocation List (CRL) and/or termination lists. (We talk more about this later in this article.)
Management of the certificate life cycle
The life cycle of a certificate is, in most cases, similar to the following diagram:
Figure 2. Certificate life cycle
All elements of the CPS are important, but the certificate life cycle is effectively the core of the CPS. So let's examine it now in detail.
Certificate life cycle
The certificate life cycle is where certificates are issued and revoked. The steps of the cycle are as follows.
Application (request) for certificate
This is the entry point into the process for new or renewed certificates. This step requests that each user is bound to the certificate. This is the validation by the CA/RA that ensures users are really who they say they are. In some enterprises, there is a binding authority that will determine the identify of the user requesting the certificate. Also, many companies use a proxy system to request a certificate. One example is where the HR department manages the provisioning of all system resources for new users. HR follows rules defined in the CPS section, "Statement regarding identification and authentication practices." After the user is identified and verified, a certified request for a new resource access is sent from HR to each system and subsystem. Recertification of certificates is managed by the Security department and proxied to the help desk.
Validation of application
This process is executed by two parties, the RA and the user. In the case of a proxy, such as HR, the RA verifies that the request is valid. One method is to use a controlled internal system to request and issue certificates. Other methods can include verbal verification to valid certificate requests. End users are then notified that they (or their proxy) have issued a request for a new (or renamed) certificate.
Acceptance of certificate
This is the step when the user accepts the certificate from the RA (and/or proxy). The user may use a PIN and/or other system to access the certificate. Notes users can receive their Notes.id files from a manager, and then obtain the password for the ID from a trusted subsystem (such as the Security department).
Certificate suspension or revocation
This step is necessary when the certificate has been compromised or is no longer required for that user (or system). There are many methods to manage this in Lotus Notes:
|Example of compromised certificate||Rules from CPS|
(some rules also from Acceptable Use policies)
|Actions required per CPS||Lotus Notes (Notes.id) actions|
|User shared ID with friend.||ID is never shared between users.||Compromised IDs can be controlled using Domino server controls.||Use password checking. Change the user's password and clear the digest in the Person document.|
|User shared ID with friend.||ID is never shared between users.||Compromised IDs must be re-issued.||The old ID is added to the termination list and a new ID is re-issued.|
|User is unable to read new encrypted messages.||The directory must be protected from man-in-the-middle public keys attacks.||Compromised public keys from the directory must be re-issued.||The user creates a new public key and sends it to the administrator to be put into the directory.|
|O and/or OUs are compromised.||O and OUs must be protected with two passwords. The Notes/Domino 6 CA process stores IDs.||In the event of a compromised O and/or OUs, all users must be re-certified into a new O and/or OU structure.||There are two options:|
|User no longer requires a Notes.id|
(User Termination Process)
|IDs and associated documents must be purged.|
This table shows just a few examples that illustrate the importance of the CPS. It is up to each enterprise to determine which steps are required to meet their CPS requirements.
Certificate renewal and expiration
Lotus Notes provides a robust system to renew Notes IDs. In fact, administrators can issue a renewal of Notes.ids automatically. Some companies use an agent-based system that sends a report to an employee's manager when his or her ID is about to expire. If the manager does not know this person, and/or this person has left the company, then the manager can contact the security department and tell him not to re-issue the ID file. This step also links into the termination process of certificates. The Domino 6 Directory has a view (Certificate Expiration) that shows Notes.id expiration times.
Certificate revocation list (CRL)
The CRL (sometimes called the terminations list) is basically a list of revoked certificates that is signed by a CA. When a certificate is issued to a user or system, it is expected to be in use for the period that it is valid. For example, if an employee leaves your organization, you should invalidate the certificates that they have been using. The CRL will accomplish this.
Other uses for the CRL include:
- You suspect that the certificate has been compromised.
Many browsers allow you to export a certificate and import it into another browser. So if you're not careful about keeping your ID to yourself, someday you may find that someone has submitted a P.O. for a billion dollars in chewing tobacco using your certificate. In cases where the user has shared a certificate, the RA places the old certificate into the CRL and issues a new certificate. Then remind the user not to share IDs -- or he may find himself filling out a job application at our old friend Ray's gas station down on FM 67.
- A person needs to change her name.
In this case, the old certificate is placed into the CRL and a new one is issued. You may need to update the name in two places, one for Lotus Notes and one for X.509.
One of the biggest issues with a CRL is the time gap between when a certificate has been flagged for inclusion in the CRL and when it actually gets put there. Unfortunately, some organizations have formed the following bad habits over the years:
- Taking days or even weeks before a certificate is placed into the CRL
- Not putting the certificate into the CRL at all
- Not having an emergency CRL process
- Not having a CRL
As you can imagine, any of these oversights could result in a significant security risk. So make sure you put processes in place to manage certificates that need to be removed from your organization. At the same time, bear in mind that your CRL can eventually grow very large with thousands (or even hundreds of thousands) of entities.
The Notes/Domino 6 CRL
In Notes/Domino 6, each X.509 certifier has an Issued Certificate List (ICL) that is created when the certifier is created or migrated to the CA process. The ICL is a database that includes the following elements:
- A copy of each unexpired certificate issued to it
- CA configuration documents
- AdminP proxy action
- Certificate revocation lists (CRLs)
The Notes/Domino 6 CRL is a time-stamped list of revoked Internet certificates. (The reasons for listing each entry is determined by the rules of the CPS.) The Notes/Domino 6 CA process issues and maintains CRLs for each Internet certifier. A CRL is associated with each certifier and is signed by that certifier. A copy of the CRL is also stored in the Domino Directory, where it is used to assert certificate validity by entities that require certificate authentication. You can also use the AdminP function "Remove Certificate from Domino or LDAP Directory Proxy action 98" to remove the certificate from the Person document.
The CA (and/or administrator) configures the CRL when a new Internet certifier is created and/or migrated into the CA process. The CA specifies the length of time for which a CRL is valid and the interval between publication of new CRLs. Also, Notes/Domino 6 provides CRL checking via a Web Site document:
Figure 3. CRL-related fields in Web Site document
For more on CRLs, see the Domino Administrator on-line help.
Managing expired certificates through the Server document
Notes/Domino 6 has another method for managing expired and/or retired certificates. This involves putting a list of names and/or groups into the Not access server field of the Security section of the Server Document. Use this field to enter the names of Notes and Internet users/groups who are not allowed to access this server. Names entered in the Not access server field take precedence over names entered in the Access server field:
Figure 4. The Not access server field
To take full advantage of this field, you can create a group (called Terminations, for example) and give it the Deny Access group type. Then add this group name to the Not access server field. This blocks all users on the list, even those who may otherwise have seemingly valid IDs. (This and other methods for restricting server access are discussed in more detail in the Domino Administrator on-line help.)
Now that you know the basics of what a CPS is used for and what it typically contains, it's now time to create and implement one for your own site. To help you get started, we've created a CPS template that you can adapt and modify to your own requirements. You can download the CPS template from the Sandbox.
One final question to consider is, "Who creates the CPS?" The answer depends on the corporate structure of your company. If yours is a large enterprise, then a Corporate Security Office might typically manage the creation of the CPS. In smaller companies, this work can be performed by the applications or messaging manager. In any case, make sure your legal department is involved with the creation of the CPS.
In this article, we have introduced the concepts around PKI and how Domino 6 implements them along with some tips and best practices. We have taken you through a roadmap to manage and document your certifiers (both Notes and X.509). Happy (and secure) driving!
- Download the CPS example template from the Sandbox.
- For more information about Notes/Domino security, see the developerWorks: Lotus article, "Lessons in secure messaging using Domino 6."
- The article, "Be the authority on the Domino 6 Certificate Authority," offers details about the Notes/Domino 6 CA.