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, each device handles unique, opaque values, which are not storage device-specific.
A DL module is responsible for the integrity of the objects it stores. Optionally, the DL module can provide additional services such as private/encrypted data storage and authenticated data storage. 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.
The DL APIs define a general data model for all persistent security-related objects. Each data store record consists of two basic components:
The data blob can be empty. If not empty, then the data blob contains a packed representation of a certificate, CRL, policy definition, integrity credential, cryptographic key, or other security object. The attributes are traditional data base objects, such as strings, integers, time values, etc. The attributes describe the security object. Selection queries are expressed in terms of the attribute values.
The Data Storage Library specification defines an initial set of record types and a minimal set of attributes for each DL record type. New record types and their associated minimal attribute schemas will be defined in the future as required.
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 or new data stores can be created. In this case, the DL module cannot know what functions it supports until the application requests capabilities of a particular data store. The DL API defines functions for applications to directly query the DL module for:
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 with 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 can be done by deleting and re-adding to the datastore or by using the data modify function.
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.
| Contents | Next section | Index |