Previous section.

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

Data Storage Library Modules

The primary purpose of a Data Storage Library (DL) module is to provide secure, persistent storage and retrieval of security-relevant data objects such as certificates, certificate revocation lists (CRLs), keys and policy assertions. The persistence of these generic trust objects is independent of the memory-based manipulations performed by certificate library modules. DL modules may be invoked by applications, trust policy modules, or certificate library modules that make decisions about the persistence of these objects.

A single DL module may cooperate with a Certificate Library (CL) module or may independently manage the persistence of opaque objects. A data storage library that is coupled with a certificate library module may use information obtained from the CL in the implementation of a physical data storage and retrieval model. For example, a DL might interrogate a certificate to construct/use indexes to speed data retrieval.

Each DL module can manage any number of independent, physical data stores. Each data store must have a logical name used by callers to refer to the persistent data store. Implementation of the DL module may use local file system facilities, commercial database management systems, custom stable storage devices and remote storage facilities. A data storage module may execute and store its data locally or remotely.

Properties and capabilities of each storage device are managed by the DL Module Manager. Applications may hold multiple references to a single storage device. The DL manages open references as context handles to internal data structures and physical media. DL modules are not restricted from using caching or other performance optimization techniques. Processes and threads may access common physical storage devices, however, device handles unique, opaque values, which are not storage device-specific.

A DL module is responsible for the integrity of the objects it stores. If the DL module uses an underlying commercial database management system (DBMS), it may choose to further secure the data store by leveraging integrity services provided by the DBMS. DL module designers must choose which mechanisms best address the availability, integrity, privacy and performance needs of the perceived customer. For example tamper-resistant storage devices and encryption could be used to protect secret objects. Local and remote redundant storage devices could facilitate integrity and availability, while caching could improve performance.

The persistent objects managed by a DL module have semantic typing associated with them. This semantic information is used to describe the object's intended use. For example certificate objects whose corresponding private key is local to the system would receive the semantic label of "owned". Other certificates may be trusted as a root of authority or as a cross-certified entity. These would receive the semantic label of "root". Applications and TP modules may use the semantic information when manipulating and evaluating objects that are semantically related.

Data Storage Library Registration

CSSM defines API calls for installing and registering of DL modules. The CSSM records each DL module name and capability description. This information enables applications to select a DL module appropriate for their needs. For example, a DL module built on top of an X.500 directory service may indicate different naming and usage semantics than for file system-based storage. Other capabilities such as structured query language support, removable media and latent operation, are also traits registered with the DL module.

DL modules may have capabilities that change after installation and registration. For example remote or removable data stores' capabilities may change during regular operation of the DL module. In this case, the DL module cannot know what functions it supports until the application requests capabilities of a particular data store. The same situation held for Cryptographic Service Providers. A DL module can be dynamically queried by CSSM to obtain these dynamic module capabilities.

Data Storage Library API

The data store management functions operate on a data store as a single unit. These operations include:

The persistence operations on data stores include:

A data store may contain a single object type or multiple object types. DL modules will register which object types the DL is capable of storing at installation time, or whenever an application polls for capabilities information.

Creating and Deleting Data Stores. The DL module creates a new, empty data store and opens it for future access by the caller. An existing data store may be deleted. Deletion discards all data contained in the data store. Deletion will not occur if there are outstanding open references to a data store. Data store creation also involves specifying an access schema and setting other configuration information. This includes describing indexed fields and fields requiring unique database keys.

Opening and Closing Data Stores. The DL module manages the mapping of logical data store names to physical storage mechanisms. The caller uses logical names to reference persistent data stores. The open operation initializes physical storage mechanisms and associates a context to the logical storage facility. The close operation terminates current access to the data store and cleans up any temporal state created during initialization and operation.

Importing and Exporting Data Stores. Local data stores may be moved from one system to another or from one storage medium to another storage medium. The import and export operations support the transfer of an entire data store. The export operation prepares a snapshot of a data store. (Export does not delete the data store it snapshots.)

The import operation accepts a snapshot (generated by the export operation) and creates a new data store or adds the data records to an existing data store managed by the DL module.

The following is a brief description of the CSSM-recommended semantics of data storage library functions. The persistence mechanisms are implemented by the DL module developer.

Inserting Objects. The DL module adds a persistent copy of the supplied object to an open data store. This operation may include updating index entries or other components of the physical data model. The mechanisms used to store and retrieve persistent objects is specific to the implementation of the DL module and transparent to applications.

Updating Objects. The DL module updates objects when the inserted object already exists in the data store and the meta-data indicates unique key space. In the case of non-unique key spaces, the inserted object is appended to the data store. It is anticipated that applications will store and retrieve multiple objects using the same key. For example an application may associate several identity certificates, several policy objects and possibly a key object with a user name. A query for the user name would result in all the user's objects being returned. Updates to these objects must be done by deleting and then re-adding to the data store.

Deleting Objects. The DL module removes the specified objects from the data store.

Retrieving Objects. Applications and add-in security modules need to search persistent data stores for objects specified in the query. The DL module must provide a search mechanism for retrieving a copy of selected persistent objects. A selection predicate controls the query. Selection predicates may be expressed as a string of structured language or as data structures of a query tree.

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