Previous     Contents     DocHome     Index     Next     
Portal Server Plug-in for the Identrus System 2.0 Installation, Administration & User Guide



Introduction


This Chapter discusses the main components that are required to participate in the Identrus Scheme. It explains how the iPlanet Portal Server Plug-in for the Identrus System facilitates secure email messaging. The objectives of this chapter are to provide an overview of:

  • Layout of the guide

  • The Identrus Scheme itself

  • SmartCard Users wishing to logon and check their email via the Portal Server

  • Certificate Status Checks done either via the Identrus scheme or by an appropriate Certificate Authority


Related Documents


Overall Layout

The document is intended to assist Three kinds of users:

  • An email User who will need to check his/her mail and perform certificate status checks.

  • System Administrators who may be a bank employee or your Local Product Support Representative, both of whom must be able to install, configure and maintain the system.

  • Developers wishing to deploy their own applications within the Portal Server that are also Identrus enabled.

The document comes in four parts:

  • Chapter 1 Installation runs through special considerations over and above those mentioned in the iPlanet Portal Server 3.0 Installation Guide

  • Chapter 2 Administration is intended for Administrators setting up Netmail users, assigning certificates and defining Certificate Status Check Responders.

  • Chapter 3 User describes: Logging on using a Smart Card, Digitally signing email messages and the general management of secure messaging.

  • Chapter 4 Deploying Applications illustrates how to develop the source code necessary to perform an Identrus enabled Certificate Status Check.


About the Identrus Scheme

Identrus was formed to establish and operate a highly secure system for identifying parties over electronic networks, including the Internet. Identrus is comprised of regulated financial institutions coming together to combine the basic technology provided by public key cryptography and PKI with adherence to a common set of operating rules that facilitate electronic commerce.

The "Four Corner" model, as depicted below, forms the basis of the Identrus PKI network.

Figure 1    Identrus Four-Corner Model

The four corners consist of:

  • Issuing Participant - Bank (or other financial institution) issuing smart cards containing private keys and certificates to Subscribing Customers.

  • Subscribing Customer - Member of the Issuing Participant bank authorised to participate in Identrus activities.

  • Relying Customer - Party with whom the Subscribing Customer initiates a signed transaction.

  • Relying Participant - Bank with which the Relying Customer communicates to obtain some level of trust in the signed data received from the Subscribing Customer.

A typical transaction using the Four-Corner Model includes the following steps:

  • The Subscribing Customer uses his/her SmartCard to sign a transaction request that the system sends to the Relying Customer.

  • The Relying Customer verifies that the signed data came from the Subscribing Customer and was not modified in transit.

  • The Relying Customer requests services from his/her bank; for example, he/she can ask its bank to perform a status check on the Subscribing Customer's certificate to make sure it is still valid (has not been revoked).

  • The Relying Participant requests services of the Issuing Participant and the Identrus Root to fulfill the Relying Customer's service request.

  • Based on the response from his/her bank the Relying Customer fulfills or rejects the request from the Subscribing Customer.

In order to accommodate the Identrus Scheme, the iPlanet Portal Server Plug-in for the Identrus System utilises a host system connected to the Portal Server as illustrated below:

Figure 2    iPlanet Portal Server and the Identrus Scheme


iPlanet's Portal Plug-in solution


The iPlanet Portal Server Plug-in for the Identrus System is designed for those Developers, Users and Administrators wishing to achieve reliable messaging when sending and receiving email messages. Messages gain meaning if in some way they have:

  • Authentication i.e. You know who your email message came from

  • Integrity i.e. You know your email message has not changed

  • Non-repudiation i.e. The sender cannot disavow the message

The iPlanet Portal Server Plug-in for the Identrus System utilises:

  • A digital signature

    to achieve integrity

  • A certificate

    in order to validate the sender of a message

If and only if there exists both a valid digital signature and a verified certificate can we say that a message be non-repudiable. Without these mechanisms in place this cannot happen, and as such, the purpose of this document is to explain the main components associated with:

  • Firstly configuring a system so that appropriate trusted certificate hierarchies are in place to authenticate messages via a certificate status check.

  • Secondly how users should view appropriately messages, containing digital signatures and certificates, that they receive and send.

  • Thirdly how developers can deploy their own applications that are Identrus enabled

The iPlanet Portal Server Plug-in for the Identrus System achieves these aims by attaching the above icons to all email messages sent and received within the email message header summary of NetMail Lite. Thus, allowing the user the ability to determine the status of each message received and also to send messages with integrity if they so wish.

Figure 3    Example Message Header


Inside an Identrus SmartCard


Part of setting up the iPlanet Portal Server Plug-in for the Identrus System involves issuing users with a SmartCard. Every Smart Card contains certificates that has an Identrus Hierarchy that defines which users can logon to the Portal Server as illustrated below.

Figure 4    A SmartCard illustrating its Certificate Hierarchy

If a chain of trust can be built between a specific SmartCard certificate and a trusted CA, the certificate can be trusted (by inference). In such circumstances, any user that is an Identrus member can log onto the Portal Server, provided the administrator, for the Identrus member, sets an appropriate Certificate to contain an Identrus Certificate hierarchy.

In order to become Identrus-enabled, the following certificates are needed:

  • An Identrus enabled Identity Certificate that provides information about who the user is.

  • An Identrus enabled Utility Certificate that provides information about what access the user is authorised to have.

  • An Identrus enabled Identity Certificate Authority Certificate that issues the users identity.

  • An Identrus enabled Utility Certificate Authority Certificate that issues the users utility.

  • Identrus Root Certificate


The Identrus Certificate Scheme

Administrators wishing to install the iPlanet Portal Server Plug-in for the Identrus System need to be aware of the main components that go into enabling users to achieve these aims. The diagram below illustrates an example of how messages typically might be validated and checked for integrity using certificates that have been issued by appropriate certificate Authorities within the Identrus Scheme.

Figure 5    Overview of Certificate Verification for the Identrus Scheme

In order to achieve these aims of authenticating email and sender/recipient integrity, three kinds of certificates are needed for the Identrus Scheme:

  1. Application Authorisation Certificates

    • Trusted Login CA Certificate. This is normally the Relying Participant Bank under such circumstances only customers of the RP Bank can login. This certificate is used for Verification purposes.

    • Trusted Email Certificate. This is normally the Identrus root itself and under such circumstances all email received by any Identrus member can be validated.

  2. Certificates for Certificate Status Checks

    • Request Signing Certificate. Outgoing, from RC Host to Identrus CSC or OCSP, status checks are signed by this certificate.

    • Response Signing Certificate. Signing certificate is used to sign the status messages returned to the RC host's user.

    • Trusted Response Verification Certificate. The Certificates used by the RC host to verify responses, whether they are OCSP or Identrus CSC.

  3. Certificates for Transport Authentication and Integrity

    • SSL Client Certificate. Signs the SSL transport handshake between client and server.


Previous     Contents     DocHome     Index     Next     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated May 16, 2001