The use of digital certificates is the foundation on which the CDSA is designed. The CDSA assumes the concept of digital certificates in its broadest sense. Applications use the credential for:
How applications interpret and manipulate the contents of certificates to achieve these ends is defined by the real-world trust model the application has chosen as its model for trust and security.
The primary purpose of a Trust Policy (TP) module is to answer the question "Is this certificate trusted for this action?" The CSSM Trust Policy API defines the generic operations that should be defined for certificate-based trust in every application domain. The semantics of each operation are defined by the:
The trust model is expressed as an executable policy used/invoked by all applications ascribing to that policy and the trust model it represents.
As an infrastructure, CSSM is policy neutral with respect to application domains. It does not incorporate any single policy. For example, the verification procedure for a credit card certificate should be defined and implemented by the credit company issuing the certificate. Employee access to a lab housing a critical project should be defined by the company whose intellectual property is at risk. Rather than defining policies, CSSM provides the infrastructure for installing and managing policy-specific modules. This ensures complete extensibility of certificate-based trust on every platform hosting CSSM.
Policy describing the intended use of security objects such as private keys, credentials and certificates requires flexible mechanisms. The CDSA trust policy module can support trust policy interpreters such as PolicyMaker. The implementation of a policy interpreter may rely heavily on the CL and DL modules for certificate parsing and policy object storage.
Trust policy statements can also be expressed concisely as action tags that assert actions a principal is authorized to perform. Fixed trust policy action assertions enable simpler expression of trust policy which makes policy inspections straightforward. These actions are primary operations on the basic objects common to almost all trust models. These include certificates, credentials and certificate revocation lists. The basic operations on certificates are sign, verify, and revoke.
Based on this analysis, CSSM defines two categories of API calls that should be implemented by TP modules. The first category allows the TP module to define and expose actions specific to the trust domain (such as requesting authorization to make a $200 charge on a credit card certificate, or requesting access to the locked project lab). The second category specifies basic operations (for example, sign, verify, and revoke) on certificates and certificate revocation lists.
Application developers and trust domain authorities benefit from the ability to define and implement policy-based modules. Application developers are freed from the burden of implementing a policy description and certifying that their implementation conforms. Instead, the application only needs to build in a list of the authorities and certificate issuers it uses.
Domain authorities also benefit from an infrastructure that supports add-in trust policy modules. Authorities are sure that applications using their module(s) will adhere to the policies of the domain. Also, dynamic download of trust modules (possibly from remote systems) ensures timely and accurate propagation of policy changes. Individual functions within the module may combine local and remote processing. This flexibility allows the module developer to implement policies based on the ability to communicate with a remote authority system. This also allows the policy implementation to be decomposed in any convenient distributed manner.
Implementing a trust policy module may or may not be tightly coupled with one or more certificate library modules and one or more data storage library modules. The trust policy embodies the semantics of the domain. The certificate library and the data storage library embody the syntax of a certificate format and operations on that format. A trust policy can be completely independent of certificate format, or it may be defined to operate with one or a small number of certificate formats. A trust policy implementation may invoke a certificate library module and/or a data storage library module to manipulate certificates.
The following descriptions present general, recommended semantics. The specific semantic implemented by the TP module is defined by the specific trust model it represents.
Determining trust for an application-specific operation. Each trust policy is specific to an application domain. The policy should support all applications in that domain. This includes an understanding of all domain-specific operations and the authorizations required to perform the operations in that domain. Determination is based on the caller's certificate. Policy evaluation may require remote processing. If the caller is authorized to perform the operation, the TP module can be designed to perform the operation on the caller's behalf, or the TP module can return an affirmative response and an authorization credential granting the caller permission to act.
Determining trust for accessing CSSM objects. There are operations that are global to all application domains. These operations involve the manipulation of CSSM-recognized objects, such as certificates and CRLs. Trust evaluation is required to manipulate these objects. For example, a caller can present the TP module with a newly-released CRL for its use. Should the TP module trust the caller who is providing this CRL? Accepting or rejecting CRL updates is common to all application domains, and as such, is not a natural part of the verification functions discussed above.
Manipulating groups of related certificates. All trust domains assign trust in one credential based on trust in another. This is a property of hierarchical trust models and introducer trust models. The TP module manipulates groups of semantically-related certificates. In the hierarchical trust model, a certificate is signed by one certificate/key and a group of certificates can be arranged in a rooted hierarchy based on this signature relationship. In the introducer trust model, certificates can include signatures from multiple parties. These certificates are be arranged in a graph based on this signature relationship. The primary operations to be performed are constructing a set of certificates related by a specific semantic, decomposing a set of related certificates, and verifying that groups of certificates are related based on a given semantic. The semantic is usually known to the TP module a priori. For example, if the application domain served by the trust policy supports only the hierarchical model, then verifying a group of certificates means to check the certificate-signatures to confirm that they form a signed, hierarchical certificate chain. If the trust policy supports an introducer model, then verifying a group of certificates could mean checking for a minimum number of recognized signatures on one or more certificates in the group.
| Contents | Next section | Index |