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.