Trust Management for the World Wide Web

2.3Review of Existing Trust Systems and Protocols

There are many existing systems and protocols built to deal with trust issues; none of them represents a satisfying solution for Web applications. This section identifies what they do and do not do, by mapping them onto the trust management infrastructure framework discussed above. This is not to say that a system missing a component is useless, but rather to show how to add its missing pieces or to show how it can collaborate with other systems toward in building a general trust management system.

2.3.1PICS

PICS, which stands for Platform for Internet Content Selection, is both a metadata format and a protocol. The system was originally designed as a technical solution to protect children from pornography on the Internet without suppressing freedom of speech. PICS enables content providers and trusted third parties to rate their sites and parents and supervisors to set filtering criteria for their children based on the ratings.



Figure 3 PICS in the Trust Management Infrastructure

Figure 3 shows a graphical representation of PICS in the trust management infrastructure. The main strength of PICS is its ability to express complex semantics within a machine-readable syntax structure. The trust protocol is relatively straightforward; there are ways to distribute labels and methods for querying them with certain attributes. The original PICS specification has neither a policy language nor an execution environment, although there is a proposed policy language called PicsRULZ described in detail in Section 4.2.

It turns out that many other applications have the same need for a general metadata format to make rich assertions as PICS does in content selection. For example, the digital library community needs metadata for cataloging books and journals. The privacy community needs metadata for labeling Web sites in terms of privacy practice. The security community needs metadata to express the semantics of a digital signature. PICS has moved quickly to become the standard, general metadata format on the Internet, with some modifications from its original specification.¹

The lack of a trust policy language and an execution environment limit the extent PICS can apply to Web applications requiring trust. PICS may be sufficient for applications involving content selection, where application-specific, proprietary policy language and execution environment can select content by matching PICS labels against user policies for acceptable ratings. However, PICS may not be applicable for applications involving database search based on PICS labels. One deficiency in content selection applications is that a fraction of the "hits" from a normal search engine will not comply with a user's policy for content selection and a user must test each "hit" to ensure compliance. A more efficient method is to give the user's policy for content selection to a search engine and the engine would return only hits that comply with that policy. In order to facilitate this database search application, both the clients and the search engines must agree on certain open-standard policy languages for PICS. In addition, both sides also need to have general execution environments to handle possibly various trust policy languages, or various metadata formats beside PICS, or various protocols to negotiate the transfer of the client's policy.

PICS alone does not provide the complete solution for managing trust, and it does not need to do so. Rather, the rich assertion system in PICS is a valuable building block in the trust management infrastructure. Other protocols and policies can simply take PICS as a component and build on top of it, as the PicsRULZ and Profiles-0.92 policy languages have already done.

2.3.2X.509

X.509 [CCITT88b] is a standard for authenticating users in an X.500 directory server [CCITT88a]. It is often referred to as an identity certification scheme, because the certificate is a signed statement that maps an identity to a public key. X.509 has a simple metadata format to express identity and a simple protocol for requesting a set of certificates. Figure 4 shows how X.509 maps to the trust management infrastructure.



Figure 4 X.509 in the Trust Management Infrastructure

The metadata format in X.509 is called an identity certificate. It contains seven static fields encoded in ASN.1: version number, serial number, signature algorithm and signature bits, certificate issuer, validity period, name of the subject, and the public key information of the subject. The metadata format cannot be extended to carry additional information about who the certificate issuers are or what the certificate is authorized to do.

The certification structure in X.509 is hierarchical. The root is called the Internet Policy Registration Authority (IPRA). Beneath the IPRA are Policy Certification Authorities (PCA), each of which establishes and publishes its policies for registration of users or organizations. PCAs in turn certify CAs, which in turn certify subordinate CAs, users, or organizations.

The trust protocol in X.509 is simple and is based on the hierarchical certification structure. When user A wants to authenticate user B, user A finds the proper certification path by traversing up the certification hierarchy until a mutual CA is reached and then traversing down the hierarchy until user B is reached.

As mentioned in Section 2.2, X.509 does not have a trust policy component. The certification path is simply a data structure for trust delegation in a certification structure. Interpretation of the information conveyed by this algorithm requires a mechanism that is extrinsic to X.509.

X.509 standard is good at authenticating public keys, but that alone is not enough for most Web applications. For example, in a Web application which approves on-line purchase order in a company Intranet, it is not enough to authenticate the purchase order form. The application needs to have a trust policy language to specify who are authorized to place certain purchase orders and an execution environment to evaluate these policies. Authenticating a purchase form is simply not enough.

From the standpoint of the trust management infrastructure, X.509 is similar to PICS. They both contain and omit the same component. Functionally, PICS conveys information about an information resource, and X.509 conveys information about an entity. Both of them have wide user bases and are the important steps toward a general trust management infrastructure.

2.3.3PolicyMaker

PolicyMaker [BFL96] was the first system to take a comprehensive approach to trust problems independent of any particular application or service. It has a general metadata format ("credentials"), a trust policy language, and an execution environment. As indicated in Section 2.1, PolicyMaker does not deal with the trust protocol component of what I call the trust management infrastructure. Figure 5 shows a graphical representation of PolicyMaker in the trust management infrastructure.



Figure 5 PolicyMaker in the Trust Management Infrastructure

PolicyMaker has its metadata format called credentials². It broke new ground by treating credentials as programs. A credential is a type of "assertion." It binds a predicate, called a filter, to a sequence of public keys, called an authority structure. The form of an assertion is:

Source ASSERTS AuthorityStruct WHERE Filter

Here, source indicates the source of authority, generally a public key of an entity in the case of a credential assertion. AuthorityStruct specifies the public key or keys to which authority is granted. Filter specifies the nature of the authority that is being granted. Both AuthorityStruct and Filter are represented as programs to maximize their generality. For example, the following PolicyMaker credential

pgp:"0x01234567abcdefa0b1c2d3e4f5a6b7" ASSERTS pgp:"0xf0012203a4b51677d8090aabb3cdd9e2f" WHERE PREDICATE=regexp:"From Alice";

indicates that the source PGP key "0x01234567abcdefa0b1c2d3e4f5a6b7" asserts that Alice's PGP key is "0xf0012203a4b51677d8090aabb3cdd9e2f".

Another major innovation in PolicyMaker is the decision to make credentials and policies the same type of object. A policy is also an assertion. The only difference is that policies are unconditionally trusted locally, and credentials are not. The source field in a policy assertion is just the keyword "POLICY", rather than the public key of an entity granting authority. Credentials are signed assertions, and the public key in the source field can be used to verify the signature.

Both credentials and policies are interpreted within a safe PolicyMaker execution environment. A PolicyMaker engine has no need to make any network connection, because it does not run trust protocols. Therefore, one property of a "safe" execution environment is limited network and resource access. The PolicyMaker engine is not dynamically extensible; if an unknown language is encountered during execution, PolicyMaker does not install software modules dynamically.

Because it does not have a trust protocol, PolicyMaker requires that the host application send all relevant credentials at the time it submits a request. This is considered a drawback, which limits its applicability in the context of the World Wide Web. The drawback can be illustrated in the following trust policy, which finds an authorized PICS label to make assertions about a particular Web object:

Retrieve the Web object first. If there is an embedded PICS label and the label is rated by entity A, B, or C, return that label (the label is authorized) and exit. If the label is rated by a unknown entity, query an auditor D for an endorsement of that entity. If the entity is endorsed by D, return the label and exit. If no label is found authorized, retrieve labels from bureau E and F in turn and process the labels as if they were embedded labels.

Clearly, an application evaluating the policy above cannot predict the "right" set of credentials and retrieve them prior to the policy evaluation, an assumption of the PolicyMaker approach. Moreover, the "right" set of credentials changes constantly with respect to the state of the Web object, the label bureaus, the auditor, and the network connection. The only way to evaluate that policy correctly and efficiently is to put the PICS trust protocol under policy control. REFEREE, as a successor of PolicyMaker, realized this deficiency early in the design phase, and it put trust protocols under policy control.

2.3.4Microsoft Authenticode

Microsoft Corporation was the first, among its competitors, to create a standard to tackle a particular trust management problem called code signing (see Section 2.4.1). Authenticode provides users with the assurance of accountability and authenticity for software downloaded over the Internet. The proposal went public in April 1996 [MS96], and the system was available in Microsoft Internet Explorer 3.0 in October 1996. Authenticode uses PKCS#7 [RSA97] and X.509 as the metadata format, X.509 as the trust protocol, a graphical interface to specify user policies and an implicit, non-extensible execution environment to evaluate user policies and run trust protocols. Below is a graphical representation of Authenticode in the trust management infrastructure.

Figure 6 Authenticode in the Trust Management Infrastructure

Authenticode is a complete trust management infrastructure in the sense that all components work together to solve a particular variation of "code-signing" problem. The drawbacks include:

Limited metadata format

Authenticode uses the PKCS#7 signature format and the X.509 identity certificate as the accepted metadata formats. The PKCS#7 signature format is used for making assertions about the software. The X.509 identity certificate is used for authenticating the PKCS#7 signature format. No other metadata formats are allowed.

Limited trust protocol

Authenticode uses the standard X.509 protocol to get a set of certificates for authentication purpose, as described in Section 2.3.2. No other trust protocols are allowed.

This single standard protocol imposes a serious constraint on the generality and applicability of Authenticode. For users who do not trust the X.509 authentication scheme, Authenticode becomes a useless system. For users who want to use Authenticode, they must accept all properties in X.509 as part of their trust policies. And if one day X.509 is compromised (e.g. if a root key is stolen), Authenticode will go down with it.

This analysis shows that it is almost a necessity to allow multiple trust protocols in the trust management infrastructure. It not only gives users the freedom to choose what they trust, but it also eliminates the single point of failure in an interconnected infrastructure of trust.

Limited trust policy

The trust policy in Authenticode is limited by the expressiveness of the graphical interface in the Internet Explorer. Below is a tour of the interface followed by discussion of its advantages and drawbacks.

Authenticode separates individual software publishers from commercial software publishers to distinguish between hobbyist code publishers and professionals. If a user receives a program signed by an unknown entity, Authenticode prompts the user for permission. Figure 7 shows the graphical interface for getting users' permission. On the left, the window interface prompts users to install a Microsoft program from a commercial software publisher. On the right, the window prompts users to install Dan Ziembienski's software from an individual software publisher.

Figure 7 Authenticode User Permission Interface

Inside the windows there are links to more information about the publisher, the software, and the certification authority. In Figure 8, users can configure their trust policies to trust a list of named entities unconditionally (i.e. "don't prompt me"). A checkbox lets users trust all commercial software publishers certified by a named CA.

Figure 8 Configuring a List of Trusted Entities in Authenticode

The advantage of this "interface driven" trust policy configuration is the ease of use. The drawback is the lack of expressiveness. For example, such policy schemes cannot do trust delegation. As an example in Figure 7, most users would not know Dan Ziembienski or whether he is trustworthy to publish software on the Internet. A solution is to delegate trust to a trusted auditor, who would vouch for the publishers that are considered trustworthy under the auditor's judgement. As long as the users trust the auditor, they can simply query the auditor once they encounter an unknown publisher. Trust delegation is just one of the many scenarios users will need to express their complex trust relationships. It is my belief that a carefully crafted policy language should come first in the design order and that the graphical interface should build on top of it.

Limited applicability

The inability to do trust delegation in Authenticode blurs the distinction between authentication and authorization from the application point of view, which imposes a serious limitation on its applicability. Given that all authenticated entities look alike, there is no way for an application to assign different authorizations. It is ok for applications where authorizations are trivial, such as electronic mail where anyone is authorized to write his or her own email messages. It is not ok for applications where authorizations are non-trivial, as in code signing where some content providers may not have the authorization to run their software in some users' local environments.

On the spectrum of simplicity versus generality in a system design, Authenticode sits at the simplicity end of the spectrum, and my thesis sits at the generality end of the spectrum. Authenticode technology is good in the sense that it forces both the content providers and the end users to face the problem of trust management in code signing. However, Authenticode does not adequately address the code signing problem or other trust management problems. It is my belief that when application developers have growing needs for trust management for their particular Web applications, they will realize the limitation on what Authenticode can do and demand a more general framework.