
		 A Trust Model for TIS/MOSS Version 7.1


INTRODUCTION

The TIS/MOSS database has been completely replaced by a system that is
more suitable for use by individual users.  In particular, the old
system was intended for use in multi-user environments in which the
services and database would be centrally managed.  With the new system,
each user manages a database(s) of user records, which are stored in
ASCII text files.  The use of text files facilitates the use of common
text-based tools for managing the database, for example, text editors.

However, using text files dramatically changes the security of the
database and the trust model available for validating the public keys.
Previously, files in the database were essentially binary files that
required programmatic access to their contents.  This facilitated
control over the contents of the database.  With the new system,
although TIS/MOSS provides a library of functions for accessing the
database, nothing can be assumed about the contents of the database.

This difference changes the process by which a public key is validated.
Whereas certificates guaranteed the existence of an issuer and a
certification path, not only does the new database not guarantee the
existence of this information, it may not guarantee the integrity of the
information even when it is present.  What follows is the specification
of the database model, a description of how to specify correct keys,
followed by a description of how public keys are validated with the new
system.  The last section describes the database access library provided
by TIS/MOSS.


DATABASE MODEL

The database model will be described formally in terms of subjects,
objects, and rules.  The subjects are as follows:

	authorized users
	un-authorized users

An authorized user is one who may add, delete, or change the value of an
object.  All other users are unauthorized.

The objects are as follows:

	public key database user records
	private key database records

The public key database is comprised of a set of user records.  Each
user record is comprised of a set of tag/value pairs.  The only required
tag is "public-key" and its value is the printably encoded, ASN.1
encoded public key.  Two other tags are "private-key-access" and
"private-key".  The first indicates the mechanism by which the private
key is accessed and the second specifies the information necessary to
access the private key.  The combination of these two entries specify
the format and location of a private key database record.

The rules which govern the state of the database are as follows:

	any subject may retrieve public key database user records

	authorized users may add, delete, or change any object

TIS/MOSS does not support an explicit mechanism to determine whether a
subject is authorized to add, delete, or change public key database user
records.  Authorization is relegated to the operating environment, for
example, in a UNIX environment, if the files containing the user records
to be changed are protected such that the subject may overwrite the file,
then that subject is an authorized user.

TIS/MOSS does support one mechanism suitable for restricting access to
private key database records when the records are stored in a file.
This mechanism works in addition to any controls that may be imposed by
the operating environment.  In particular, a user may encrypt the
private key database record.  The user enters a passphrase that is
converted to a DES key which is used to encrypt and decrypt the private
key database record.  When this mechanism is used and the object to be
added, deleted, or changed is a private key database record, an
authorized user is one who is authorized by both the operating
environment and TIS/MOSS.  The user must be able to provide the
passphrase that correctly decrypts the private key database record to be
authorized by TIS/MOSS.


PUBLIC KEY CORRECTNESS

Previously, public keys were required to be embodied in a certificate.
Among other things, a certificate contained a public key, a name form
identifying the owner of the public key, a name form identifying an
issuer vouching for the binding between the public key and its owner,
and a digital signature computed by the issuer over the contents of
the certificate.  The PEM specifications defined a strict hierarchy
for the certificates with a single, well-known root.

As a result, given knowledge of the public key of the root of the
hierarchy, a certificate, and hence its public key, would be considered
valid if a path from the certificate to the root could be constructed
and all the information in it and each certificate of the path was
valid.  The path thus constructed is called a certification path.

A user always knew if the correct public key was being used since if the
certificate was valid the distinguished name of the owner of the public
key could be extracted from the certificate and displayed for the user.
A user could then evaluate the name to determine if the public key being
used is the correct one.

With the integration with MIME, MOSS no longer requires the existence
of a certificate.  Users may generate public/private key pairs and
exchange public keys via whatever mechanism is most suitable for them.
As a result, TIS/MOSS provides a database that is "anchored" by public
keys instead of certificates.

Conceptually, each user database is comprised of two parts: the public
key database and the private key database.  The public key database is a
text file containing a set of user records each of which is comprised of
at least a public key.  The private key database is for the storage of
the private keys corresponding to public keys in the user's public key
database.  In order for TIS/MOSS to access a private key, there must
exist a user record with the corresponding public key which indicates
that the private key exists and how to access it.  It is not possible to
access a private key without first accessing its corresponding public
key.  This separation allows users to easily share public key databases
while protecting their private keys from unauthorized users.
Subordinating private keys under public keys allows the specification of
a single interface for accessing objects and the flexibility to support
a variety of private key access methods, for example, storing private
keys in either files or smart cards.

When a user wishes to send or receive a MOSS message, the user must
ensure that the correct public or private key is used.  Before the
public or private key can be validated (determined to be correct), we
must define what is meant by "correct public key" and "correct private
key".

When a user is sending a digitally signed message, the correct private
key must be used.  The private key used is the correct one if it is a
key which belongs to the user and its use conveys the context desired by
the user (for example, a user may have a key for personal correspondence
which is distinct from the key used for work-related correspondence).
The latter decision is not made programmatically by TIS/MOSS; if a user
selects a private key to be used TIS/MOSS will use it if the user owns
it.  TIS/MOSS determines whether the user owns the key with two tests.
First, if the operating environment will allow the user to retrieve the
private key from storage, the user is assumed to own the private key.
Second, if the private key is encrypted, the user is assumed to own the
private key if the correct passphrase is provided that decrypts it.

When a user is receiving a digitally signed message, the correct public
key of the originator must be used to verify the signature on the
message.  The public key used is the correct one if its use verifies the
signature of the message and if it is known to belong to the originator
of the message.  TIS/MOSS can determine if a public key verifies the
signature of a message but it can not determine if a public key belongs
to a particular originator.  However, when a user determines that a
public key belongs to a particular originator, TIS/MOSS does provide a
mechanism with which the user can programmatically indicate the binding
between the originator and the public key and thus, in the future, it
will be able to programmatically verify that the correct public key is
being used.

When a user is sending an encrypted message, the correct public key of
the recipient must be used to encrypt the Data Encrypting Key (DEK) used
to encrypt the message.  The public key used is the correct one if its
use encrypts the DEK such that only the desired recipient of the message
can decrypt it and if it is known to belong to the desired recipient of
the message.  To know if the public key will encrypt the DEK only for
the intended recipient, the user must know that the public key belongs
to the recipient.  TIS/MOSS can not determine if a public key belongs to
a particular recipient.  However, when a user determines that a public
key belongs to a particular recipient, TIS/MOSS does provide a mechanism
with which the user can programmatically indicate the binding between
the recipient and the public key and thus, in the future, it will be
able to programmatically verify that the correct public key is being
used.

When a user is receiving an encrypted message, the correct private key
must be used to decrypt the DEK used to encrypt the message for the
user.  The private key used is the correct one if it is a key which
belongs to the user.  TIS/MOSS determines whether the user owns the key
with two tests.  First, if the operating environment will allow the user
to retrieve the private key from storage, the user is assumed to own the
private key.  Second, if the private key is encrypted, the user is
assumed to own the private key if the correct passphrase is provided
that decrypts it.

In summary, a public or private key is the correct one if it correctly
processes a message and/or is known to belong to the intended originator
or recipient.  TIS/MOSS can always determine if a public or private key
correctly processes a message.  However, only a user knows for sure who
owns a key.  However, once a user has made the determination of who owns
a key, TIS/MOSS provides a mechanism for the user to indicate this
binding such that it can be verified programmatically the next time the
key is accessed.

There are three steps that a user must complete to establish that a key
is the correct key.

1. First, the user must verify the key currently possessed is the
   correct key.  Initially, the user will need to do this via some
   out-of-band mechanism, for example, perhaps the user will communicate
   the key over the telephone with its owner.

2. Second, the user must determine what additional information must be
   bound to the key so the user will recognize the key as the correct
   one.  For example, at a minimum, it is expect that a user will bind
   the owner's name to each key.  Additionally, a key is more useful if
   a short name, e.g., an alias, is also bound to the key.  In this way,
   when the key is used, a user's user interface could display these
   values instead of the key when identifying the source or destination
   of a message.  In the interests of simplicity, TIS/MOSS binds all
   information in a user record together.  A user need only make sure
   that all the desired information is in the user record.

3. Finally, the user must indicate the binding in the database.  Since
   the integrity of the database file can not be guaranteed, the
   mechanism chosen to indicate the binding is a digital signature.  The
   user computes a hash over the entire contents of the user record and
   signs this hash value with a private key owned by the user.  This
   signature, along with an indication of who signed it, is added to the
   user record and stored in the database.  In particular, a "trusted"
   tag is added the value of which has 2 parts separated by a comma:

	alias, MIC-INFO

   The alias is the alias of a user record identifying the originator of
   the digital signature.  The MIC-INFO has the same syntax as the
   MIC-INFO field of a MOSS message.

The TIS/MOSS utility mosskeysign is used by a user to indicate that user
records are correct.  It computes the digital signature and updates the
user's public key database file.


PUBLIC KEY VALIDATION

Given a database of public key records which contains at least one
public key known to be correct, it is now possible to validate public
keys.  A user considers a public key valid if either of the following is
true:

1. the public key belongs to the user

2. it is possible to construct a sequence of public keys following the
   path directed by the aliases in their respective trusted tags
   beginning with the public key in question and ending with a public
   key owned by the user.

Case 1 is self-evident.  The keys a user owns must be correct and
therefore must be valid.  The simplest example of case 2 are keys which a
user explicitly indicates are correct.  However, it is also possible a
user may decide to trust another user and, as a result, consider valid
any public key that user indicates is correct.

The algorithm, in psuedo-code, is as follows.

validate_user(user, root)
user_record  user, root
{
    get public-key from user
    get trusted from user
    	get trusted_alias from trusted
	get signature from trusted

    get root_aliases from root

    if trusted_alias is not in root_aliases
	lookup trusted_user with trusted_alias
    else
	trusted_user = root

    get trusted_public_key from trusted_user
    compute new_hash over user
    "decrypt" signature to get hash
    compare hash and new_hash

    if (trusted_user != root)
	validate_user(trusted_user, root)

    return OK
}


TIS/MOSS DATABASE ACCESS ROUTINES
