A certification trust model simply prescribes which certifying authorities (CAs) can legitimately issue (create and sign) certificates for which principals. A trust model is implemented by a policy module. The ultimate purpose of the certification service is to return public keys, and it is the job of the routines in a policy module to do this. Looked at from this point of view, policy modules are mainly distinguished from each other by the two following things:
· Which principals a policy module is willing to return keys for.
· Which CAs a module is willing to trust the signatures of on the certificates from which it retrieves keys.
A principal's certificates will be retrieved from a directory service entry (exactly what entry depends on the policy used), and the policy module will only look for certain signatures known to it on the certificates it retrieves. However, direct retrieval via the subject's directory entry name is only one trust model. There can be many others. For example, see the discussion of certification paths above.
Policy Modules Provided with DCE Certification
Several certification policy modules are provided by DCE. These policies are described in the following topics.
Direct secd Lookup: DCE Registry Lookup Policy Model
The registry lookup policy module simply looks up principals' public keys in the DCE registry, and returns them. These keys are not held in certificates, but are stored as extended registry attributes.
If a caller of the high-level certificate retreival API has DCE credentials, then the registry retrieval policy will authenticate the registry as part of the retrieval operation. If no credentials are available, no authentication is possible. In this case, keys will still be returned, but the certificate API will indicate to the caller that the keys are untrusted.
DCE Hierarchical Trust Policy
The DCE hierarchical trust policy supplied with DCE 1.2.2 supports hierarchical cells/DASS style trust paths. A trust path between principals A and B consists of zero or more up links, followed by zero or one cross link, followed by zero or more down links. The DCE hierarchical trust policy extension uses the DCE namespace certificate store extension (NCSE) for certificate retrieval.
Each cell is assumed to operate as a certification authority (CA) for top level principals registered within that cell. Thus, the CA for the cell over_cell is assumed to create a certificate for, say, the principal felix within over_cell, where the certificate signatory is "over_cell'' and the certificate target is "over_cell/felix''. If a cell employs structured names for principals, each level is considered to act as a CA for its subordinate. For example, if cell "over_cell'' contains a principal admin/JohnSmith, then over_cell/admin/JohnSmith is certified by two certificates, the first signed by over_cell and certifying over_cell/admin, and the second signed by over_cell/admin and certifying over_cell/admin/JohnSmith.
To avoid requiring that the cell's root CDS directory be used for storing certificates for the cell's principals, the DCE NCSE provided in DCE 1.2.2 allows any directory (in CDS or GDS) to be given an attribute (with OID 1.3.24.9.15) that names a subdirectory (of the directory to which the attribute is given) within which certificates are to be stored. The value of this attribute is a string which will be appended to the name of the directory to give the name of a new directory within which certificates will be stored.
For example, if the root directory in the cell over_cell is the directory to which this "principal directory'' attribute is attached, and the attribute contains the value principals, the DCE NCSE will attempt to retrieve the certificate for over_cell/P from the CDS directory over_cell/principals/P. If the "principal directory'' attribute is missing or empty, the cell root directory will be searched for principal certificates. (Note that the insertion of the "principal directory'' attribute value applies only to locating certificates within the directory service; the above certificate would contain the name over_cell/P as its actual subject.)
At most, one "certificate directory" attribute is considered when looking for certificates for a given name, according to the following algorithm:
· Starting with the name for which certificates are desired, RDNs are removed from the right of the name until either a directory is found that contains the "certificate directory" attribute, or the namespace root is reached.
In general, CDS administrators should define the "certificate directory" attribute within each CDS root directory, rather than storing certificates within the root directory. As well as reducing clutter in the cell root directory, doing this has efficiency benefits (terminating the search for the certificate directory at each CDS root), and also prevents the definition of this attribute at a higher level within the DCE global namespace from influencing the placement of certificates within a cell's namespace.
PEM-like Policy
No explicit PEM-like policy is provided with DCE 1.2.2; however, the DCE hierarchical policy may be used in a PEM-like fashion by specifying root CA keys as the initial trust list, rather than keys belonging to the caller's immediate CA.