Proposal for Implementing PTMK

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


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: 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"
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:

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.


Similar to the scenario described above, the profile for this example is as followed:
(PICS-Profiles "http://profiles-0.9"
   (get-labels "http://bureau")
   (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 "http://bureau")
                  (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

                ("(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:

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:

  1. implement parser in Java: this includes s-expression parser, PICs label parser, parser for PICS extended label.
  2. implement the kernel in Java.
  3. 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:


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 are much appreciated. Please direct all comments to me. Thank you.