Proposal for Implementing PTMK

By: Yang-hua Chu
Supervisor: Dr. Jim Miller, W3C Technology and Society Area Leader
Last Revised: 9/27/96

Introduction

The goal of my thesis is to implement a trust management system based on the existing PICS labeling system. The underlying mechanism is primarily based on the draft "PICS Profiles and Trust Management" by Brezin, Resnick and Strauss (shorthanded "PTMK draft"), with some modifications to suite my thesis criteria. The basic system has two parts: a PICS trust management kernel and an interpreter for the profiles scripting language and extended PICS labels (collectively shorthanded "PTMK"). They will both be implemented in Java. My final product will be a collection of documentation and demonstrable codes.

This proposal discusses only the modification I make to the PTMK draft for the purpose of my implementation, especially the handling of signature verification which is yet specified in PTMK. Please refer to the original draft for more detail regarding PTMK.

This thesis work is intended to be short (till the end of 12/96), so some of the interesting features in PTMK may not be implemented in this version. However, I will try to provide enough hooks in my design so that additional features can be added incrementally in the future. There is also a plan for me to continue this work after my thesis.

It is agreed that there will be a stable version of Profile language before October 11 (two weeks from the date this proposal is written). That version will go into my project implementation.

Typical Scenario

The scenario below describes a typical scenario of a user's trust policy (in English) for filtering documents downloaded from the World Wide Web:

   View this URL if a corresponding PICS label can be found either 
   embedded in the document or fetched from a named label bureau, 
   whose label is unexpired, signature is verified, message digest is  
  checked, and rating is below some scale by a named rating system.

It is a good starting point to see in this scenario what PTMK needs to extend and what can be simplified.

Handling Signature

There are two existing security features in PICS Label Syntax 1.1 which will be supported in my project : message digest (MD5) and digital signature (signature-RSA-MD5). MD5 is well handled in PTMK but signature-RSA-MD5 is not. I describe a mechanism below so that a profile can invoke a signature verification and review the status afterward, with the following assumptions:

All public keys are stored locally and are therefore inherently "trusted" by the application.
The notion of a "trusted public key" has only one interpretation; if a signature is verified by a trusted public key, the document signed by the signature is trusted. This is less functional than an assertion in PolicyMaker, where the meaning of a public key can be further specified by a filter written in a safe interpreted language.

The mechanism works as followed. Initially, the kernel receives a list of trusted public keys either from a file or from the application and it converts them into PTMK statements:

POLICY       ("J" "RSA" "0x1234abc...")              http://signature
POLICY       ("k" "RSA" "0x4312cba...")              http://signature
...

This type of statement is regarded as saying ""POLICY says ÒJÓ has a ÒRSAÓ public key with value Ò0x1234abc...Ò in mini-language Òhttp://signatureÓ".

When it comes time for the application to make a request to the kernel, the kernel first sets up the two statements for the user request and the user profile, appends the public key statements onto the statement list, fetches the default interpreter, and calls exec_label as in PTMK:

1 USER         ("view" "http://greatdoc")              http://actions-v1
2 app'n        (PICS-Profiles "http://..."             http://label
3 POLICY       ("J" "RSA" "0x1234abc...")              http://signature
4 POLICY       ("k" "RSA" "0x4312cba...")              http://signature
...

During the evaluation of a profile, if it encounters

(PICS-Profiles "http://profiles-0.9"
...
   (check-signature-rsa-md5)
...
)

the interpreter will first extract the entity who signed the label (in "by" field of the label), search if that entity's public key is ever spoken by POLICY, and if found, use that public key to verify the label's signature (in the Òsignature-RSA-MD5Ó field). Append the following statement to the statement list only if the signature is good:

SIGNATURE-RSA-MD5    ("[the label]")       http://label

In summery, the modifications needed are:

Kernel: convert a list of trusted public keys to PTMK statements, and append them to the statement list for each invocation.
Profile-0.9 grammar: add "(check-signature-rsa-md5)" action.
Profile 0.9 interpreter: add another module to handle RSA signature verification algorithm.

Simplifying PTMK

Because it is still uncertain whether executing arbitrary interpreters downloaded from the network is a good idea, the feature to do recursive calls to another interpreter will not be implemented at this point. It will in turns be a stub, when recursive call is invoked, returns no statement by default.

Due to the elimination of recursive interpreter calls, vouching mini-language will not be implemented. Moreover, RSA signature verification will be implemented as part of the Profile-0.9 interpreter, instead of being an independent interpreter as originally planned in PTMK. Furthermore, some of the features in Profile-0.9 grammar may not be implemented as a result of this.

Example

Similar to the scenario described above, the profile for this example is as followed:

(PICS-Profiles "http://profiles-0.9"
   (get-labels)
   (get-labels "http://bureau")
   (check-exp)
   (check-md5)
   (check-signature-rsa-md5)
   (expand languages traditional sources UNEXPIRED MD5 SIGNATURE-RSA-MD5)
   (service "http://musac" any-allows s :2)
)

The English translation is to view this URL if a corresponding PICS label can be found either embedded in the document or fetched from "http://bureau", whose label is unexpired, signature is authenticated, message digest is checked, and the Òhttp://musac sÓ rating is less than 2.

Further assume the user wants to view "http://greatdoc", which has no embedded label, but the label bureau "http://bureau" has one:

(PICS-1.1 "http://musac"
  by "J"
  for "http://greatdoc"
  exp "1997.2.7.T23:59-0000"
  signature-RSA-MD5 "=1234Ab+/56=="
  md5 "=4321Zy65/+=="
  labels ratings (s 1))

The user also happens to know the rater J's public key for sure, so J's signature for this label can be verified. Below is a sample trace under this particular situation:

1  USER         ("view" "http://greatdoc")              http://actions-v1

2  app'n        (PICS-Profiles "http://profiles-0.9"
                  (get-labels)
                  (get-labels "http://bureau")
                  (check-exp)
                  (check-md5)
                  (check-signature-rsa-md5)
                  (expand languages traditional
                     sources UNEXPIRED MD5 SIGNATURE-RSA-MD5)
                  (service "http://musac"
                     any-allows s :2))                  http://label

3  POLICY       ("J" "RSA" "0x1234abc...")              http://signature

4  "http://bureau"
                ("(PICS-1.1 "http://musac"
                    by "J"
                    for "http://greatdoc"
                    exp "1997.2.7.T23:59-0000"
                    signature-RSA-MD5 "=1234Ab+/56=="
                    md5 "=4321Zy65/+=="
                    labels ratings (s 1))               http://label

5  UNEXPIRED    ("(PICS-1.1 "http://musac" ...)")       http://label

6  MD5          ("(PICS-1.1 "http://musac" ...)")       http://label

7  SIGNATURE-RSA-MD5
                ("(PICS-1.1 "http://musac" ...)")       http://label

8  "J"          ("data" "greatdoc" "musac" "s" "1")     http://profiles

9  POLICY       ("allow" (service "http://musac"
                      any-allow s :1))                  http://profiles

10 POLICY       ("view" "http://greatdoc")              http://actions-v1

More remarks on the trace:

Statement 1, 2 and 3 are constructed by the kernel. Statement 3 represents a public key that the application trusts initially, and more public keys can be appended to the statement list. The kernel should append all trusted public keys to the list because it does not know yet which public keys will be used.
Statement 4 is fetched from the label bureau (get-labels "http://bureau")
Statement 5-7 are produced from statement 4, one at a time, after evaluating (check-exp), etc. Each statement will appear only if the test passes. Note that (check-signature-RSA-MD5) needs statement 3 to make its approval.
Statement 8 is parsed from statement 4 after statement 5-7 have evaluated successfully. Note that it will appear only if statement 5-7 appears.
statement 9 is constructed from statement 8 after evaluating (any-allow s :2)
statement 10 returns success after seeing statement 9.

Divide and Conquer

There are three major components to my implementation. I plan to implement in the order listed. The last part is built on top of the first two:

implement parser in Java: this includes s-expression parser, PICs label parser, parser for PICS extended label.
implement the kernel in Java.
implement the Profile-0.9 interpreter in Java.

Documentation and thesis will be written in concurrent with the implementation.

To keep track of my progress, I would like to meet with my thesis supervisor, Jim Miller, at least once every two weeks. I promise to submit the following via the web every two weeks:

a brief progress report
some writing
some code

Schedule

I have 12 weeks to complete my thesis. I divide up my time below in hope I can be finish my thesis in time.

Paul Resnick and Jim Miller also agreed that the version of Profile-0.9 language I will implement is frozen in two weeks.

Fri  10/11  end of 2nd week    the spec for Profile-0.9 is fixed
Fri  10/25  end of 4th week    finish the parser and the kernel
Fri  11/22  end of 8th week    finish the profile interpreter
Fri  12/6   end of 10th week   ready for a project demo
                               finish a preliminary thesis write-up
Fri  12/20  end of 12th week   finish the thesis write-up.

Comments

Comments are much appreciated. Please direct all comments to me. Thank you.