Major Trust Models
This section discusses three primary trust models. Different organizations have different thresholds for risk, and the choice of a trust model should be based on that threshold. Specific security solutions should map to the applicable trust model.
Direct trust exists when you perform the validation of an entity's credentials without reliance on any other entity. There is no delegation of trust, because all relying parties are subordinate constituents of the trust hierarchy. All entities gain trust by their association with a common entity responsible for the original entity authentication of each relying entity, always following a stated security policy. Distinct binary trust relationships are established between a common trust point and the various end entities.
A direct trust model is found in some architectures using a PKI. In this example, the root certificate authority (CA) initiates all trust relationships. The CA is the common trust entity that performs all original entity authentications and the generation of credentials that are bound to specific entities. A key difference with other models is that the direct trust model does not allow the delegation of original entity authentication. And every relying party must use this CA directly for all validation processes.
The advantage of the direct trust model is that the validation of credentials is performed by one's self with no delegation, thus ensuring a high level of confidence in every entity associated with the trust implementation. Direct trust is often necessary to reduce liability for organizations bound by regulatory or fiduciary requirements. Organizations involved with financial transactions, e-commerce, insurance, or health care should consider a direct trust model.
However, as we stated earlier, trust is not established without effort. The primary disadvantage of the direct trust model is that it may be more labor intensive and more expensive than other trust models.
Transitive trust is trust transmitted through another party. Transitive trust allows the following:
Entity A validates and trusts Entity B.
Entity B validates and trusts Entity C.
Entity A trusts but does not need to validate Entity C. For example, Entity A trusts Entity C, but does not perform original entity authentication of Entity C.
Such a trust model is common in distributive or peer-to-peer systems. It relies on participating entities to align their security policies that control credential validation (for example, original entity authentication). In the preceding example, for A to trust C, A needs confidence that B has validated C by the same standards that A used to validate B. Because you are explicitly trusting another entity to perform credential validation, you should, at the very least, evaluate that entity's security policy, validation process, and position on liability management.
The advantage of the transitive trust model is that it enables the linkage of different entities that share similar security policies while reducing the credential validation effort.
Consider the following example of transitive trust, which is common with the frequency of bank mergers in recent years. You are a customer of Bank ABC, which is acquired by Bank XYZ. Because XYZ trusts ABC's original validation process, you are trusted by XYZ to continue your normal banking activities (unless previously allowed activity somehow significantly violates the new owner's security policy). The new portfolio owner has presumably reviewed, very carefully, ABC's financial statements, security policy, and validation process to have confidence in extending trust to the customers it gains through the acquisition.
Assumptive trust is a formal name for a model that was earlier described as spontaneous trust. With this model, there is no mandatory, explicit, direct credential validation. With essentially no control over the validation process, you must either "take it, or leave it."
An example of an assumptive trust model is the pretty good privacy (PGP) web of trust. The validation of entities is essentially one personally vouching for another. Although this web of trust has some value for relatively simple activities, such as signing email messages, it is not sufficient in the business realm. Many users have false confidence that PGP is based on a transitive trust model, so it is important to emphasize that which differentiates a transitive trust model from an assumptive one is the validation process (or lack thereof). A transitive trust model requires a validation process, and an assumptive one does not.
There are many other examples of assumptive trust models. If more than casual, noncritical information or processes are involved, you should consider implementing these and other protocols with at least a transitive trust model.