Data storage library interface

A module with Data Storage Library (DL) services provides access to persistent data stores of certificates, Certificate Revocation Lists (CRLs), keys, policies, and other security-related objects. Stable storage can be provided by a:

• Commercially available database management system (DBMS) product
• Directory service
• Custom hardware-based storage device
• Native file system.

The implementation of DL operations should be semantically free. For example, a DL operation that inserts a trusted X.509 certificate into a data store should not be responsible for verifying the trust on that certificate. The semantic interpretation of security objects should be implemented in Trust Policy (TP) services, layered services, and applications.

The DL provides access to persistent stores of security-related objects by translating calls from the Data Storage Library Interface (DLI) into the native interface of the data store. The native interface of the data store may be that of a DBMS package, a directory service, a custom storage device, or a traditional local or remote file system. Applications are able to obtain information about the available DL services by using the CSSM_GetModuleInfo function to query the OCSF registry. The information about the DL service includes the following:

• Vendor information - Information about the module vendor, a text description of the DL and the module version number.
• Types of supported data stores - The module may support one or more types of persistent data stores as separate subservices. For each type of data store, the DL provides information on the supported query operators and optionally provides specific information on the accessible data stores.

The DL may choose to provide information about the data stores that it has access to. Applications can obtain information about these data stores by using the CSSM_GetModuleInfo function call. The information about the data store includes the following:

• Types of persistent security objects - The types of security objects that may be stored include certificates, CRLs, keys, policy objects, and generic data objects. A single data store can contain a single object type in one format, a single object type in multiple formats, or multiple object types.
• Attributes of persistent security objects - The stored security object may have attributes which must be included by the calling application on data insertion, and which are returned by the DL on data retrieval.
• Data store indexes - These indexes are high-performance query paths constructed as part of data store creation and maintained by the data store.
• Secure access mechanisms - A data store may restrict a user's ability to perform certain actions on the data store or on the data store's contents. This structure exposes the mechanism required to authenticate to the data store.
• Record integrity capabilities - Some data stores will insure the integrity of the data store's contents. To insure the integrity of the data store's contents, the data store is expected to sign and verify each record.
• Data store location - The persistent repository can be local or remote.

To build indexes or to satisfy an application's request for record retrieval, the data store may need to parse the stored security objects. If the application has invoked CSSM_DL_DbSetRecordParsingFunctions for a given security object type, those functions will be used to parse that security object as the need arises. If the application has not explicitly set record-parsing functions, the default service provider modules set by the data store creator will be used for parsing.

Secured access to the data store and to the data store's contents may be enforced by the DL, the data store, or both. The partitioning of authentication responsibility is exposed via the DL and data store authentication mechanisms.

Data stores may be added to a DL in one of three ways:

• Using DL_DbCreate - This creates and opens a new, empty data store with the specified schema.
• Using DL_DbImport with information and data - If the specified data store does not exist, a new data store is created with the specified schema and the exported data records.
• Using DL_DbImport with information only - In this case, the data store's native format is the same as that managed by the DL service. Importing its information makes it accessible via this DL service.

In all cases, it is the responsibility of the DL service to update the OCSF registry with information about the new data store. This can be accomplished by making use of the CSSM_GetModuleInfo and CSSM_SetModuleInfo functions.