As new standard formats are defined and accepted by the industry, certificate library modules will be defined and implemented by industry members and used directly and indirectly by many applications. Certificate library modules perform syntactic manipulations of certificate and CRL data objects. The semantic interpretation of certificate and revocation security objects are considered policy transformations and are implemented as trust policy modules.
Certificate library modules manipulate memory-based objects only. The persistence of these objects is an independent property. It is the responsibility of the application and/or the trust policy module to use data storage add-in modules to make these objects persistent (if appropriate). The storage mechanism used by a data storage module may be independent of other modules.
Application developers and trust policy module developers both benefit from the extensibility of add-in certificate library 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. CAs who issue certificates also benefit. Dynamically downloading certificate libraries ensures timely and accurate propagation of data-format changes.
Every certificate library (CL) module should implement most if not all of these functions. A pass-through function is also defined by the certificate library API. This allows CLs to provide additional functionality if required to manipulate the certificate data format and CRL data format supported by the module.
Some of the functions can be implemented as remote services. For example, creating a certificate can be performed by a remote Certificate Authority (CA). Remote operations have an impact on the specification of the CL-API when the operation could require asynchronous completion.
The following is a brief description of the CSSM-recommended semantics of certificate library functions. The data format-dependent manipulation of certificates and CRLs is implemented by the CL module developer.
Creating new Certificates and new CRLs. The CL issues a signed, memory-resident certificate containing values specified by the caller and values specified by the issuing process. The CL also creates an initialized, but empty, memory-resident CRL. Revocation records can be added to the CRL using the CL module's revocation function.
Signing Certificates and CRLs. The signing function is used to add subsequent signature to a signed certificate. Subsequent signatures can represent a local endorsement of the certificate. For example, in the introducer model of trust, a local policy may define that once a certificate has been verified, it is re-signed using a locally trusted certificate. This can significantly reduce the effort required for future verifications of the certificate. This is akin to the function of a notary public. When signing certificates, the CL computes the digital signature over a certificate or a CRL, and includes the newly-generated signature in the memory-resident copy of the certificate or CRL. CL modules may forward signing requests to external signing authorities or perform them locally. The CL module may use the services of a CSP add-in module to calculate the signature. Many certificate formats define fields that must be excluded from the signature calculation.
For example, management fields whose state must change over time without invalidating the certificate cannot be included in the signature calculation. The CL module uses its knowledge of the certificate data format to include only those certificate fields that must not change during the life of the certificate. Signing memory-resident CRLs is performed in the same manner.
Verifying Certificates and CRLs. Mechanically verifying one or more signatures associated with a certificate or CRL depends on the format of the signed objects. The CL module embodies knowledge of which subset of the object's fields were included in the signing process. Regardless of data format, every CL module must test the integrity of the signature. This means that the object associated with that signature has not been modified since the signature was calculated.
Typically the CL module will invoke a CSP to recalculate the one-way hash of the certificate or CRL, decrypt the signed hash value, and compare it with the calculated hash complete the verification process. Depending on the fields stored in the certificate or the CRL, additional checks may be required to complete syntactic verification.
Extracting Values (such as Public Keys) from Certificates. Applications and trust policy modules may need selected values from a certificate. Extracting field values depends on the certificate data format. The CL module must extract and return, to the caller, any requested field value.
Importing and Exporting Certificates. When presenting a certificate to an application or sending a certificate from one system to another, a data format translation is often required. A full-service CL module should provide format translation functions that import certificates of foreign format to the library's particular format. Also the reverse translation should be provided.
These import and export functions allow applications to more easily accept certificates in one of several distinct formats by converting the foreign format to the format typically processed by the application. CRLs are typically stored only in the CL module's native format. It is assumed that CRLs are exchanged only among systems that support the same CRL format.
Revoking and Reinstating Certificates. A certificate may be permanently or temporarily revoked for a number of reasons. Some certificate formats include one or more revocation status fields. In this case, the CL module will mark the certificate as revoked. When revoking a certificate, the CL module will typically add a revocation record to the supplied CRL.
To ensure the integrity of the revocation record, it should be digitally signed, using the private key associated with the revoking agent's certificate. To reinstate a temporarily revoked certificate, the revocation record must be removed from the CRL. If fields in the certificate itself were modified to indicate the revoked state, these certificate values must also be updated and a renewed certificate is issued.
Searching Certificate Revocation Lists. Certificate revocations must be reported to all systems that may receive the certificate as a security credential. To avoid constant online revocation checks, CRLs are distributed periodically to all systems that need to verify certificates possibly contained in the revocation list. When a user presents a certificate to an application, the application must verify that certificate.
Certificate verification (by a CL module) includes a check to ensure the certificate in not revoked. This test requires a search of all CRLs that may contain the certificate in question. A CL module must support searches over a CRL, selecting revocation records based on selection criteria appropriate to the CRL data format.
| Contents | Next section | Index |