Previous section.

Common Security: CDSA and CSSM
Copyright © 1997 The Open Group

Multi-Service Modules

CSSM APIs are logically partitioned into functional categories. The goal of this logical partitioning is to assist application developers in understanding and making effective use of the security APIs. To this end, the partitioning has been effective.

Vendors providing add-in security service modules are developing products that provide services in more than one functional category. Vendors may not want to partition their products in this manner. More pointedly, they can be unable to do so. Consider a class 2 PKCS#11 cryptographic device. This device performs cryptographic operations and provides persistent storage for keys, certificates, and other security-related objects. These services are logically partitioned between the CSP-APIs and the DLM-APIs. Implementing two separate add-in modules is not feasible. In order to provide correct service, the two modules must share execution state, such as PKCS#11 session identifiers. Additional examples exist, as shown in A Multi-Service, Add-In Module .

Figure: A Multi-Service, Add-In Module
Serving Three Logical, Functional Categories

Multi-service add-in modules separate module packaging from the application developers functional view of CSSM APIs. A multi-service module is a single, dynamic add-in module that implements CSSM functions from two or more functional categories of the CSSM APIs.

Application Developer's View of a Multi-Service Add-in Module

Application developers must have some (but limited) visibility into the organization of the service provider modules available through the CSSM framework. Knowledge of underlying implementations should be kept to a minimum.

Applications attach a multi-service module as they would any other module. The attach function returns a handle representing a unique pairing between the caller and the attached module. The caller uses this single handle to obtain any and all types of services implemented by the attached module. A Single Handle References a Multi-Service Add-In Module shows the handle for an attached PKCS#11 service provider that performs cryptographic operations and persistent storage of certificates.This single handle can be used as the CSPHandle in cryptographic operations and as the DLHandle in data storage operations.

Figure: A Single Handle References a Multi-Service Add-In Module

Multiple calls to attach are viewed as independent requests. Each attach request returns separate, independent handles that do not share execution state.

Before attaching a service module, an application can query the CSSM registry to obtain information about that module. A multi-service module has exactly one CSSM registry entry containing multiple capability descriptions. There are one or more capability descriptions per functional category supported by the module. Each set of capabilities includes a type identifier to distinguish CSPinfo from Clinfo, and so on.

Service Provider's View of a Multi-Service Add-in Module

A Multi-Service Module is a single product. It has a single associated globally-unique identifier (GUID). It's implementation may consist of several libraries, forming a single service.

When an add-in module is installed on a CSSM system, the module registers its name, GUID, and capability descriptions with CSSM. CSSM securely records this information in the CSSM registry (making it available for application queries). A multi-service module will register capabilities for each of the service categories supported by the module.

A multi-service module is not required to implement all of the functions in any functional categories. The CSSM dispatching mechanism invokes only to those interfaces registered with the CSSM.

Companion Modules

It can also be useful for a set of separate modules that interoperate to declare their interoperability. Such modules are referred to as "companion modules". Each can be a multi-service or a single service module. Modules register a list of companion modules with CSSM during module installation. CSSM records this in the CSSM registry with other information about the module. Applications can query this information about companion modules. The list is optional and if supplied, it is strictly advisory. Applications may ignore or use this information to their advantage. For example, a trust policy module for SET applications may register a companion CL module that manipulates DER-encoded X.509 certificates. Similarly, a DLM that implements access to an X.500 directory service may register the same CL module as a companion.
Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.
You should also read the legal notice explaining the terms and conditions relating to the CDSA documentation.

Contents Next section Index