The Certificate Library Interface (CLI) specifies the functions that a CL may make available to applications via OCSF in order to support a certificate and a CRL format. These functions mirror the OCSF API for certificates and CRLs. These functions include the basic areas of functionality expected of a CL, which include certificate operations, CRL operations, extensibility functions, and module management functions. The CL developer may choose to implement some or all of these CLI functions. The available functions are made known to OCSF at module attach time when it receives the CL's function table. In the function table, any unsupported function must have a NULL function pointer. The CL module developer is responsible for making the certificate format and general functionality known to application developers.

Certificate operations fall into three general areas, including:

• Cryptographic Operations - These operations include signing a certificate and verifying the signature on a certificate. It is expected that the CL will determine the certificate fields to be signed or verified, and will manage the interaction with a Cryptographic Service Provider (CSP) to perform the signing or verification.
• Certificate Field Management - Fields are added to a certificate when it is created. After the certificate is signed, the fields cannot be modified in any way. However, they can be queried for their values using the OCSF certificate interface.
• Certificate Format Translation - In the heterogeneous world of multiple certificate formats, CL modules may want to provide the service of translating between certificate formats. This translation would involve mapping the fields from one certificate format into another certificate format, while maintaining the original format for integrity verification purposes. For example, an X.509 Version 1 certificate may be exported to a Simple Distributed Security Infrastructure (SDSI) format or imported into an X.509 Version 3 certificate, but the original data and signature must somehow be maintained. The supported import and export types are registered with OCSF as part of CL installation.

To support new certificate types and new uses of certificates, the sign and verify operations in the CLI support a scope parameter. The scope parameter enables an application to sign a portion of the certificate, namely, the fields identified by the scope. This provides support for certificate models that permit field signing. CL modules that support existing certificate formats, such as X.509 Version 1, which sign and verify a predefined portion of the certificate, will ignore this parameter.

The CL module's certificate format is exposed via its fields. These fields will consist of tag/value pairs, where the tag is an object identifier (OID). These OIDs reference specific data types or data structures within the certificate or CRL. OIDs are defined by the CL developer at a granularity appropriate for the expected usage of the CL.

Operations on CRLs are comprised of cryptographic operations and field management operations on the CRL, as a whole, and on individual revocation records. The entire CRL can be signed or verified. This will ensure the integrity of the CRL's contents as it is passed between systems. Individual revocation records are signed when they are revoked and verified when they are queried. Certificates may be revoked and unrevoked by adding or removing them from the CRL at any time prior to its being signed. The contents of the CRL can be queried for all of its revocation records, specific certificates, or individual CRL fields.

A pass-through function is included in the CLI to allow CLs to expose additional services beyond what is currently defined in the OCSF API. These services should be syntactic in nature, meaning that they should be dependent on the data format of the certificates and CRLs manipulated by the library. OCSF will pass an operation identifier and input parameters from the application to the appropriate CL. Within the CL_PassThrough function in the CL, the input parameters will be interpreted and the appropriate operation performed. The CL developer is responsible for making known to the application the identity and parameters of the supported passthrough operations.