Trust Management for the World Wide Web

2.1What is Trust Management

As formulated by Blaze, Feigenbaum, and Lacy, trust management addresses the question "is this request, supported by these credentials, in compliance with this user policy?" The [BFL96] paper identified three components of trust management:

• 
  security policies
  
• 
  security credentials
  
• 
  trust relationships
  

Security policies are local policies that an application trusts unconditionally. Security credentials are assertions about objects by trusted third parties. Trust relationships are special cases of security policies. An example in the paper illustrated the use and the interactions among the three components:

An electronic banking system must enable a bank to state that at least k bank officers are needed to approve loans of $1,000,000 or less (a policy), it must enable a bank employee to prove that he can be counted as 1 out of k approvers (a credential), and it must enable the bank to specify who may issue such credentials (a trust relationship).

The paper referred to the study of the three components and their interactions as the trust management problem. The authors believe that the trust management problem is a distinct and an important aspect of security in network services and that such problems can be solved using a general mechanism that is independent of any particular application or service. They propose is a trust management layer that applications and services can build on top of.

PolicyMaker, described in [BFL96], is a trust management system designed to meet the needs of this layer. It is a three-part solution: a credential format to represent authorization assertions, a security policy language to express user preferences, and an execution environment to evaluate certificates and policies. PolicyMaker broke new ground by expressing credentials and policies as programs. The execution environment acts like a database query engine: The host application sends to the execution environment a request for action and a user policy, and the environment returns an answer to the question of whether the credentials prove that the request complies with the policy.

What is missing from PolicyMaker is consideration of "trust protocols", in particular, of mechanisms for acquiring additional trust information in the course of evaluating policies. PolicyMaker assumes the application is responsible for providing all credentials at the time a query is made to the trust management engine. In practice, the "right" set of credentials is often determined by the semantics of the policy and the state of the evaluation. For example, the "right" set of credentials to validate a PICS label may depend on the type of signature and certificate, the intended use of the Web document, the semantics of the label, the processor speed, or the network connection. These factors are often known only at the time of policy evaluation. A better approach is to put trust protocols under policy control. That is, a policy is capable of determining how, where, when, and under what circumstances to invoke a trust protocol to fetch credentials.

Adding "trust protocols" to the execution environment necessitates substantial changes in the [BFL96] framework. First, a trust policy needs a language construct with which to invoke trust protocols. The PolicyMaker language is only able to express authorizations. Moreover, a trust policy needs to be able to parse the retrieved credentials in order to make intelligent trust decisions. PolicyMaker avoids this by requiring the host application to translate the credentials into a special format before querying the engine. Furthermore, the underlying execution environment needs to be powerful enough to handle protocol invocations during the interpretation of a trust policy. It needs either to run the protocol inside its environment or to delegate the request to another software module. Finally, a trust management system should be extensible enough to install and de-install trust protocols. A given trust policy does not know a priori which trust protocols are available. When a protocol is unknown during the policy interpretation, the execution environment should be able to install it.

The need to treat metadata formats, trust protocols, trust policy languages, and execution environments as distinct components in trust management is the main conceptual contribution of my work on trust management infrastructure as explained in the next section. My framework draws the lines that separate components and assigns duties to each of them. Later the readers will see the importance of this component-wise view of trust management. It leads to several important design decisions in the REFEREE architecture: Policies and protocols are both software components of REFEREE, and these components not only coexist under one execution environment but also work together by invoking each other through a standard REFEREE interface.

2.2Trust Management Infrastructure

A trust management infrastructure is a conceptual framework for the design of a coherent solution to various trust decisions that must be made in what is commonly referred to as the "information infrastructure". A trust management infrastructure allows parties to make trusted assertions about objects in the information infrastructure, and applications to acquire these assertions and make trust decisions based on them. The framework is independent of the trust criteria imposed by any particular application and of the type of assertions made by a trusted party. There are four components in a trust management infrastructure:

Metadata format

is a format for describing information about an object, often called an assertion system. Metadata exists in various forms and under various names, but its function is similar throughout. For example, the content-filtering community calls its metadata "labels"; an instance of a label is "the code pointed to by this URL is safe to download." The security community calls its metadata "identify certificates"; an example of an identify certificate is "this person is over 18 years of age." Metadata is the medium in which trust flows from the entity creating the metadata to the application making the trust decision. It represents a token of trust.

Metadata itself is an object; it may be described by other metadata. The ability to form a chain of metadata allows trust to branch and decentralize into a Web-like structure. Actually, a collection of interconnected metadata look just like objects in an information infrastructure without trust. It is the duty of the trust policies and trust protocols to weave these objects together and provide them meanings.

Trust protocol

is a method for applications to acquire assertions from third parties. In X.509, there is an algorithm to walk up the certification path (a hierarchical chain) and gather the appropriate certificates along the path for a given directory name. In PICS and PGP, there is no algorithm for finding the "right certificates"; some metadata come with the original source, and others are acquired from named trusted parties.

The sole duty of a trust protocol is to gather an appropriate set of trusted assertions in order for a given request to comply with a trust policy. Algorithms used in a trust protocol do not perform any trust evaluation; rather they help a trust policy to collect a set of metadata likely to be used during a policy evaluation.

Trust policy language

is a language to specify a set of criteria for an object to be trustworthy to perform a given action. For example, there can be a policy about "downloading and running Java Applets in my browser", which requires "signed credentials from two trusted parties asserting that the Applet contains no virus".

Chapter 4 is devoted to the discussion of trust policy languages. PicsRULZ and Profiles-0.92, described in that chapter, are examples of trust policy languages.

Execution environment

is an environment for interpreting trust policies and administering trust protocols. An execution environment takes requests from its host application and returns an answer that is compliant with trust policies.

Chapter 3 is devoted to the discussion of execution environments. Both PolicyMaker and REFEREE have a notion of a general-purpose execution environment in which policies are evaluated.

Instances of the components work together to form a trust management system, which is an instance of a trust management infrastructure. For example, PolicyMaker trust management system has a metadata format, a trust policy language, and an execution environment. How components interact with each other may be application specific. This section provides a rule of thumb on how components should interact, based on their defined properties. Figure 2 shows a component dependency graph in the trust management infrastructure. Diamonds represent components in the trust management infrastructure and arrows represent dependency relations.

Figure 1 Trust Management Infrastructure


Figure 2 Dependency Graph of Trust Management Infrastructure Components

A metadata format is independent of any other components in the trust management infrastructure. It can be distributed by multiple protocols and operated on by multiple trust policy languages. For example, it is possible to represent SDSI certificates as PICS labels and use them in the SDSI public-key distribution protocol.

A trust protocol generally depends on the metadata format. A typical protocol contains methods to query specific metadata, heuristics to chain the metadata together, and ways to transport them. The specific properties in the metadata format enable the trust protocol to perform these methods.

A trust policy language depends on both the trust protocol and the metadata format. It must understand the syntax and the semantics of the metadata in order to write a policy on it. A trust policy may depend on trust protocols in order to fetch metadata at runtime.

An execution environment depends on both the trust policy language and the trust protocol. The underlying execution environment in the system needs to be powerful enough to interpret the policies and run the protocols. However, an execution environment need not understand the syntax or the semantics of the metadata formats directly. It is the duty of trust policies to parse the syntax and reason about the semantics.

Most existing trust systems can be mapped into this infrastructure, marked by their component dependencies. Not surprising, these solutions are geared toward neither a single component nor a complete infrastructure. For example, PICS is both a metadata format and a trust protocol, but it has neither a policy language to express trust relationships nor an execution environment to evaluate it. The next section discusses some well-known trust systems in greater detail and fits them into this framework.