CLIP:An Online PKI Management Function
CLIP is a new function of Trust-CANP, which is a PKI-based electronic certification system available from NTT. It is designed to reduce operating costs, one of the barriers to widespread adoption of the public key infrastructure (PKI) scheme, by providing services online to both end users and operators, while also making it more convenient for these users.
1. Authentication technology and PKI
In order for the Internet to be used as part of the social infrastructure, it is very important to have technology that can conclusively confirm with whom we are communicating, or who created any particular digital data. The public key infrastructure (PKI) scheme is one such type of authentication technology. PKI provides an infrastructure for authentication using public-key cryptography. With PKI, a trusted third-party authority issues a public key certificate that verifies the relationship between the key and its holder. Authentication can be carried out by verifying the public key certificate and a digital signature created by the other party. In Japan, this operation can be easily understood by regarding a public key certificate as the counterpart of a registered seal in the real world and by regarding a digital signature as the impression of a seal.
2. Certificate Authority system
A Certificate Authority (CA) is an entity that issues public key certificates. The CA is composed of the Issuing Authority (IA), which has the role of issuing and revoking public key certificates and issuing a list of revoked certificates, and the Registration Authority (RA), which accepts applications, verifies the identities of end-users, and manages end-user information, as shown in Fig. 1. The IA generally issues public key certificates in the standard format specified in RFC 3280, but the RA functions vary according to the individual product or system.
NTT Information Sharing Platform Laboratories is developing Trust-CANP ,  as a CA product. Its RA function uses an issuing method that accepts only off-line constituents and is limited to handling fixed combinations of user data. Most of the applications of this product so far have been in the public-sector field.
3. Difficulties with PKI
With the RA function of most traditional CAs, such as Trust-CANP, aspects like the user data and application procedure are fixed, so these CAs are difficult to use when there is wider variation in the type of user data or a variety of application procedures for issuing public key certificates. Traditional RAs have not been suited to private services because the level of requirements in these areas tends to be high.
Moreover, operational costs tend to increase for systems operating off-line, which is also not always compatible with cost-conscious private services, and the extra burden on users of acquiring a public key certificate through an off-line process can be a reason for avoiding PKI.
In particular, a significant obstruction to the adoption of PKI is the increase in the variety of applications and devices providing PKI functions, such as Web browsers, email programs, and network routers along with the variety of public key certificates required for each of them. This is adding another layer of burden to the acquisition of public key certificates.
4. Implementing an online CA with CLIP
NTT Information Sharing Platform Laboratories believes that extending the functions of the RA in the ways shown in Fig. 2 will be an effective way to resolve the issues discussed in Section 3. Based on the above-mentioned ideas, it is developing CLIP (customizable lightweight identity profiler) as a new function of Trust-CANP. A comparison of traditional RA functions and CLIP is given in Table 1.
CLIP differs from traditional RAs by enabling online operation via the Internet instead of requiring off-line procedures for the initial contact. It can issue various types of public key certificates effectively with various combinations of user information because it manages the user data required for the certificates flexibly, according to the requirements where the certificate is to be used. These characteristics satisfy the direction of end-user-oriented online support shown in Fig. 2. Extending it further to provide full online support will make possible an online CA system yielding improvements in both convenience and operational efficiency.
5. Architecture and characteristics of CLIP
An example of a typical system architecture using CLIP is shown in Fig. 3. The role of CLIP is to provide the RA function for Trust-CANP. The CLIP main server manages user information and processes the issuing and revoking of public key certificates through its link to the CANP server, which provides the IA function. The CLIP wrap server provides user access as well as functions for issuing and downloading public key certificates. The main features of CLIP are as follows:
(1) It handles a variety of types of user data used to issue public key certificates.
(2) It can link to multiple CAs.
(3) It can verify requirements for issuing a certificate based on a public key certificate.
(4) It can issue multiple and various types of public key certificates online.
(5) Certificates can be distributed to users and imported into terminals automatically.
CLIP handles user data including the key, public key certificate, and personal data as generalized attribute data. In so doing, it can handle information that will not all be stored in the public key certificate (like user classification or contract information) more flexibly, providing specialized functionality that can meet the various needs of private-sector services.
As shown in Fig. 3, users can use multiple CAs in a centralized way through CLIP, so multiple certificates can be managed together, and certificates can be issued based on verification using other, already-existing public key certificates. In addition to this feature being used for renewing a public key certificate, it can also be applied to the process of issuing new, different certificates in a linked fashion. An existing public key certificate (the primary certificate) would be used to verify the requirements for issuing the new certificate (the secondary certificate), as shown in Fig. 4. For example, this will allow modes of operation, using PKI, much like when a membership certificate (“Employee ID” in Fig. 4) is issued based on verification of a person's identity using more-widely used means such as a driver's license (“Certificate used for company services” in Fig. 4).
Public key certificates can also be automatically imported into a terminal's certificate store (or the Windows* certificate store) when they are downloaded by the user. Users do not need to install any additional software on their terminal in order to use this function. If this function is combined with a public-key-certificate-issuing portal service, users can be provided with the public key certificates they need in an online, low-cost, and timely manner.
CLIP also provides practical functions for issuing X.509-attribute certificates and for sending email notifications to users for new registrations and when certificates need to be renewed.
6. Example of a CLIP Installation
NTT is using CLIP in a trial operation (Fig. 5) to provide a public key certificate issuing service for certifying users of other in-house services. For this service, all employee user accounts were created in CLIP at once, based on data already in the employee database.
Employees can easily download public key certificates using only a Web browser, as shown in the screen-shot in Fig. 6. The certificate is automatically stored in the certificate store of the user's terminal when it is downloaded, so compared with conventional procedures in which the user first downloads the file containing the public key certificate and then manually imports it, this system is extremely simple to use. Moreover, users are automatically notified by email when the certificates need to be renewed, and they can perform the update online by themselves, so no operator intervention is required.
At this time, the number of services using public key certificates to verify users is quite limited, and services supporting PKI are not advancing due to the cost barriers of issuing public key certificates. However, if procedures are established within the system to distribute and renew public key certificates at a low cost, this situation will be improved, which should stimulate the appearance of more services using public key certificates.
7. Future developments
To further encourage the spread of PKI in the private sector, it will be necessary to address demands for even greater cost reductions. In particular, one approach that could effectively provide further cost reductions by centralizing facilities and operations is to create an outsourced CA, by contracting out the system operation in an application service provider (ASP) format. Then, by providing an online interface for operators together with end-users, we hope to provide an even more enhanced online CA. Of the main functions of the CA authority, only the application-handling functions will remain in the organization; the rest will be concentrated at the outsourcer. Application handling depends heavily on the structure and operational policies of the organization, but we plan to include functions for a variety of application procedures and ways of allocating roles.
Furthermore, information specific to the issuee (e.g., name and address) is part of what is certified by the public key certificate, so this information is required by both the applicant and the person assessing an application. Thus, there is a need in various circumstances to reference and verify user data that is specific to the organization where the system is being used. Because of this, we are also considering further facilitating the adoption of PKI by expanding functions that link to the organizations' systems, allowing management of issuee data and automatic assessment of applications to be done based on existing user databases.