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 signatures 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 to complete the verification process. Depending on the fields stored in the certificate or the CRL, additional checks (such as the presence of non-zero fields) may be required to complete syntactic verification.
Extracting Values from Certificates and CRLs. 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. The CL may also support multiple return-representations for certificate fields. When multiple representations are supported, the caller must specify the desired return format.
CRLs can contain field values describing the CRL in general. These values can be extracted for use by an application. Additional functions are defined to search a CRL to retrieve a field value. If multiple return-representations are supported, then the caller must specify the desired return 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.
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 |