The immediate goal is Managed FORTEZZA Access Anywhere.
Figure 1 shows the Token Management System in a typical operational scenario depicting strategic and tactical deployment.

Figure 1. shows that Token Management System Solution can operate in two modes: floppy disk based (or sneakernet)[1] and network enabled. The TMS components are identified in the figure. Additional details on the three (3) proposed configurations of these components are provided later in this document. A brief description of each TMS component and its relationship to the full TMS solution follows.

[1] [1] In this mode the contents of the floppy disk can be sent: (i) from the ECA to the T2CSS (VFC only) in the local (CAW) keying operation; or (ii) from CMART to ECA and back for the remote re-keying operation.

1.1.1 Enhanced CAW Adapter

The Enhanced CAW Adapter (ECA) is an intelligent card reader.  It is connected to the CAW over a SCSI interface.  The ECA is used to create and generate new tokens, keys and certificates under the control of the CAW and can also remotely re-key, renew, update and add to existing keys and certificates that have been previously deployed in the field.  Supported tokens include the T2CSS PCI board, T2CSS Virtual FORTEZZA Card (VFC), FORTEZZA PC card, Forte and Rosetta smart cards and USB devices.

The principal ECA user is the CA Operator. To the CA operator the ECA is a card reader with a two-line display that provides status information. Three action keys on the ECA (Enter, Cancel and Scroll) make up the ECA user interface.

The ECA has floppy disk and network interfaces that can communicate with organizational server applications (MLA, DA, etc.) or with the end user. Key/re-key request information is submitted by the T2CSS administrator or the end user and transferred to the ECA. It is assumed that the Certificate Request Form will be created through the registration process and then sent to the CAW and the CA Operator for processing. After keying or re-keying the ECA sends the token, keys and certificates back to the administrator or end user.

When the ECA is configured to use a network interface, it communicates with the Certificate Management & Registration Tool (CMART) that is running in the organizational server or the user workstation. CMART is used to complete the key/re-key request process including initiation and submission, and installation, tracking and monitoring.

1.1.2 Certificate Management & Registration Tool (CMART)

The Certificate Management & Registration Tool (CMART) is a user utility that runs in a Microsoft Windows environment and provides a Microsoft Management Console (MMC) interface to the user. It may be run on demand or as a background process on the T2CSS server platform or a user workstation. CMART uses Microsoft tools with which the user may be already familiar, and thus can eliminate or minimize the need for additional training. The CMART user will most often be the T2CSS Administrator or SA responsible for the T2CSS PCI board and the VFCs, but the CMART user may also be the owner of other FORTEZZA tokens (PC card, smart card or USB device).

The CMART provides a graphical user interface (GUI) that allows the user to perform the following functions:

• Provide data to facilitate token initialization, transit protection, etc. depending upon the keying or re-keying action to be requested. For example, the CMART provides the serial number of the T2CSS board to which a new VFC will be sent.

• Initiate a remote re-keying, certificate maintenance (add, renew, update, etc.) or card management (Copy or Restore VFC) action (with prior approval by the registration system).
• Visually understand and monitor the status of the FORTEZZA token and its keys and certificates. The CMART can check the status of all certificates on all tokens and alert the end user by displaying the certificate(s) due to expire within a preset time period (e.g., 45 days).
• Import and install tokens (VFC), keys and certificates that are sent to the user from the ECA.
• To support the placement of keys and certificates by the CAW/ECA in a remote re-key operation whether the CAW adds or overwrites.
• Display labels and certificate information for each installed token.
• Track the status of requests submitted to the ECA.
• Support installation of new infrastructure certificates (CA, PCA, and ICRLA).
• Inform the Token Manager of token changes as they occur.

The CMART interfaces directly with the ECA using the floppy (via sneakernet) for information exchange in either direction. In a network enabled TMS solution, CMART communicates with the Registration Manager and the Token Manager as described below.

1.1.3 Token Manager

The Token Manager (TM) facilitates keying and remote re-keying operations on the various tokens supported by the ECA. Conceptually, CMART sends requests to the TM and then the ECA pulls the request from the TM. The TM functions as a store-and-forward entity because network access and bandwidth may not be guaranteed at all times. It also makes unattended operation possible. The TM is closely coupled with the Registration Manager (RM) described below. The TM coordinates with the RM for each CMART request.

In addition to a store-and-forward capability, the TM also performs the following functions:

• Collects the data embedded in the CMART request and prepares it for the ECA.
• Receives the response to the CMART request sent by the ECA and forwards the token, keys or certificates to the appropriate CMART.
• Gathers token and certificate data at the source, i.e. sent by the ECA, when the token is keyed or re-keyed. Examples of such data are token serial number, CAW ID, ECA ID, public key (T2CSS board), etc. No sensitive data such as private keys, PINs or Ks is stored at the TM.
• Monitors and tracks certificate lifetimes and prompts the end user via the CMART on his workstation for appropriate action.
• Distributes PINs once an acceptable scheme can be established.
• Other functions and capabilities as the TMS evolves

The TM is a software component that runs unattended on a computer platform. Depending upon the organization’s deployment strategy, it can reside on the same platform as the Registration Manager and CMART. The TM can run unmanned and the data collected for tracking and monitoring can be dispatched to a central location that is manned with an administrator, i.e., an LRA.

1.1.4 Registration Manager

The Registration Manager (RM) is a software component designed to work with a network aware Token Management System to facilitate remote keying or re-keying.  The keying or re-keying action by the T2CSS Administrator or an end-user can only be requested once the registration process (manual hard copy or electronic as proposed in RAT2) has been completed, i.e., a Certificate Request Form is completely approved. The administrator or end-user will then initiate a request using CMART. The Registration Manager (RM) serves as a surrogate of the registration system. The RM keeps an account of the requests submitted by one or more CMARTs, and tracks their status.

The RM interfaces with both the CMART and the TM. The CMART interface as stated earlier provides the facility via the MMC to enter a request based on the registration information and the token and/or certificate (if it is a re-key request). Once the registration process is electronic, the RM will receive notification of completion and use this to validate the legitimacy of the request submitted by the end user via CMART. The RM receives this information and forwards the request to the TM. The RM is used only in the TMS solution that is network enabled. It is important to note that in the floppy disk (or sneakernet) mode, CMART sends the request and related information directly to the ECA.

The RM is required to remotely re-key tokens, keys and certificates. It runs unattended on the same platform as the TM or is connected over the network. The RM deployment concept will be further refined as other operational details are taken into account, such as the deployment of the CAW, the associated ECA and the community of organizations and users it serves. This functionality will evolve into an electronic registration system in the future.