Chapter 1 Introduction to Certificate Management System

This chapter introduces Netscape Certificate Management System (CMS), a highly configurable set of software components and tools for creating, deploying, and managing certificates.

The chapter has the following sections:

• System Overview


• Authentication and Policy Modules


• Some Enrollment Scenarios


• End Entities and Life-Cycle Management


• Summary of System Features


• System Architecture


• Standards Summary

• Public-Key Cryptography Standard (PKCS) #11


• Secure Sockets Layer (SSL)


• Lightweight Directory Access Protocol (LDAP)


• X.509 certificate formats recommended by the International Telecommunications Union (ITU)


• Public-Key Infrastructure (X.509) (PKIX) standards proposed by the PKIX working group of the Internet Engineering Task Force (IETF).


• Federal Information Standards Publications (FIPS PUBS) 140-1.

The standards and services that facilitate the use of public-key cryptography and X.509 version 3 certificates in a networked environment are collectively called public-key infrastructure (PKI). In any PKI, a certificate authority (CA) is a trusted entity that issues, renews, and revokes certificates. An end entity (EE) is a person, router, server, or other entity that uses a certificate to identify itself.

To meet the widest possible range of configuration requirements, Certificate Management System permits the independent installation of three separate subsystems, or "managers," that typically play distinct roles:

• A Certificate Manager functions as a root or subordinate certificate authority. This subsystem issues, renews, and revokes certificates, generates certificate revocation lists (CRLs), and can publish certificates and CRLs to an LDAP directory. It can be configured to accept requests from end entities, Registration Managers, or both, and can process requests either manually (that is, with the aid of a human being) or automatically (based entirely on customizable policies and procedures). When set up to work with a separate Registration Manager, the Certificate Manager processes requests and returns the signed certificates to the Registration Manager for distribution to the end entities. (For an overview of the role of certificate authorities and related concepts of public-key cryptography, see Appendix D of Managing Servers with Netscape Console.)
• A Registration Manager performs a subset of the end-entity tasks performed by the Certificate Manager, such as enrollment or renewal, on behalf of the Certificate Manager. A Registration Manager is typically installed on a different machine from the Certificate Manager that it serves. After the Registration Manager approves requests, it forwards them to this Certificate Manager, which trusts the Registration Manager to provide reliable authentication services and therefore trusts any signed requests it submits. The Certificate Manager processes the requests and issues the certificates. The Registration Manager then distributes the certificates to the end entities.
• A Data Recovery Manager performs the long-term archival and recovery of private encryption keys for end entities. A Certificate Manager or Registration Manager can be configured to archive end entities' private encryption keys with a Data Recovery Manager as part of the process of issuing new certificates. The Data Recovery Manager is useful only if end entities are encrypting data (using applications such as S/MIME email) that the organization may need to recover someday. It can be used only with client software that supports dual key pairs--that is, two separate key pairs, one for encryption and one for digital signatures. This service is available in newer clients only (including future versions of Communicator). The Data Recovery Manager archives encryption keys. It does not archive signing keys, since such archival would undermine nonrepudiation properties of dual-key certificates.

Figure 1.1 illustrates some of the data formats and protocols used among the three independent CMS managers and various kinds of end entities. To keep things simple, the figure assumes that each manager is installed in a different CMS instance and on a different machine. The Registration Manager handles all interactions with different kinds of end entities, using protocols appropriate for each entity.

• Certificate Request Message Format (CRMF) and Certificate Management Message Formats (CMMF). Proposed standards from the Internet Engineering Task Force (IETF) PKIX working group that define message formats used to convey requests to a Registration Manager or Certificate Manager and to return information to end entities. CMMF will be subsumed by another proposed standard, Certificate Management Messages over Cryptographic Message Syntax (CMC), which is also supported by Certificate Management System.
• Certificate Enrollment Protocol (CEP). A certificate management protocol jointly developed by Cisco Systems and VeriSign, Inc. CEP governs communication between routers or VPN clients and a Registration Manager or Certificate Manager.
• KEYGEN tag. An HTML tag supported by Netscape browsers that generates a key pair stored in the client and formats an HTTP GET string to send off to a CA as part of the enrollment process.
• Public-Key Cryptography Standard (PKCS) #7. An encrypted data and message format developed by RSA Data Security to represent digital signatures, certificate chains, and encrypted data. This format is used to deliver certificates to end entities.
• Public-Key Cryptography Standard (PKCS) #10. A message format developed by RSA Data Security for certificate requests. This format is supported by many server products and by Microsoft Internet Explorer.

• Hypertext Transport Protocol (HTTP) and Hypertext Transport Protocol Secure (HTTPS). Protocols used to communicate with web servers.

An authentication module is a set of rules (implemented as a Java class) for authenticating an end user, server, or other entity that needs to interact with a CMS manager. (Similar rules are used to authenticate agents and administrators, but they are built into Certificate Management System instead of being implemented as plug-in modules.) With a typical end-user enrollment, the user supplies the information requested by the Registration Manager on an enrollment form, and then the servlet uses an authentication module specified within the form to validate the information and authenticate the user's identity. This simple input value makes it possible to use custom authentication for any form without changing the corresponding servlet code.

After a Registration Manager or Certificate Manager has successfully authenticated an end entity, the entity's request is passed to a policy processor, which sequentially applies a set of policy rules configured for that CMS manager. A policy module is a rule (implemented as a Java class) that validates the contents of a certificate request for that rule and can add or modify any part of a certificate's contents, including validity dates, name constraints, and extensions.

• A name constraints policy checks that the subject name matches a pattern, and it rejects, defers, or adjusts the subject name in the request accordingly.
• A validity constraints policy checks that the certificate validity period falls within a specified period, and it rejects, defers, or adjusts the validity period in the request accordingly.
• An extensions policy checks that a request includes a specified extension and adds the extension if it's missing.

The following steps take place when a Registration Manager or a Certificate Manager handles an enrollment request from an end user. Figure 1.2 shows a simplified view of how this works.

1. Submit form. When the user first interacts with the CMS manager (either the Registration Manager or the Certificate Manager), the user specifies the kind of request to be made, fills in the form for that request, and submits it to the servlet via HTTP or HTTPS. The servlet then processes the form. In the figure, a certificate request is being sent to an enrollment servlet. It could also be a renewal or revocation request being sent to one of the other servlets.
2. Authenticate user. Authentication can be either automatic or manual. If the CMS manager is configured for automatic authentication, the servlet uses the authentication module specified by the form to validate the information provided by the user. For example, the directory authentication module that comes with Certificate Management System validates the user ID and password by comparing it to the user's entry in an LDAP directory. Custom authentication modules can be used to take advantage of existing databases, security systems, or other methods of authentication. If the CMS manager is configured for manual authentication, the servlet routes the request to the request queue and informs the user (via a web page) that approval has been deferred. The request remains in the queue until an agent approves it or rejects it.
3. Process policies. If authentication is successful, policies specified for this CMS manager are applied to the request for the purpose of formulating the contents of the certificate to be issued and to enforce certain rules, such as name constraints. Custom policy modules can be used to enforce specialized certificate extensions and other requirements.
4. Service request. After policy processing, the servlet's work is finished and the CMS manager services the request (assuming that a policy has not triggered deferral)--for example, by issuing a certificate.
5. Notify user. If the CMS manager has been configured for automatic authentication and issuance, the manager delivers the signed certificate to the user via a web page. If the request has been deferred (for example, for manual approval) or rejected, the user is informed of the request's status. When the request has been approved and the certificate issued, the CMS manager notifies the user (for example, with an email) and provides a URL where the certificate can be picked up.

• Firewall Considerations


• Extranet/E-Commerce: Acme Sales Corp.


• PIN Registration: Atlas Manufacturing


• VPN Client Enrollment and Revocation


• Router Enrollment and Revocation

Most of the examples that follow show a Certificate Manager inside the firewall and a Registration Manager outside the firewall. Other variations are possible, but this arrangement is often appropriate. These are some of the advantages:

• The most sensitive elements of the deployment--the Certificate Manager, internal databases, directories, and so on--have the additional protection of the firewall.
• The Certificate Manager can have additional physical protection, if desired--such as storage in a locked room and agent authentication by means of smart cards.
• All communication between the Registration Manager and the Certificate Manager takes place over SSL with mutual authentication--that is, both client and server authentication via X.509 v3 certificates.
• The Registration Manager provides only a subset of the capabilities of the Certificate Manager--those required for processing end-user requests. If the Registration Manager is compromised, the Certificate Manager can revoke its signing certificate (thus invalidating all subsequent requests from that Registration Manager) and issue a new one after the problem has been addressed.

Acme Sales is a high-end mail-order catalog service that is launching an online shopping service. Many of Acme's affluent customers make very expensive purchases, so Acme has decided to use certificate-based authentication for its new web site.

• Enrolling Existing Customers


• Enrolling New Customers


• Enrolling Extranet Users

Acme has decided on the following process for registering its existing customers, as shown in Figure 1.3.

1. Request certificate. The customer fills in and submits a form (over SSL) that specifies account information and other personal details stored in the existing customer database.
2. Custom authentication. The Registration Manager uses a custom authentication module to verify the customer's account and status against the existing customer database.
3. Request certificate. If authentication against the customer database is successful, the Registration Manager performs policy processing and, if processing is successful, forwards the request to the Certificate Manager.
4. Issue certificate. The Certificate Manager performs its own policy processing and, if processing is successful, issues the certificate and delivers it to the Registration Manager.
5. Deliver certificate. If the Certificate Manager successfully issues the certificate, the Registration Manager delivers it to the end user in the same session. If the request is unsuccessful for any reason, the Registration Manager displays a web page to the customer explaining the problem and what to do about it.

Figure 1.3 Custom authentication against an existing customer database

The following process will be used for enrolling new Acme customers. In this case, the Registration Manager uses manual authentication to validate every certificate request personally before issuing the certificate. Figure 1.4 illustrates the steps in this process.

1. Request certificate. The customer fills in and submits a certificate request form for new Acme customers.
2. Deferral notice. The Registration Manager immediately informs the customer (via a web page) that the request has been deferred and that Acme will be in touch soon. Meanwhile, the certificate request waits in a queue for attention from the Registration Manager agent.
3. Manual approval. The Registration Manager administrator may configure the Registration Manager to notify the agent via email whenever a new request is added to the request queue. In any case, when the agent processes the requests in the queue, he or she follows Acme's procedure for processing credit checks and validating other customer information, including making a personal phone call. If all authentication procedures are successful, the agent approves the request.
4. Request certificate. The Registration Manager performs policy processing and, if the processing is successful, sends the approved request to the Certificate Manager.
5. Issue certificate. The Certificate Manager performs its own policy processing on the request and, if processing is successful, issues the certificate and delivers it to the Registration Manager.
6. Email notice of issuance. The Registration Manager sends an email containing a URL to the new customer, asking the customer to pick up the certificate.
7. Pick up certificate. The customer goes to the specified Registration Manager URL and picks up the certificate.

Figure 1.4 Manual authentication of new customers

Acme wants its new, certificate-enabled extranet applications to be available to contract workers, suppliers, employees, and others who routinely access parts of the company's internal network. In general, this can be achieved by using Kerberos or other non-PKI security systems as the authentication mechanism for requesting a certificate. To authenticate them for the purposes of PKI enrollment, Acme uses a third-party authentication module from DASCOM that takes advantage of its existing Kerberos system without disturbing its current functions.

1. Request certificate. A user of Acme's existing extranet fills in and submits a certificate request (over SSL) using a customized form that requires a Kerberos ID and password.
2. Authentication. The Registration Manager uses a third-party authentication module to validate the user's identity using the existing internal Kerberos system.
3. Request certificate. If authentication against Kerberos is successful, the Registration Manager performs policy processing and, if processing is successful, forwards the request to the Certificate Manager.
4. Issue certificate. The Certificate Manager performs its own policy processing on the request and, if processing is successful, issues the certificate and delivers it to the Registration Manager.
5. Deliver certificate. If the Certificate Manager issues the certificate, the Registration Manager delivers it to the end user in the same session. If the request is unsuccessful for any reason, the Registration Manager displays a web page to the user explaining the problem and what to do about it.

Figure 1.5 Custom authentication against an existing Kerberos security system

Atlas Manufacturing has decided to put information for its employees, suppliers, dealers, and customers--a total of nearly 500,000 people, including individual consumers and employees of several dozen other companies--on an extranet. Atlas already uses Netscape Directory Server to store names, addresses, and other information about the various groups of people who will need access to the extranet. To register all these people at once, Atlas uses the directory-based PIN Generator tool that comes with Certificate Management System to generate PINs in bulk. The PINs are then stored in the directory and delivered to the end users via a batch mailer program, an employee payroll stub, a customer invoice, or some other means of physical delivery.

1. Generate PINs. The CMS administrator runs the CMS PIN Generator against the existing directory, populating each entry with a unique PIN.
2. Write out PIN records. The CMS administrator uses the CMS PIN Generator to write out PIN records for use by an out-of-band delivery mechanism.
3. Out-of-band delivery. The user receives the PIN via a batch mailing system, payroll stub, invoice form, or other out-of-band delivery mechanism.
4. Request certificate (using PIN). The user goes to a specified Registration Manager URL, fills in name and PIN, and submits a certificate request.
5. Authentication (using PIN). The Registration Manager uses the standard CMS PIN-based directory authentication module to verify the PIN against the directory.
6. Request certificate. If authentication against the directory is successful, the Registration Manager performs policy processing and, if this succeeds, forwards the request to the Certificate Manager.
7. Issue certificate. The Certificate Manager performs its own policy processing and, if all goes well, issues the certificate.
8. Deliver certificate. If the Certificate Manager issues the certificate, the Registration Manager delivers it to the end user in the same session. If the request is unsuccessful for any reason, the Registration Manager displays a web page to the user explaining the problem and what to do about it.

Figure 1.6 PIN-based enrollment

Virtual private network (VPN) client software runs on a user's desktop, outside the firewall, and uses the IP Key Management Protocol (IPKMP) or IP Security (IPSec) protocol to establish encrypted communication with VPN hardware that straddles the firewall. These protocols allow VPN hardware to authenticate VPN client software using the client's certificate, in much the same way that the SSL protocol allows a server to authenticate client browser software.

1. Enroll in PKI. The VPN client sends a certificate request to the Registration Manager via CEP, and the Registration Manager processes the request and forwards it to the Certificate Manager inside the firewall. (Any of the authentication methods discussed in the previous sections can be used during enrollment to authenticate the client.)
2. Issue certificate. The Certificate Manager issues the certificate, and the Registration Manager delivers it to the VPN client. The VPN client can now authenticate itself to the VPN hardware and establish an encrypted channel using IPKMP or IPSec. All TCP/IP communication passes through this encrypted channel. From the point of view of the VPN client, it appears to be directly connected to the TCP/IP network inside the firewall.
3. Publish certificate. The Certificate Manager publishes the certificate to a directory (this is an optional step).
4. Revoke certificate. After some time has passed, the Certificate Manager agent revokes the certificate (for example, after the certificate owner leaves the company).
5. Publish CRL. The Certificate Manager publishes a new CRL to the directory specified as the CRL distribution point in the original certificate.
6. Verify certificate. The VPN hardware checks the CRL as part of its authentication process. Certificates listed in the CRL are not authenticated, and VPN clients presenting them cannot establish a connection.

Figure 1.7 VPN client enrollment and revocation

Cisco routers support the use of certificates for authentication, encryption, and tamper detection with the IP Security (IPSec) protocol. Cisco routers also support CEP for certificate life-cycle management, as discussed in the previous section.

1. Enroll in PKI. The routers each send a certificate request to the Certificate Manager via CEP, and the Certificate Manager issues them certificates. (Any of the authentication methods discussed in the previous section can be used during enrollment to authenticate the client.)
2. Publish certificates. As part of the issuing process, the Certificate Manager publishes the certificates to the directory. (Publishing occurs only if the router's DN exists in the publishing directory. This is important for some Cisco routers that must fetch their certificates from an LDAP directory because flash memory is not large enough to hold them.) The routers can now authenticate each other and establish an encrypted channel using IPSec. All TCP/IP communication passes through this encrypted channel. From the point of view of other connections to each router, they all appear to be sharing the same TCP/IP network.
3. Revoke a certificate. After some time has passed, the Certificate Manager agent revokes one of the certificates (for example, after the certificate owner leaves the company).
4. Publish CRL. The Certificate Manager publishes the CRL to the directory.
5. Verify certificate. The routers check the CRL as part of their mutual authentication process. Certificates listed in the CRL are not authenticated, and routers presenting them cannot establish a connection.

Figure 1.8 Router enrollment and revocation

• Life-Cycle Management Formats and Protocols


• Access to Subsystems


• HTML Forms for End Users

The Registration Manager and Certificate Manager provide default HTML forms that use different protocols and life-cycle management procedures for different kinds of end entities. For example, end entities running Navigator 3.x and versions of Communicator earlier than 4.5 need to be presented with an enrollment form based on the use of the HTML tag KEYGEN to generate keys. End entities running Microsoft Internet Explorer require a form containing VBScript XENROLL commands. These various tags, scripts, and protocols result in enrollment messages that are sent back to the Certificate Manger or Registration Manager in a variety of nonstandard and standards-based formats.

Three kinds of entities can access CMS subsystems: administrators, agents, and end entities. Administrators are responsible for the initial setup and ongoing maintenance of the subsystems. Agents manage the day-to-day operations of each subsystem, such as responding to requests from end entities. End entities access Registration Manager or Certificate Manager subsystems to enroll in a PKI and to take part in other life-cycle management operations, such as renewal or revocation.

Each type of end-entity form provided by a Registration Manager or Certificate Manager determines the type of client, such as Communicator or Internet Explorer, and presents the appropriate input page. Each form also specifies both an authentication module and an output template. The authentication module is used by the servlet to authenticate the end entity; the output template is an HTML page that returns information from the servlet to the end entity.

• Authentication Modules


• Policy Modules


• Job Scheduler Plug-Ins


• Event-Driven Notifications


• Registration Manager


• Certificate Manager


• Data Recovery Manager


• Command-Line Utilities

An authentication module is a set of rules (implemented as a Java class) for authenticating an end entity, agent, administrator, or any other entity that needs to interact with a CMS manager. For an introduction to the role of authentication modules in the enrollment process, see Authentication and Policy Modules.

• Manual authentication. Requires manual approval by an agent. This authentication module is hardwired; you cannot configure it. This ensures that when the server receives requests that lack authentication credentials, it sends them to the request queue for agent approval. It also means that if you don't configure Certificate Management System for any other authentication mechanism, the server automatically sends all certificate-related requests to a queue where they await agent approval.
• Directory-based authentication. Checks a user's name and password against the user's entry in a specified directory and uses the DN for that entry to formulate the subject name for the certificate.
• Directory-based PIN authentication. Checks a user's name, password, and a special one-time PIN against the user's entry in a specified directory and uses the DN for that entry to formulate the subject name for the certificate. The PIN is stored in salted and hashed form, and is removed after being used once to authenticate a user during enrollment.

A policy module is a rule (implemented as a Java class) that validates the contents of a certificate request and formulates the contents of the certificate to be issued. Policy modules are also responsible for accepting, rejecting, or deferring the request. Certificate Management System policies have nothing to do with export control policies or certificate usage policies. For an introduction to the role of policy modules in the enrollment process, see Authentication and Policy Modules.

• DefaultRevocation. Allows the server to revoke only those certificates that are currently valid; expired certificates cannot be revoked.
• DSAKeyConstraints. Allows the server to certify only DSA keys of specified lengths.
• KeyAlgorithmConstraints. Allows the server to certify only those keys that are generated using one of the specified algorithms, such as RSA or DSA.
• RenewalValidityConstraints. Enforces the number of days before which a currently active certificate can be renewed and a new validity period for the renewed certificate.
• RSAKeyConstraints. Allows the server to certify only RSA keys of specified lengths.
• ValidityConstraints. Causes the server to check whether the validity period of a certificate falls within a specified period.

• AuthorityKeyIdentifierExt. Adds the Authority Key Identifier extension to certificates of a specified type. The Authority Key Identifier extension identifies the public key corresponding to the private key used to sign a certificate. This extension is useful when an issuer has multiple signing keys (for example, due to CA certificate renewal).
• BasicConstraintsExt. Adds the Basic Constraints extension to certificates of a specified type. This extension is used during the certificate chain verification process to identify CA certificates and to apply certificate chain path length constraints.
• CRLDistributionPointsExt. Adds the CRL Distribution Points extension to certificates of a specified type. This extension defines where CRLs that could list the certificate as revoked will be published.
• KeyUsageExt. Adds the Key Usage extension to certificates of a specified type. This extension defines the purpose of the key contained in the certificate. The Key Usage, Extended Key Usage, Basic Constraints, and Netscape Certificate Type extensions act together to specify the purposes for which a certificate can be used.
• NSCertTypeExt. Adds the Netscape Certificate Type extension to certificates of a specified type. This extension can be used to limit the purposes for which a certificate can be used. It has been replaced by the X.509 v3 extensions extKeyUsage and basicConstraints, but must still be supported in deployments that include Navigator 3.x clients.
• SubjectAltNameExt. Adds the Subject Alternative Name extension to certificates of a specified type. This extension includes one or more alternative (non-X.500) names for the identity bound by the CA to the certified public key. It may be used in addition to the certificate's subject name or as a replacement for it.
• SubjectKeyIdentifierExt. Adds the Subject Key Identifier extension to certificates of a specified type. This extension identifies the public key certified by this certificate. It provides a way of distinguishing public keys if more than one is available for a given subject name, for example after the certificate has been renewed with a new key.

The CMS Job Scheduler allows you to configure a Certificate Management System to perform a specified action at a specified time, such as informing a user of the need to renew a certificate or removing an expired certificate from the directory. The scheduler checks at specified intervals for jobs waiting to be executed; if the specified execution time has arrived, the scheduler initiates the job.

You can use standard CMS job plug-ins or write your own Java plug-in class in much the same way that you can write your own authentication and policy modules. Plug-in classes are provided out of the box for scheduling the following jobs:

• Renewal notification. Notifies end entities by email that their certificates are about to expire and must be renewed. This job also sends a summary of such notices to agents. Available for Certificate Manager only.
• Request in queue. Notifies agents at regular intervals of the state of the request queue. Alternatively, an event-driven notification can be sent whenever a request has been added to the request queue; see the next section for details. Available for Registration Manager or Certificate Manager.
• Directory expiration update. Updates a specified LDAP publishing directory periodically by removing expired certificates. This can be useful for end entities such as Netscape Enterprise Server 3.x that rely on the presence or absence of the certificate for authentication purposes, or if you wish to ensure that only current, valid certificates can be found in the directory. This job also sends a summary of removed certificates to agents or administrators. Available for Certificate Manager only.

The Certificate Manager and Registration Manager support two kinds of event-driven notifications:

• Request-completion status. Automatically notifies users by email that a requested certificate has been issued or that a request has been deferred or rejected. Available for Registration Manager or Certificate Manager.
• Request-queue status. Automatically notifies agents by email when a request has been added to the request queue. Available for Registration Manager or Certificate Manager.

A Registration Manager is a trusted subsystem to which a Certificate Manager can delegate responsibility. A Registration Manager cannot issue or revoke certificates by itself; instead, it evaluates end-entity requests and forwards them to a Certificate Manager for action, such as the issuing of a certificate.

• enrolling end entities (initial authentication and initiation to the PKI)


• enforcing policies such as request validation requirements, authentication requirements, and certificate formulation


• distributing issued certificates


• publishing issued certificates to an LDAP directory (LDAP 1.0 or higher)


• coordinating certificate renewal


• coordinating end-entity private encryption key storage with a Data Recovery Manager

A Certificate Manager can be configured to accept requests from end entities, from Registration Managers, or from both end entities and Registration Managers. When set up to work with a remote Registration Manager, the Certificate Manager processes requests and returns the signed certificates to the Registration Manager, which distributes them to end entities.

• can be configured as either a root CA or a subordinate CA


• can accept certificate requests directly from end entities and/or Registration Managers


• can issue end-entity, Registration Manager, and Certificate Manager certificates


• can issue single key-pair or dual key-pair certificates


• can notify users and administrators of approaching certificate expiration


• can renew certificates


• can revoke certificates


• can publish certificates and CRLs to an LDAP directory (LDAP 1.0 or higher)

• X.509 version 3


• internationalized subject names


• customized components in subject names


• customized extensions

The Certificate Manager supports the following signing algorithms for both certificates and CRLs:

• RSA with MD2


• RSA with MD5


• RSA with SHA-1


• DSA with SHA-1

The Certificate Manager can issue X.509 v1 or v2 CRLs. A CRL can be automatically updated whenever a certificate is revoked or at specified intervals.

• Authority key identifier. Identifies the public key to be used to validate the digital signature on the certificate.
• CRL number. A sequential number unique to each CRL issued by a given CRL issuer. This number allows CRL-checking software to ensure that all previous CRLs have been received.
• Issuing distribution point. The URL at which this CRL is maintained.

• Issuer alternative name
• Delta CRL indicator
• Certificate issuer

• Reason code. Indicates the reason the certificate was revoked.
• Invalidity date. Indicates the date on which the private key corresponding to the public key certified by the certificate was (or is suspected to have been) compromised.

A Data Recovery Manager provides facilities for archiving and recovering private RSA encryption keys. This crucial element of a PKI allows an authorized Data Recovery Manager agent to recover an encryption key that has been lost or corrupted. It also allows administrators to recover encryption keys for employees who have left the company or who are unavailable for some other reason. In either case, once the encryption key has been recovered, the user or administrator can use it to decrypt any data (such as saved email messages) that was encrypted with that key.

1. After the user completes and submits an enrollment form, the end entity generates dual key pairs and sends two certificate requests to the Registration Manager, which detects a request for key archival and requests the private encryption key from the end entity. The end entity then encrypts (or "wraps") its newly minted private encryption key with the Data Recovery Manager's public transport key (obtained from a copy of the transport certificate embedded in the enrollment form) and sends the wrapped private key to the Registration Manager.
2. The Registration Manager sends the end entity's wrapped private encryption key to the Data Recovery Manager as part of a key storage request (which also includes the end entity's public encryption key).
3. The Data Recovery Manager uses its private transport key to decrypt the end entity's private encryption key. After confirming that the private encryption key corresponds to the end entity's public encryption key, the Data Recovery Manager encrypts the private encryption key with its private storage key and stores the private encryption key in the CMS internal database.
4. The Data Recovery Manager signs a proof-of-archival token with its private transport key and sends the token to the Registration Manager.
5. The Registration Manager verifies the token and sends the certificate requests on to the Certificate Manager.
6. The Certificate Manager issues the signing and encryption certificates and sends them back to the Registration Manager
7. The Registration Manager delivers the certificates to the end entity.

Figure 1.11 Key storage process during end-entity enrollment

Table 1.4 summarizes the command-line utilities that are bundled with Certificate Management System. For more detailed information about these utilities, see Appendix D and the appendixes that follow in Netscape Certificate Management System Administrator's Guide. The binaries for the tools listed in the table are located in the directory <serverroot>/bin/cert/tools.

Public-Key Cryptography Standard (PKCS) #11 specifies an API used to communicate with devices that hold cryptographic information and perform cryptographic operations. Because it supports PKCS #11, Certificate Management System works with a wide range of hardware and software devices intended for such purposes.

• Default Netscape Internal PKCS #11 Module. This comes with two built-in tokens:
• The Internal Crypto Services token performs all cryptographic operations, such as encryption, decryption, and hashing.
• The Internal Key Storage token ("Certificate DB token" in Figure 1.12) handles all communication with the certificate and key database files (called certX.db and keyX.db, respectively, where X is a version number) that store certificates and keys.

• FIPS 140-1 module. This module complies with the FIPS 140-1 government standard for implementations of cryptographic modules. Many products sold to the US government must comply with one or more of the FIPS standards. The FIPS 140-1 module includes a single, built-in FIPS 140-1 Certificate DB token (see Figure 1.12), which handles both cryptographic operations and communication with the certX.db and keyX.db files.

Netscape Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled communications applications. Applications built with the NSS libraries support the SSL protocol for authentication, tamper detection, and encryption as well as the PKCS #11 interface for cryptographic token interfaces. Netscape uses NSS to support these features in a wide range of products, including Certificate Management System.

Java Security Services (JSS) provides a Java interface for security operations performed by NSS. JSS and higher levels of the Certificate Management System architecture are built with the Java Native Interface (JNI), which provides binary compatibility across different versions of the Java Virtual Machine (JVM). This design allows customized subsystem services to be compiled and built just once and run on a range of platforms.

A middleware layer above JSS and the Java/JNI layer provides a range of services required by the Registration Manager, Certificate Manager, and Data Recovery Manager. The middleware layer is based on Java Development Kit (JDK) 1.1.6, and it underlies both the manager subsystems and the APIs available to third-party developers for building custom authentication and policy modules. The default authentication and policy modules provided with Certificate Management System are built from the same Java classes.

The top layer of Figure 1.12 consists of authentication and policy modules. Several default modules ship with Certificate Management System; third parties can create their own custom modules using the APIs provided above the middleware and subsystem layers. Modules for all three subsystems work the same way and are interchangeable.

Certificate Management System supports the following certificate management formats and protocols. For more details about the proposed PKIX standards listed here, see http://www.ietf.org/html.charters/pkix-charter.html (under Internet Drafts).

• Certificate Enrollment Protocol (CEP). A certificate management protocol jointly developed by Cisco Systems and VeriSign, Inc. CEP is an early implementation of CMC (described later in this list). CEP specifies how a device communicates with a CA, including how to retrieve the CA's public key, how to enroll a device with the CA, and how to retrieve a CRL. CEP uses PKCS #7 and PKCS #10.
• Certificate Request Message Format (CRMF). A message format used to convey a request for a certificate to a Registration Manager or Certificate Manager. A proposed standard from the Internet Engineering Task Force (IETF) PKIX working group.
• Certificate Management Message Formats (CMMF). Message formats used to convey certificate requests and revocation requests from end entities to a Registration Manager or Certificate Manager and to send a variety of information to end entities. A proposed standard from the IETF PKIX working group. CMMF is subsumed by another proposed standard, CMC (next item).
• Certificate Management Messages over CMS (CMC). A general interface to public-key certification products based on CMS and PKCS #10, including a certificate enrollment protocol for DSA-signed certificates with Diffie-Hellman public keys. A proposed standard from the IETF PKIX working group. CMC incorporates CRMF and CMMF. Future versions of Certificate Management System will support this standard as it is finalized.
• Cryptographic Message Syntax (CMS). A superset of PKCS #7 syntax used for digital signatures and encryption. A proposed standard from the IETF PKIX working group.
• PKIX Certificate and CRL Profile (PKIX Part 1). The first part of the four-part standard under development by the IETF for a public-key infrastructure for the Internet. Part 1 deals with specifications for certificates and CRLs. Certificate Management System will support the other PKIX parts as they are finalized. For more information about PKIX Part 1, see ftp://ftp.isi.edu/in-notes/rfc2459.txt.

Certificate Management System supports the following security and directory protocols:

• FIPS PUBS 140-1. Federal Information Standards Publications (FIPS PUBS) 140-1 is a US government standard for implementations of cryptographic modules--that is, hardware or software that encrypts and decrypts data or performs other cryptographic operations (such as creating or verifying digital signatures).
• Hypertext Transport Protocol (HTTP) and Hypertext Transport Protocol Secure (HTTPS). Protocols used to communicate with web servers.
• KEYGEN tag. An HTML tag supported by Netscape browsers that generates a key pair for use with a certificate. For more information, see http://www.netscape.com/eng/security/comm4-keygen.html.
• Lightweight Directory Access Protocol (LDAP) v2, v3. A directory service protocol designed to run over TCP/IP and across multiple platforms. LDAP is a simplified version of Directory Access Protocol (DAP), used to access X.500 directories. LDAP is under IETF change control and has evolved to meet Internet requirements.
• Public-Key Cryptography Standard (PKCS) #7. An encrypted data and message format developed by RSA Data Security to represent digital signatures, certificate chains, and encrypted data. This format is used to deliver certificates to end entities.
• Public-Key Cryptography Standard (PKCS) #10. A message format developed by RSA Data Security for certificate requests. This format is supported by many server products and by Microsoft Internet Explorer.
• Public-Key Cryptography Standard (PKCS) #11. Specifies an API used to communicate with devices such as hardware tokens that hold cryptographic information and perform cryptographic operations.
• X.509 v1, v3. Digital certificate formats recommended by the International Telecommunications Union (ITU).
• Secure Sockets Layer (SSL) 2.0, 3.0. A set of rules governing server authentication, client authentication, and encrypted communication between servers and clients.