RSA Keon Certificate Authority Product Overview Technology White Paper e-business is an integral component of everyday life-from online banking and brokerage transactions, to chip-based smart cards and e-contracts. Ensuring the security and scalability of e-transactions is imperative to a company s e-business success. Enterprises need systems to simplify and centralize the definition and administration of key and certificate management policies and procedures. The RSA Keon Certificate Authority is designed to help meet these needs by enabling organizations to better develop, deploy and scale secure applications and e-business services by automating and centralizing the management of cryptographic keys and digital certificates.
Table of Contents I. Introduction 1 II. Introduction to Public Key Infrastructure 1 III. Introduction to Certificate Authorities 2 Certificate Authority Architectures 2 IV. RSA Keon Certificate Authority 4 The Administration Server 5 The Enrollment Server 7 The Secure Directory Server 7 Logging Server 7 RSA Keon Registration Authority 8 RSA Keon Key Recovery Module 9 RSA Keon WebSentry Plug-in 9 Secure e-mail Module 9 V. RSA Keon CA Scalability 10 Summary 10 About RSA Security 10 RSA Security Inc.
I. Introduction e-business is an integral component of everyday life from online banking and brokerage transactions, to chip-based smart cards and e-contracts. Ensuring the security and scalability of e-transactions is imperative to a company s e-business success. The number of applications that use public key security and digital certificates is growing rapidly as more and more enterprises leverage e-business to grow corporate profits. Establishing the trust carried by certificates and managing the use of keys and certificates is critical to the proper deployment and maintenance of these products. To succeed in this task, enterprises need systems to simplify and centralize the definition and administration of key and certificate management policies and procedures. The RSA Keon Certificate Authority is designed to help meet these needs by enabling organizations to better develop, deploy and scale secure applications and e-business services by automating and centralizing the management of cryptographic keys and digital certificates. The RSA Keon Certificate Authority (CA), an industry leading digital certificate management system, helps enable companies to conduct secure and cost-effective e-business by providing a flexible and scalable system for managing digital identities. The RSA Keon CA is engineered to be a fullfeatured public key infrastructure (PKI)-based certificate management solution that provides the following essential elements of a robust security solution: strong authentication, data confidentiality, integrity and non-repudiation. The RSA Keon CA has been designed to maintain performance when scaled with demonstrated industryleading performance. The RSA Keon CA is built to easily integrate into your existing environment as it features an open, modular architecture to help ensure a timely and cost efficient deployment. II. Introduction to Public Key Infrastructure Network security is paramount to every corporation that stores sensitive data digitally. Data that is stored on a network, or that is passed from one user to another over a network, must be protected from the malicious attacks and random errors to which the digital medium is susceptible. To be sure that the data is secure, a security policy that ensures entity authentication, non-repudiation, data integrity, data confidentiality and authorization is an absolute necessity. Public key infrastructure, or PKI, is the security solution that meets these requirements and more. In a secure system, entity authentication is required so that users can be satisfied that they are communicating with only the person, corporation or system, with whom they wish to be communicating. For example, users sending their credit card number across a network to make a purchase want to be certain that they are dealing with a trustworthy merchant rather than a fraud who may steal their credit card number for a private spending spree. If the user verifies the identity of the merchant, he/she will send their credit information with greater confidence. Data confidentiality plays a major role within the transaction framework. Sensitive data, including business plans or financial transactions, must be safeguarded from prying eyes. The data confidentiality aspect of a PKI allows the transfer and storage of this data with the knowledge that only those who are intended to see the data may see it. Data integrity systems ensure that the message sent and the message received are the same. To see the importance of using a data integrity system, consider the case of an online banking transaction. For example, a user sends a request to move $400.00 from one account to another, but in the course of transmission a chance error or a malicious attacker alters that amount to $4,000,000.00. Both parties, the end user and the bank, would suffer severe consequences. Data integrity mechanisms inform the recipient when the message received matches the message sent, and perhaps more importantly, indicate when they do not match. Non-repudiation gives a recipient the confidence that the sender cannot deny having sent the data at a later date. This is quite important in financial transactions where someone may wish to refuse a bill claiming that they hadn t requested the service in the first place. Using a system that provides non-repudiation, the service or data provider can produce irrefutable evidence that the request was made and the bill is legitimate. Sensitive data stored on a network requires policies to administer access rights. The authorization services provided by a PKI enables an administrator to ascertain access privileges of an entity before allowing them access to the data, or even before verifying the existence of the data. A PKI can meet the five requirements for digital security: entity authentication, non-repudiation, data integrity, data confidentiality and access control. Cryptographic theory is the basis upon which the PKI creates this secure environment. By meeting these security needs, a PKI is a very effective tool to provide trust in networks in both intranet, extranet and Internet environments. RSA Security Inc. 1
III. Introduction to Certificate Authorities One of the most important questions involved in setting up a PKI has to do with how you know whom you should trust. Distribution of the public and private keys as well as how to verify users identities are additional important issues. Certificate Authorities (CAs) are at the heart of a PKI and play a major role in answering these and many other questions that arise. For an organization to be able to reap the benefits that public key cryptography has to offer, public keys must be accessible but at the same time protected from tampering and transmission errors. Digital certificates provide the vehicle to address these issues. CAs in turn are the delivery and administrative mechanism for digital certificates. A digital certificate is a file containing information identifying a user and their public key. A CA is the trusted third party that verifies and binds together this information. A user wishing to take part in a particular PKI generates a public/private key pair. He/she then enrolls in the PKI by supplying the CA with an authentic copy of the public key and some information identifying herself. The CA, when it has verified the supplied data to its satisfaction, digitally signs the information with its own private key. The CA s signature combined with the data supplied by the user is known as the digital certificate. At this point anyone who receives a certificate and trusts the CA can trust that the user who supplied the certificate is who they say they are, and that the public key contained in the certificate belongs to the certificate owner. Certificate Authority Architectures The architecture of the PKI must also be determined. If there is to be more than one CA in a PKI, the PKI system administrator has to decide whether to use a hierarchical model, a peer-to-peer model or a hybrid model when designing a PKI. Hierarchical Model In the hierarchical model there are levels of CAs, each subordinate to a superior CA with the root representing the first, or top level of the PKI model. Each CA has a certificate signed by the CA directly superior to it except the root. The root CA has a self-signed certificate. Since a certificate must be signed, and since there is no CA superior to the root CA, the root simply signs its own certificate. This model of PKI has a defined chain of trust involved and provides optimal PKI security. This reduces the margin for human error or accidental redundancy. Root CA Primary CA Subordinate CA Subordinate CA Subordinate CA A Hierarchical CA Model RSA Security Inc. 2
Peer-to-Peer Model A peer-to-peer model consists of two or more self-signed CAs from which users may request and receive certificates as well as status queries. The CAs in this model may be configured to trust certificate status information from their peers. Thus, a certificate signed by one CA may be accepted as valid or rejected, depending on the status information available, by a hierarchically separate CA from the PKI. This model of a PKI provides more flexibility in regard to the organization of CAs but requires a strictly enforced security policy to maintain good security. Hybrid Model The hybrid model incorporates a combination of hierarchical and peer-to-peer CA architectures to accomplish the security goals of a particular organization s needs After signing a digital certificate, the CA takes on the responsibility for the maintenance of that certificate. A certificate has an expiration date, determined by the CA, after which the certificate is no longer valid. An event may trigger the need to revoke the certificate prior to its expiration date. For this reason, the CA can revoke the certificate at any time and remove its trust associated with the certificate. Each CA plays a key role in a PKI system. It maintains a chain of trust from one user to another. It is important that the maintenance of this trust chain be performed regularly and kept up to date. The RSA Keon CA is engineered to provide a simple, user-friendly way to maintain this trust chain while ensuring the security of a network. Root CA Other Primary CA A Peer-to-Peer CA Model Primary CA A Hybrid CA Model RSA Security Inc. 3
IV. RSA Keon Certificate Authority The RSA Keon CA is designed to issue, manage and validate digital certificates. The software includes secure administration, enrollment, directory and logging servers. The RSA Keon CA also is designed to feature a powerful signing engine for digitally signing end-user certificates and system events as well as an integrated data repository for storing certificates, system data and certificate status information. The RSA Keon CA is engineered to publish to lightweight directory access protocol (LDAP)-compliant directories or external databases for certificate storage and sharing and has a built-in online certificate status protocol (OCSP) responder that is built to conform to industry standards and provide critical real-time certificate status checking to help ensure that a certificate is still valid for use. The RSA Keon CA comes equipped to create an enterprisewide PKI, or to incorporate an existing PKI into a new and larger PKI. The enrollment and administrative interfaces are designed to be intuitive and enable an easy learning curve during deployment. The RSA Keon CA comes equipped to handle cryptographic hardware tokens. Based on open standards for the greatest possible interoperability, the RSA Keon CA is designed to create and trust certificates and certificate extensions supported by the X.509 standard. X.509 is the industry standard that describes a basic certificate format. The central components of the RSA Keon CA s architecture are the administration server, the enrollment server, the secure directory and the logging server. These servers can, and usually do, reside on the same machine. The administration server is used to administer the PKI. Users apply for a digital certificate via the enrollment server. Certificate requests, issued certificates and access control lists are stored in the Secure Directory to help ensure that they are kept from harm. The logging server can be configured to record the actions of the administrators, the requestors and other users to varying degrees. The RSA Keon CA is designed to support all three PKI models previously mentioned (hierarchical, peer-to-peer, hybrid) to provide security in a flexible manner. Not only can the RSA Keon CA support these models, if the PKI model needs to be altered after it has been created, the RSA Keon CA can change the hierarchy as required. For example, if a subordinate CA in a hierarchy needs to be changed to become a peer, that CA would simply sign its own certificate to be removed from the hierarchical model to become a selfsigned CA. To incorporate a self-signed CA into a hierarchy, the administrator would simply sign the certificate belonging to the CA that is to become a subordinate using the public key of the CA that is to be the superior. Once this has been accomplished, the change has been made, and the CA has become a subordinate to the signing CA. In today s dynamic business environment with organizational restructuring, integration with business partners and the formation of new business units, this is a feature that helps allow security to adapt to changing needs. Secure Directory Server Cryptographic Signing Engine Logging Server Database SSL-LDAP SSL-LDAP SSL SSL-LDAP Web Server OCSP Responder Administration Server Enrollment Server SCEP Server https https Administrator User The RSA Keon CA Architecture RSA Security Inc. 4
The Administration Server PKI administrators use a Web browser to connect securely over an HTTPS connection to the administration server. This allows access to RSA Keon CA functions. Divided into four separate sub-interfaces called workbenches, the administration interface is designed to allow the administrators to perform certificate operations, CA operations, administrator operations and system configuration from a Web browser. The functionality of these workbenches is covered in the following sections. Certificate Operations Workbench The certificate operations workbench is the area where administrators process certificate requests as well as perform the ongoing maintenance requirements for existing certificates. An administrator connected to the certificate operations workbench can view all of the requests for certificates, and may choose to approve, deny, delete or defer the request. Approving certificate requests may be automated in the RSA Keon CA or it may be transferred to an administrator who is assigned to the task. Previously issued certificates can also be viewed and managed from this workbench. An administrator can view, re-sign revoke or suspend existing certificates. Approving a request passes the certificate request to a CA to sign and issue the certificate. Denying a request stores a copy of the request in the secure database but does not grant the signed certificate to the applicant. Deleting a request simply removes the request and all records of it from the queue. This is useful in the case of a test request or in the case of a request submitted to the wrong CA. Deferring a request neither denies nor approves the request. Rather, it removes it from the request queue to be handled at a later date. This feature is useful, for example, when using multiple administrators in the approval sequence. The request could be deferred until the next administrator is available to process the certificate request. The administrator may wish to view a certificate that has been issued in order to verify that the certificate is still valid or to obtain some information from the certificate that is necessary for specific access control. A certificate might need to be re-signed if, for example, the expiration date of the certificate is approaching but the end of the relationship between the user and the CA is not yet over. A circumstance, such as a late service payment, may result in the administrator needing to suspend the certificate. Suspension removes the privileges of that certificate temporarily. The certificate may be reinstated and the certificate holder will once again have full use of the certificate. Some events, for example the compromise of the private key, will require the revocation of the certificate. Revoking permanently removes the privileges of a certificate. Certificate Validation Certificate Revocation List (CRL) The RSA Keon CA is designed to provide the PKI with several options for checking the status of a certificate. The most widely used method for checking certificate status is through the use of a Certificate Revocation List (CRL). With a CRL, a list of certificates that have been revoked is produced periodically. When a certificate is presented to an application, the application checks the certificate presented against the CRL. If the certificate is on the CRL, the user s request is rejected. If the certificate does not appear on the CRL, the application assumes that the certificate is valid, and grants the user the appropriate access. While the use of CRLs is currently the most widely deployed method, there are some challenges associated with using them. Since CRLs are published and then the application checks them, there is the possibility that a certificate may have expired since the last publication. This means that someone may still be granted access to data even though their certificate had been revoked, as the revocation will not present itself to the application until the next iteration of the CRL. In some cases a delay in certificate revocation is acceptable, if the data available is not overly critical. However, in many e-business scenarios, if a certificate has been revoked and there is a delay a malicious user could do significant damage before the next CRL is published. In the case of an employee leaving a company after years of good service for personal reasons, then a CRL may provide sufficient security. If a contract between companies is terminated, and there are sensitive documents that must be protected, a more immediate solution is required. Certificate Validation Online Certificate Status Protocol (OCSP) While CRLs have traditionally been the method for checking certificate status, a newer method is the use of online certificate status protocol (OCSP). OCSP is an industry standard messaging protocol for formatting certificate status information. OCSP simplifies the status checking process by providing a central location for CRLs, rather than having CRLs distributed to multiple applications. Instead, an OCSP responder provides the application with information on the certificates in question by retrieving a CRL from the CA. While the status returned using OCSP may be more timely than using a standard CRL, there is still the difficulty with the fact that the CRL may reflect out-of-date information. For example, the termination of a contract may now be handled using OSCP, as the time between the contract s end and any action taken to access the sensitive data may well be sufficient for the CA to generate an internal list of revoked certificates. However, a certificate used for financial transactions may be used improperly to spend a large amount before the CA has time to regenerate that list. RSA Security Inc. 5
Certificate Validation Real-time Certificate Status Check The RSA Keon CA is designed to check the status of certificates not only online but also in real-time. The CA s OCSP responder has been engineered to have the ability to query an RSA Keon CA certificate directory directly, returning with up-to-the-instant certificate status. As soon as the certificate is revoked, the user will be unable to login and will be denied access to all restricted areas the certificate had permitted access to previously. This effective implementation of the OCSP standard helps address the liabilities around data latency. Andrea 1. Certificate issued Andrea s CA 2. Certificate sent www.philsflowers.com Real-time Online Certificate Status Checking 3. Check certificate s validity CA Operations Workbench From the CA operations workbench, the administrator maintains the relationships of the CAs with respect to each other. It is from this workbench that local CAs are created and viewed, that external CAs are trusted or CAs are imported into the PKI. CA certificates can be replaced, exported to another PKI or downloaded from the workbench. Active and revoked certificates can also be viewed. Creating a local CA is designed to be a straightforward process that involves filling out a form and providing information such as the common name of the CA to be created, whether the CA is to be self-signed, or part of a hierarchy, the location of the CA and and the validity period for the new CA. Once the form is completed and the CA is created, the resulting CA information is available from the CA operations workbench. If trust is to be extended across particular CA infrastructures, the CA operations workbench is used by the administrator to verify which external CAs are to be trusted. Also, if CAs, local or external, are to be brought into an existing CA infrastructure administrated by a particular RSA Keon CA installation, the CA operations workbench can be used to import the appropriate CAs. System Configuration Workbench The system configuration workbench is designed to provide the administrator tools for generating access control lists, and configuring logging options. From this workbench the administrator may choose what actions are to be logged. It is also the place where access to various files and directories on the CA, or another Web server, may be defined. When generating an access control list, the administrator may choose a graphical rule generator that fills in the required syntax using keywords. Alternatively, the administrator can enter the rule syntax directly. This rule, once saved, either explicitly or implicitly grants access to each certificate or group of certificates. RSA Security Inc. 6
Administration Server Workbench All of the features above, in combination, are designed to provide the administrator with a very powerful, yet easy-touse tool for administrating the PKI. All of the access for end users, CAs and administrators can be granted, restricted, suspended or revoked using the tools found in the administration server. The RSA Keon CA is built to employ a role-based approach to the administration of the PKI, allowing for the delegation of authority. A good example of this is the group of administrators responsible for the verification of end user certificate requests. These administrators may be restricted from accessing the system configuration workbench, for example. Another role that may be defined in the PKI may be that of a PKI administrator. A PKI administrator could have the ability to reissue CA certificates and approve and issue administrator and issuer certificates, while other administrators may not have the ability to perform these sensitive functions. These PKI administrators would have access to the administrator operations workbench where these functions are performed, while other parties in the PKI would have their access restricted. The first end-entity certificate with full administrative access to the PKI is issued in real-time during the installation of the CA. The Enrollment Server The enrollment server is the most highly visible part of the RSA Keon CA from the point of view of an end user. Each person who wishes to have a certificate must use the enrollment server to obtain one. The form presented to the end user is designed to be customizable not only in the information fields to be filled out, but also in appearance. The enrollment server can be branded to adhere to the image or graphical requirements appropriate for an organization. To the end entities who wish to be enrolled in the PKI, the enrollment server is the most important aspect of the RSA Keon CA. A user who wishes to have a public key registered in the PKI connects to the enrollment server using a Web browser and an HTTPS connection. He/she is then presented with a straightforward form into which he/she enters the data required for certificate approval purposes and submits the request. A key pair is generated during this process on the client s computer, smart card or smart token, and the public key is transmitted to the enrollment server to be signed when the request is approved. The private key does not travel over the communication lines at all; rather it is stored directly on the client s computer or token. The submitted request is processed by an administrator from the administration server, and upon approval an e-mail is automatically sent to the requestor indicating a URL where the signed certificate may be retrieved. The Secure Directory Server The secure directory server is engineered to be where all the certificates, certificate requests and access control lists are stored to be accessed by the RSA Keon CA. External applications needing access to this directory are granted readonly access through a lightweight directory access protocol (LDAP) connection. The RSA Keon CA s Administration and enrollment servers that need access to write to the secure directory, connect using a SSL-LDAP connection to help ensure data integrity and security. Using the SSL-LDAP connection, the Secure Directory Server may be implemented with certificate based access control. The secure directory server is also where the RSA Keon CA s signing engine is housed. The rules for accessing the signing engine can be defined for each CA involved. This yields the flexibility to mirror business operations as well as handle scalability issues. The RSA Keon CA s secure directory server is designed to provide token support for the use of hardware security modules (HSMs). The link between the secure directory server and the HSMs is designed to integrate fully into the secure directory server. An HSM may be used to provide tamper resistant protection for the private keys and to perform signing operations outside of the software environment. The Logging Server This server is accessible by the other three servers to record activity in each of the areas as specified by the administrator. For example, the administration server may be required to log each time a certificate is revoked or the secure directory server may be required to log the time and name of the entity involved whenever data is written to the database. The logging configuration will reflect the organization s audit requirements. RSA Security Inc. 7
RSA Keon Registration Authority A registration authority (RA) works with the CA to help streamline the enrollment process for handling large volumes of end-user certificate requests. The RA component enrolls clients by extending the approval process for certificate issuance. The is an optional module designed to work with the RSA Keon CA to verify the credentials of certificate requests and to provide certificates to the requestor. The RA helps enable organizations to set up either remote or local standalone enrollment centers for large user implementations at distributed geographic locations. This allows the organization to scale its certificate management system while moving the approval process closer to the users to help minimize the risk of approving certificates to unauthorized parties. is built to contain the same architecture and functionality as the RSA Keon CA, except that it cannot sign certificate requests. Certificate requests must be passed to the RSA Keon CA for signing. Approved certificates can then be issued to the user by either the CA or RA. The RSA Keon CA database remains the primary storage and lookup location for issued certificates, although a copy of the certificate is also stored with. Although the RSA Keon CA can have multiple RAs attached to it, each instance of RSA Keon RA can only process certificate requests for one CA. is designed to give an organization the flexibility to deploy their PKI to suit their particular needs and structure. And, when that structure changes in the future, the organization can easily re-configure their PKI as needed. Despite the fact that is being run remotely, an organization retains central control over the certificate issuance process. Since the RA works in conjunction with the RSA Keon CA to issue certificates, policies enforced at the CA will be carried over to each RA. RSA Keon CA RSA Keon CA Administrator SSL-LDAP HTTPs is designed to allow an organization to build a secure, distributed PKI that mirrors their organizational structure. RSA Security Inc. 8
RSA Keon Key Recovery Module Many companies deploying a PKI must be able to retrieve encrypted data as part of their disaster recovery operations or to meet regulatory requirements. For example, through a hard disk crash, an employee s private encryption key may be destroyed and the employee may need a way to recover this key in order to access encrypted e-mail. In the finance and healthcare industries, there are regulations that mandate minimum storage and retrieval periods for certain data. The challenge is to sustain tight security while complying with business or regulatory requirements. The RSA Keon Key Recovery Module (KRM) helps meet this challenge. The RSA Keon KRM is an optional module used with the RSA Keon CA. The KRM is designed to provide a way to securely archive and recover encryption keys of users, helping eliminate the risk of serious data loss in the event that the encryption key is lost, misplaced, corrupted or if a user leaves an organization. The KRM automatically adds an encryption key option to the RSA Keon CA enrollment process. During enrollment, the user simply accesses a specified URL through the Web browser and downloads a certificate. The user then selects the encryption key option and a second key pair/certificate is obtained. The first-issued authentication certificate is used as identification for obtaining the private encryption key and certificate. The private encryption key is centrally generated on the hardware security module and then securely distributed to the end user along with the encryption certificate. The most effective way to help insure the protection of business-critical private encryption keys is to remove them from the server and store them in secure hardware. The RSA Keon KRM is engineered to utilize ncipher hardware security modules for the generation and archival of private encryption keys. The KRM s archived private encryption keys are kept strongly encrypted in secure storage. This is designed to prevent that even a compromise of the server s operating system file protections will not jeopardize the security of the key database. RSA Keon WebSentry Plug-in Often to control access to a Web site or to specific areas of a Web site, an organization will use IP address restrictions, user names and passwords. These methods are at best a rudimentary way of implementing security, as intelligent IP spoofing or user name/password distribution lists are simple ways to get around the access problem. The RSA Keon WebSentry Plug-in is an optional security solution that is designed to work with the RSA Keon CA to enhance the certificate handling capabilities of a Web server. Because WebSentry verifies a client s certificate through the RSA Keon CA, the validity of the certificate is checked each time access is requested. This helps provide a zero tolerance approach to user authentication and access. Access control lists can be implemented that dictate exactly to what an end user does and does not have access. Comprehensive logging options allow the administrator to keep an eye on user activity. With no end-user software required, other than a Web browser, the RSA Keon WebSentry Plug-in is a simple tool to build upon an organization s existing security structure. Secure e-mail Module RSA Keon digital certificate management software is designed to provide seamless integration support for secure e-mail with Microsoft Exchange Server and Microsoft Outlook messaging and collaboration clients. RSA Keon CA software is designed to enable end users to encrypt and digitally sign important e-mail communications including attachments so that only intended recipients can access the message. e-mail is an instrumental and convenient part of our business lives, but it is not without some inherent risks. Unprotected, e-mail messages can be opened, forwarded or tampered with by unauthorized people. By integrating RSA Keon digital certificate management software with Microsoft Exchange Server and Microsoft Outlook messaging and collaboration clients, RSA Security has helped ensure the confidentiality and integrity of information exchanged between parties. The Secure e-mail Module is designed to enable organizations to: Implement an easy to deploy, seamlessly integrated, secure e-mail solution across the enterprise that requires no client software other than a standard Microsoft Outlook e-mail client, Automatically set configuration for signing and encrypting e-mails when users enroll for certificates this ease-of-use feature helps eliminate the need for users to configure e-mail clients and denote which certificates are to be used for signing and encryption, Insert sign and encrypt buttons on the user tool bar, helping enable easier signing and/or encrypting of e-mail communications and Publish certificates into the Microsoft Exchange Server Global Address List (GAL), helping enable the sending of secure e-mail from any user in the system to other users without prior interaction. RSA Security Inc. 9
V. RSA Keon CA Scalability A PKI solution must be able to deal with a large user base without adversely affecting the performance of the system. In the case of an Internet-oriented business, the number of potential users is limited only by the online population. Using the facilities at the Sun Microsystems iforce TM Ready Center in Menlo Park, California, the RSA Keon CA has been proven to scale to over eight million certificates without a noticeable reduction in system performance. These tests illustrate the RSA Keon CA s scalability and ability to address real world Internet-based deployments and not just limited pilots. Summary About RSA Security RSA Security, the most trusted name in e-security, helps organizations build trusted e-business processes through its RSA SecurID two-factor authentication, RSA ClearTrust Web access management, RSA BSAFE encryption and RSA Keon digital certificate management product families. With approximately one billion RSA BSAFE-enabled applications in use worldwide, more than twelve million RSA SecurID authentication devices deployed and almost 20 years of industry experience, RSA Security has the proven leadership and innovative technology to address the changing security needs of e-business and bring trust to the online economy. RSA Security can be reached at www.rsasecurity.com. From user enrollment, to PKI hierarchy, to certificate management, the RSA Keon CA is designed to be a complete, standards based, PKI solution that is easy to roll out to an enterprise as is, or may be further extended to encompass particular requirements of an organization. Web-based and easy to use, the RSA Keon CA is engineered to be a practical tool for helping ensure the data integrity, confidentiality, non-repudiation, access control and proof of identity necessary in today s workplace. The RSA Keon CA provides the infrastructure and security required by today s digital information and networking environments. BSAFE, ClearTrust, Keon, RSA, RSA Security, the RSA logo, SecurID and The Most Trusted Name in e-security are registered trademarks of RSA Security Inc. All other trademarks mentioned herein are the property of their respective owners. 2002 RSA Security Inc. All rights reserved. KCATO WP 0702