Certificate Library Module Manager

The Certificate Library Module Manager administers the Certificate Libraries (CLs) that may be installed on the local system. It defines a common application programming interface (API) for these libraries.

The API allows applications to manipulate memory-resident certificates and Certificate Revocation Lists (CRLs).

Operations defined in the API include create, sign, verify, and extract field values. The CL modules implement all certificate operations. Application-invoked calls are dispatched to the appropriate library module. Each library incorporates knowledge of certificate data formats and how to manipulate that format. The OCSF Certificate Module Manager administers a queryable registry of local libraries. The registry enumerates the locally accessible libraries and attributes of those libraries, such as the certificate type manipulated by each registered library.

The primary purpose of a CL module is to perform memory-based, syntactic manipulations on the basic objects of trust: certificates and CRLs. The data format of a certificate will influence (if not determine) the data format of CRLs used to track revoked certificates. For this reason, these objects should be manipulated by a single, cohesive library. CL modules incorporate detailed knowledge of data formats. The Certificate Library Module Manager defines API calls to perform security operations (such as signing, verifying, revoking, viewing, etc.) on memory-resident certificates and CRLs. The mechanics of performing these operations is tightly bound to the data format of a given certificate. One or more modules may support the same certificate format, such as X.509 ASN/DER-encoded certificates or Simple Distributed Security Infrastructure (SDSI) certificates.

As new standard formats are defined and accepted by the industry, CL modules will be defined and implemented by industry members and used directly and indirectly by many applications. CL modules encapsulate certificate and CRL data formats from the semantics of TPs, which are implemented in TP modules.

Since CL modules manipulate memory-based objects only, the persistence of certificates and CRLs is an independent property of these objects. It is the responsibility of the application and/or the TP module to use data storage modules to make these objects persistent (if appropriate). It must be possible for the storage mechanism used by a data storage module to be independent of the other modules. It must also be possible to design a CL module that depends on the storage mechanism of a DL module.

Application developers and TP module developers both benefit from the extensibility of CL modules. Applications are free to use multiple certificate types without requiring the application developer to write format-specific code to manipulate certificates and CRLs. Without increased development complexity, multiple certificate formats can be used on one system, within one application domain, or by one application. Certificate Authorities (CAs) who issue certificates also benefit. Dynamically downloading CLs ensures timely and accurate propagation of data-format changes.