Trust Management for the World Wide Web

3.5Bootstrapping REFEREE

There are two stages in a lifetime of REFEREE: the bootstrap stage, followed by the query stage. During the bootstrap stage, the host application provides REFEREE enough information to be aware of itself. After the bootstrap stage, REFEREE enters the query stage where the requests are accepted and processed.

There are two pieces of information supplied by the host application during the bootstrap stage:

• 
  trusted assertions
  
• 
  module database
  

All bootstrapping information is unconditionally trusted. The trusted assertions are key assertions frequently used by REFEREE operations, such as the root public key, cached credentials and certificates. The module database contains a minimum set of bindings that the host application is expected to use.

3.6Querying REFEREE

Once REFEREE finishes bootstrapping, it is ready to process queries for its host application. The figure below shows the steps for processing a query with three software modules:

Figure 15 Sample REFEREE Implementation

First, the dispatcher in the host makes a query to REFEREE, which composes an action name with a list of arguments (step 1). When REFEREE receives the query, it grabs the appropriate REFEREE module (module 1) from the module database (step 2), which consists of a policy and an interpreter pair. REFEREE invokes the interpreter with the policy and the list of input arguments. During policy interpretation, the module may invoke other modules (step 3 and step 5), which may in turn call the host-specific actions provided by the host application (step 4). When module 1 finishes the interpretation, REFEREE returns back to the dispatcher with the returned values from module 1.

4Policy Language

Chapter three shows how the REFEREE execution environment processes queries, interprets trust policies and runs trust protocols in a generic, application-independent way. To prove that REFEREE is indeed a general-purpose execution environment, I implemented two different policy language interpreters as REFEREE modules, namely PicsRULZ and Profiles-0.92.

Both PicsRULZ and Profiles-0.92 describe trust policies based on PICS labels. While PicsRULZ is considerably simpler and easier to use and implement, Profiles-0.92 is more general and expressive. Section one identifies the design goal of a policy language. Sections two and three describe PicsRULZ and Profiles-0.92 in turn. Section four provides four sample policy scenarios and their respective PicsRULZ and Profiles-0.92 translations.

4.1Design Goals

A policy language describes user policy in a machine-readable format. Despite its simple goal, the design of a good policy language may be more than an engineering task. The more complex the language is, the more expressive the policies can be, at the cost of being more difficult to implement, prove correctness, or build a user interface on top. This section sets asides these engineering tradeoffs, and focuses on the desired properties of a policy language.

Safe

The policy written by a policy language should not cause any undesirable side effect to its host application. That is, assuming the underlying policy interpretation is correct, there should be no way to write a valid policy that crashes the host computer.

Transferable

A profile should be transferable among different applications and platforms. This property allows not only a company to specify a profile for its employees to use on different applications and platforms, but also a user to carry his or her profile to other locations without reconfiguration.

Simple

A policy language should not be a general-purpose programming language (in the sense of Turing-complete), but a simple policy language designed specifically to describe trust policies. However, the language should have an extension mechanism to leave room for future expansion. This property comes hand in hand with the safety and the transferability of a policy language; a simpler language is easier to prove safety and more likely to be executed by an untrusted party when a policy is being transferred.

Well-defined

A policy written in a policy language should be unambiguous irrespective of its specific implementation. It is as if writing a book of law, where the citizens know exactly what is legal and not legal.

Expressive

The language construct should be expressive enough to accommodate realistic policies different users want to specify under different circumstances. The level of expressiveness may depend on programming ability of the people creating the policy, or the complexity of the user interface.

4.2PicsRULZ

PicsRULZ, by its name, is a rule-based policy language. There are language constructs to write filtering rules based on a requested URL or its associated PICS label attributes retrieved from the author or trusted third parties. It is a simple and concise policy language designed to work with the PICS protocol and metadata format.

PicsRULZ is the result of the PICS Profiles Language Working Group in the World Wide Web Consortium. The language specification is not finalized when the thesis is written. The description of PicsRULZ is based on the draft version presented in a PICS Interests Group Meeting on April 10 in Santa Clara, CA [PICS97c].

PicsRULZ language is organized into clauses. There are seven types of clauses. Some clauses may appear multiple times in a PicsRULZ rule. Although PicsRULZ is a rule-based language, partial evaluation order is enforced to prevent ambiguity. FailURL clause takes the highest precedence, followed by passURL clause. Filter clause is always evaluated last, and other clauses are evaluated arbitrarily between passURL and filter clauses. By default, if a clause does not specify a returned value, it is assumed that the evaluation continues. All symbols in PicsRULZ are case insensitive, and all quoted strings are case sensitive.

Each of the seven clauses in PicsRULZ is explained below. A complete BNF syntax is in Appendix A..

failURL

FailURL clause is a method to express a list of URL prefixes which are explicitly blocked. If the requested URL matches one of failURL list, the evaluation terminates immediately and outputs a block answer. For example, the clause

failURL ("http://www.harvard.edu" "http://www.caltech.edu")

blocks all URLs from Harvard and Caltech Web servers.

FailURL clause takes the highest precedence in the evaluation order. It may appear more than once in a PicsRULZ rule, but it is recommended that they be combined into a single failURL list.

passURL

PassURL has the same syntax as failURL but opposite in semantics. It means if the requested URL matches one of passURL list, the evaluation terminates and outputs a pass answer. PassURL takes the second precedence in the evaluation, after failURL. As with failURL, passURL may appear more than once but a single list is preferred. The following clause

passURL ("http://www.wellesley.edu")

explicitly allows all URLs with "http://www.wellesley.edu" prefix.

serviceinfo

Serviceinfo specifies information about a rating service. There are five attributes in a serviceinfo clause: name, shortname, bureauURL, ratfile and bureauUnavailable. Name attribute is the URL of the rating service. Shortname binds a local variable to a rating service. BureauURL specifies the location of a label bureau to retrieve PICS labels from. Ratfile contains either the URL or the actual text of the machine-readable rating description file. BureauUnavailable is an exception mechanism to specify what to do when the named label bureau cannot be contacted. Since users may want to utilize more than one rating service for a given URL, multiple serviceinfo clauses are allowed in PicsRULZ. All clauses must be evaluated before the filter clause because the filter clause may use the local name defined in the clause. In the following example,

serviceinfo ( name "http://6001.mit.edu/ratings/midterm.html"

shortname "6001"

bureauURL "http://6001.mit.edu"

bureauUnavailable true )

the clause retrieves PICS labels rated by "midterm" rating system from "6.001.mit.edu" label bureau. If the label bureau is unavailable, the evaluation terminates and returns true (allow).

filter

Filter clause operates on the PICS labels acquired from serviceinfo clauses. The clause is divided into two sub-expressions, pass-expression and block-expression, linked by an explicit and logic. That is, a URL passes the filter only if the pass-expression is true and the block-expression is false. The default value of the pass-expression is true, and the default value of the block-expression is false. Pass-expression and block-expression are composed of simple-expressions. A simple-expression compares an attribute of a PICS label with a constant (6.001.grade >= 5.0), returning a Boolean value (true/false). Simple-expressions can be combined with and and or operators to create arbitrary-depth pass-expressions and block-expressions. "Not" operator is explicitly omitted for clarity reasons. In the following example,

filter ( Pass "(6001.grade = 5.0 or 6001.grade < 2.0)"

Block "(6001.by = [e-mail])" )

the clause returns true (allow) only if the midterm grade is A (to brag about it), or is below D- (to drop the class), and the label does not come from the instructor Jim Miller (he likes to "spam" poor freshmen with fake grades, if students are not confused enough by his lectures).

extension

Extension provides a way to extend the functionality of PicsRULZ. As in PICS-1.1 extension, there are required (mandatory) and optional extensions. If the extension is required, the rule evaluator must understand and evaluate the extension. Optional extensions need not be evaluated; they are intended for documentation purpose.

In the following example,

reqextension ("http://www.w3.org/DSig/RSA-MD5.html")

filter (Block "(6001.by = [e-mail])"

Check-signature true)

the content of the "RSA-MD5" extension presumably defines a new attribute-value pair (check-signature )within a filter clause. Now filter clause returns true only if the PICS label contains a valid signature (a true value in the attribute) and the signature is not of Jim Miller's. In this case, the use of this extension prevents Jim to fake as another person to bypass the filtering rules.

name

Name clause provides local information about the rule, intended to facilitate the construction of a user interface. There are two attributes, namely rulename and description. Rulename attribute binds the rule to a local name. Description attribute is a more detailed description of the rule. For example,

name (rulename "6.001-Rule"

description "Viewing rule for the graded 6.001 midterm")

source

Source provides information about where the rule comes from. There are four fields in the clause. SourceURL field uniquely identifies the rule. Interested parties can also go to this location to find more information about the rule. CreationTool field identifies how the rule is constructed. Author field gives an identity (generally an e-mail address) of who creates the rule. LastModified gives the date and time that the rule was last modified. An example looks like the following:

source (sourceURL "http://web.mit.edu/bendiddle/6001.html"

creationTool "PicsRULZ-EDITOR/1.0"

author "[e-mail]"

lastModified "1997.05.06:12.34-0500")

Examples of PicsRULZ are in Section 4.4.