Previous section.

Common Security: CDSA and CSSM, Version 2
Copyright © 1999 The Open Group


CSSM Add-In Module Overview

Figure: CDSA Add-In Module Structure

A CDSA add-in module is a dynamically-linkable library, composed of functions that implement some or all of the CSSM Module Interfaces. Add-in module functionality is partitioned into two areas:

Add-in modules provide one or more categories of security services to applications. The service categories are Cryptographic Service Provider (CSP) services, Trust Policy (TP) services, Authorization Computation (AC) services, Certificate Library (CL) services, and Data Storage Library (DL) services. Each security service contains one or more implementation instances, called sub-services. For a CSP service providing access to hardware tokens, a sub-service would represent a slot. For a CL service provider, a sub-service would represent a specific certificate format. These sub-services each support the module interface for their respective service categories.

This Part describes the module interface functions in the CL service category.

Each module, regardless of the security services it offers, has the same set of administrative responsibilities. Every module must expose functions that allow CSSM to indicate events such as module attach and detach. In addition, as part of the attach operation, every module must be able to verify its own integrity, verify the integrity of CSSM, and register with CSSM. Detailed information about add-in module structure, administration, and interfaces can be found in Part 9 of this Technical Standard.

Certificate Library Module


The primary purpose of a Certificate Library (CL) module is to perform syntactic operations on a specific certificate format, and its associated certificate revocation list (CRL) format. These manipulations encapsulate the complete life cycle of a certificate and the keypair associated with that certificate. Certificate and CRLs are related by the life cycle model and by the data formats used to represent them. For this reason, these objects should be manipulated by a single, cohesive library.

The Certificate Library encapsulates format-specific knowledge into a library which an application can access via CSSM. These libraries allow applications and add-in modules to interact with Certificate Authorities and to use certificates and CRLs for services such as signing, verification, creation and revocation without requiring knowledge of the certificate and CRL formats.

CSSM defines the general security API that all certificate libraries should provide to manipulate certificates and certificate revocation lists. The basic areas of functionality include:

Each certificate library may implement some or all of these functions. The available functions are registered with CSSM when the module is attached. Each certificate library should be accompanied with documentation specifying supported functions, non-supported functions, and module-specific passthrough functions. It is the responsibility of the application developer to obtain and use this information when developing applications using a selected certificate library.

Certificate libraries manipulate memory-based objects only. The persistence of certificates, CRLs, and other security-related objects is an independent property of these objects. It is the responsibility of the application and/or the trust policy module to use data storage add-in modules to make objects persistent (if appropriate).

Certificate Life Cycle

The Certificate Library provides support for the certificate life cycle and for format- specific certificate or CRL manipulation, services which an application can access via CSSM. These libraries allow applications and add-in modules to create, sign, verify, revoke, renew, and recover certificates without requiring knowledge of certificate and CRL formats and encodings.

A certificate is a form of credential. Under current certificate models, such as X.509, SDSI, SPKI, and so on, a single certificate represents the identity of an entity and optionally associates authorizations with that entity. When a certificate is issued, the issuer includes a digital signature on the certificate. Verification of this signature is the mechanism used to establish trust in the identity and authorizations recorded in the certificate. Certificates can be signed by one or more other certificates. Root certificates are self-signed. The syntactic process of signing corresponds to establishing a trust relationship between the entities identified by the certificates.

The certificate life cycle is presented in Certificate Life Cycle States and Actions. It begins with the registration process. During registration, the authenticity of a user's identity is verified. This can be a two part process beginning with manual procedures requiring physical presence followed by backoffice procedures to register results for use by the automated system. The level of verification associated with the identity of the individual will depend on the Security Policy and Certificate Management Practice Statements that apply to the individual who will receive a certificate and the domain in which that certificate will be issued and used.

After registration, keying material is generated and a certificate is created. Once the private key material and public key certificate are issued to a user and backed up if appropriate, the active phase of the certificate management life cycle begins.

The active phase includes:

Figure: Certificate Life Cycle States and Actions

Click here to return to the publication details.

Contents Next section Index