Trust Management for the World Wide Web

5.5Discussions

The REFEREE implementation in the Jigsaw proxy provides many insights on how a trust management system should work in a real-world application. This section attempts to address some of the concerns raised during the implementation, and explain how my particular implementation deals with them.

The first concern is the order in which REFEREE is placed with respect to other tasks in a host application that are concurrently affecting the behavior of the application. Caching is such a conservative task in the Jigsaw proxy, where the order to do trust management and caching matters. I place the REFEREE filter in the highest precedence, so it always gets evaluated. It is considered the most conservative approach, because it would accurately observe time-dependent trust elements, such as expired or revoked certificates, and make correct trust decisions based on them. However, if performance is more critical than accuracy, an application should place the caching filter in front of the REFEREE filter. Determining how the trust management task interacts with other processes in a host application is in a way another "trust policy", and it is outside the scope in which REFEREE can evaluate.

The second concern is whether actions issued during the evaluation of trust management are subject to the same trust management evaluation. For example in the Jigsaw proxy, download-applet requires Label Loader to call the Jigsaw Client API and fetch PICS labels from the network. The act of fetching PICS labels itself may be considered as a trust management problem and be subjected to a label-fetching trust management policy. My current implementation does not invoke another level of trust management during a trust management evaluation. I reject this idea for two reasons. First, it may introduce deadlock if the label-fetching policy in turn requests the same labels before the label can be fetched. The same Label Loader would be called recursively without making any progress. Second, I treat the action of fetching PICS labels as a trust protocol that is safe, secure, without any judgement of trust, therefore the action needs not be subjected to a trust management decision.

The third concern is whether REFEREE should introduce an explicit caching mechanism for performance reason. Currently REFEREE does not have one, and my implementation has no mechanism explicitly for caching purpose. However, my implementation transparently inherits the benefit of Jigsaw's internal caching mechanism (caching filter). When Label Loader needs to fetch labels from the network, it calls the Jigsaw Client API, where the cache filter is activated. The subsequent call to get the same label will be caught by the caching filter, and hence Label Loader gets caching for free. The observation implies that caching is supposed to be transparent from the rest of the processes in the application, and REFEREE needs not implement an explicit caching mechanism.

The fourth concern is whether REFEREE can be application independent as promised. As demonstrated in this implementation, the only two pieces that are "Jigsaw-centric" are the Jigsaw filter and the network fetcher. The Jigsaw filter traps requests from its host and bootstraps REFEREE. The network fetcher fetches information from the network, which are already in place for most network applications. Both of them are considered minimal for an application to do trust management. The rest of the code can be ported to other applications without any modification.

The fifth concern is whether REFEREE introduces disastrous performance hit for doing trust management. My implementation takes less than half a second to evaluate of the sample policy in Section 5.4, excluding any network time (my implementation supplies all the network information through a fixed input stream). This observation implies that the bottleneck to do trust management will not be the invocation of REFEREE modules, or evaluation of trust policies. Rather, the bottleneck will be the use of network, where fetching labels from the Web may incur long delays, or the use of cryptography, where validating digital signatures may take large CPU cycles. They are however, the unavoidable steps to make any trust decisions, but the overhead of REFEREE is minimal.

6Conclusion

My thesis identifies the trust management problems in the context of the World Wide Web and provides a two-part solution: REFEREE as the general-purpose execution environment and PicsRULZ and Profiles-0.92 as the policy languages. They utilize the existing trust protocols and metadata formats, and together, they form a complete trust management infrastructure in which trust is exchanged and established among mutually untrusting parties in an untrusted information infrastructure.

My thesis has four contributions to the area of trust management:

• 
  identify the concept of the trust management infrastructure, with the four basic building blocks in the infrastructure.
  
• 
  study current protocols and systems involving trust and identify their strengths and weaknesses.
  
• 
  propose a two-part solution: REFEREE as a generic execution environment, and Profiles-0.92 as a flexible trust policy language.
  
• 
  implement reference versions of REFEREE and Profiles-0.92 and prove that the concept of a generic trust management infrastructure is a realistic goal.
  

I do not claim the work on REFEREE and trust management is definitive or conclusive in its current state, but rather that it is a step forward in the understanding of the intricacies of trust. Of course, more work is needed. In particular, we need network experts to build robust and yet more efficient metadata formats and trust protocols. We need language experts to define simple and yet expressive trust policy languages. We need system experts to structure secure and yet dynamic execution environment. We also need user interface experts to deliver a user-friendly and yet feature-rich user interface to take advantage of a sophisticated trust management infrastructure beneath.

More challenges are ahead of us. Chin up!

Appendices

1. Modified BNF for PicsRULZ Policy Language

rule :: '(' 'PicsRule-' verMajor '.' verMinor rule-body ')'

verMajor :: integer

verMinor :: integer

rule-body :: '(' rule-clauses ')'

rule-clauses :: rule-clause+

rule-clause :: filter-clause | fail-clause | pass-clause |

name-clause | source-clause | service-clause |

                opt-ext-clause | req-ext-clause |

                extension-clause

filter-clause :: 'Filter' '(' attrvalpair+ ')'

fail-clause :: 'failURL' '(' attrvalpair+ ')'

url-list :: quotedURL+

pass-clause :: 'passURL' '(' attrvalpair+ ')'

name-clause :: 'name' '(' attrvalpair+ ')'

source-clause :: 'source' '(' attrvalpair+ ')'

service-clause :: 'serviceinfo' '(' attrvalpair+ ')'

opt-ext-clause :: 'optextension' '(' attrvalpair+ ')'

req-ext-clause :: 'reqextension' '(' attrvalpair+ ')'

ext-clause :: extension-clause-name '(' attrvalpair+ ')'

attrvalpair :: attribute whitespace value | primaryvalue

attribute :: alphanumstr

value :: quotedstring | '(' attrvalpair '(' whitespace

attrvalpair)* ')' 

primaryvalue :: quotedstring+ | '(' attrvalpair+ ')'

quotedstring :: ('"' notquotechars '"') | ("'" notquotechars "'")

alphanumchar :: alphanum+ 

whitespace :: ' ' | '\t' | '\r' | '\n' 

alphanum :: '0' - '9' | 'A' - 'Z' | 'a' - 'z'

notquotechars :: any ASCII characters between 32-127 except ' and "

comment :: '{' comment-text* '}'

comment-text :: any octets except '}'

PermissionExp :: "Unless-Prohibited" | expression

ProhibitionExp :: expression

expression :: simple-expression | or-expression | and-expression 

simple-exp :: '(' service '.' category op constant ')'

service :: any shortname defined in a serviceinfo clause

within this rule

category :: any transmit-name for a category defined by

the rating-system referred to by the matching system

op :: '>' | '<' | '=' | '!=' | '>=' | '=>' | '<=' | '=<' |

'all-equal' | 'none-equal' | 'includes'

constant :: [sign] alphanumchar ['.' alphanumchar]

or-expression :: '(' expression or expression [or expression]+ ')'

or :: 'or' | '||'

and-expression :: '(' expression and expression [and expression]+ ')'

and :: 'and' | '&&'

sign :: '-'

2. Modified BNF for Profiles-0.92 Policy Language

policy :: rule+

rule :: let-rule | combine-rule | invoke-rule |

install-rule | project-rule | match-rule |

url-match-rule

let-rule :: '(' 'let' '(' let-binding+ ')' rule+ ')'

let-binding :: '(' variable-name let-expr ')'

variable-name :: symbol

let-expr :: rule | ''

combine-rule :: unary-rule | multi-rule | threshold-rule

unary-rule :: '(' unary-op rule ')'

unary-op :: 'not' | 'true-if-unknown' | 'false-if-unknown'

multi-rule :: '(' multi-op rule* ')'

multi-op :: 'and' | 'or'

threshold-rule :: '(' 'threshold-and' threshold-val rule* ')'

threshold-val :: number

invoke-rule :: '(' 'invoke' policy-name statement-list

optional-arg* ')'

policy-name :: quoted-name

statement-list :: '(' statement* ')'

statement :: '(' context content ')'

context :: s-expression

content :: s-expression

optional-arg :: s-expression

install-rule :: install-policy | install-interp

install-policy :: '(' 'install-policy statement-list ')'

install-interp :: '(' 'install-interpreter' statement-list ')'

project-rule :: '(' 'tri-value' rule ')' |

'(' 'statement-list' rule ')'

match-rule :: '(' 'match' pattern rule ')'

pattern :: '*' | '+' | '.' | string-literal | symbol-literal |

restriction | '(' pattern* ')' | `\` string-literal |

`,` string-literal

restriction :: '(' 'RESTRICT' restriction-op transmit-name

value ')'

restriction-op :: '<' | '>' | '=' | '<=' | '>=' | '<>' |

'!' | '=!' | '<=!' | '>=!' | '<>!'

transmit-name :: as defined in [PICS97a]

url-match-rule :: '(' 'url-match' variable-name string-literal+ ')'

3. Modified BNF for the Returned Statement-List of Label Loader

returned-stmt :: '(' content* ')'

content :: '(' header version service poption* ratings ')'

header :: '(' '"label-loader"' quotedURL label-source ')'

label-source :: bureau | 'EMBEDDED' | 'ALONG-WITH'

bureau :: quotedURL

version :: '(' 'version' '"PICS-1.1"' ')'

service :: '(' 'service' quotedURL ')'

poption :: '(' option ')'

option :: 'by' quotedname | 'gen' Boolean |

'for' quotedURL | 'on' quoted-ISO-date |

'signature-rsa-md5' base64-string |

'exp' quoted-ISO-date | 'at' quoted-ISO-date |

'md5' base64-string | 'comment' quotedname |

'full' quotedURL | 'original' quotedname |

'extension' '(' mand/opt quotedURL data* ')'

ratings :: '(' 'ratings' rating* ')'

rating :: '(' transmit-name number ')' |

'(' transmit-name '(' multi-value* ')' ')'

transmit-name :: as defined in [PICS97a]

alphanumpm :: 'A' | ... | 'Z' | 'a' | ... | 'z' |

'0' | ... | '9' | '+' | '-'

urlchar :: alphanumpm | '.' | '$' | ',' | ';' | ':' | '&' |

'=' | '?' | '!' | '*' | '~' | '@' | '#' | '_' |

'%' hex hex

References

[BCKLMRS] Brezin, J., Chu, Y., Khare R., LaMacchia, B., Miller, J., Resnick, P., Strauss, M. (1996), "REFEREE Version 1.4d: Rule-controlled Environment for Evaluation of Rules, and Everything Else," Working draft.

[BFL96] Blaze, M., Feigenbaum, J., and Lacy, J. (1996), "Decentralized Trust Management," Proceedings of the 17^th Symposium on Security and Privacy, IEEE Computer Society, Los Alamitos, 1996, pp. 164-173.

[BFRS97] Blaze, M., Feigenbaum, J., Resnick, P., and Strauss, M. (1997), "Managing Trust in an Information-Labeling System," to appear in European Transactions on Telecommunications. (Special issue of selected papers from the 1996 Amalfi Conference on Secure Communication in Networks.)

[CCITT88a] CCITT (1988), Recommendation X.500 (ISO 9594): The Directory—Overview of Concepts, Models and Services.

[CCITT88b] CCITT (1988), Recommendation X.509: The Directory--Authentication Framework.

[CFLRS96] Chu, Y., Feigenbaum, J., LaMacchia, B., Resnick, P., and Strauss, M. (1997), "REFEREE: Trust Management for Web Application," Proceedings of the 6^th International World Wide Web Conference Proceedings, International World Wide Web Conference Committee, 1997, pp. 227-238.

[DLLC97] DesAutels, P., Lipp, P., LaMacchia, B., and Chu, Y. (1997), "DSig 1.0 Signature Labels – Using PICS 1.1 Labels for Digital Signature," W3C Working Draft, June 5, 1997.

[EFRT97] Ellison, C., Frantz, B., Rivest., and Thomas, B. (1997) "SPKI—Simple Public Key Certificate," Internet Draft, April 6, 1997.

[FL97] Feigenbaum, J., and Lee, P. (1997), "Trust Management and Proof-Carrying Code in Secure Mobile-Code Applications," PDARPA Workshop on Foundations for Secure Mobile Code, March 26-28, 1997.

[MS96] Microsoft Corporation (1996), "Proposal for Authenticating Code Via the Internet." Revision 1.1, available from http://www.microsoft.com/workshop/prog/security/authcode/authcode.htm.

[NCSA95] National Security Computer Association (1995), "Microsoft Word Document Macro Virus," Hard-Copy, Journal of the Chicago Computer Society, Volume 11, Number 10, October 1995, pp. 39-40, available from http://www.ccs.org/hc/9510/ncsa.html.

[Necula97] Necula, G. (1997), "Proof-Carrying Code," to appear in Proceedings of the 1997 ACM Symposium on Principle of Programming Languages.

[PICS97a] "Rating Services and Rating Systems and Their Machine-Readable Descriptions Version 1.1," W3C Recommendation.

[PICS97b] "PICS Label Distribution Label Syntax and Communication Protocols Version 1.1," W3C Recommendation.

[PICS97c] "PICS Profile Language Working Group – PicsRULZ," W3C PICS Working Group draft, available from http://www1.raleigh.ibm.com/pics/ProfilesWG.html.

[RL96] Rivest, R. and Lampson, B. (1996), "SDSI—a Simple Distributed Security Infrastructure Version 1.1," draft, available from http://theory.lcs.mit.edu/~cis/sdsi.html.

[RSA97] RSA Laboratories (1997), "PKCS #7: Cryptographic Message Syntax Standard Version 1.6," RSA Standards.

1 There is a Next Generation of PICS (PICS-NG) Working Group in W3C, whose goal is to create a next generation of PICS label format.

2 PolicyMaker credential syntax has evolved since [BFL96] was published. Readers should consult [BFRS97] for up to date information.

3 Macro is considered active code, and active code can be malicious in the form of a virus. An example of a macro virus is "Winword Concept" in Microsoft Word documents [NCSA95]. The virus is automatically executed whenever an infected document is opened within Microsoft Word. Once active, all documents using the File 'Save As' menu item are automatically infected.

4 For example, on May 16 1997 a team of researchers at the University of Washington found a verifier bug as part of a research effort developing automatic Java verification services. The team found that JDK1.1.1 Bytecode verifier does not check whether a method allocates enough space to hold the input arguments passed in from a caller. If a method is given more arguments than it has room for in the space allocated to its local variables, this could cause a stack overflow. This most likely leads to the Java VM crashing, but it can potentially be used for malicious attacks. See http://java.sun.com/sfaq for more information.

5 This concept was advocated by Sun Security Architect Li Gong at the JavaOne conference. See http://java.sun.com/javaone/sessions/slides/TT03/index.html for more information.