[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Edward Lewis <lewis@tislabs.com>
cc: keydist@cafax.se
From: Keith Moore <moore@cs.utk.edu>
Date: Thu, 17 Jan 2002 13:29:42 -0500
In-reply-to: Your message of "Tue, 15 Jan 2002 17:50:21 EST." <v03130300b86a60c0a0f7@[192.94.214.127]>
Sender: owner-keydist@cafax.se
Subject: problem statements...

> Problem statements.  Requirements.  Vulernabilty assesments.  Trust
> assumptions per protocol.  That is where we need to begin.

Okay, here's a stab at a problem statement:

As an applications developer, what I would like to have are two oracles:

- one which I can ask:
  "please assess the validity and trustworthiness of this
   key, certificate, or signed statement"

  I would use this to validate an SSL key, SSH key, a signed MIME 
  message, whatever.

  The answer might be a list of (validity, trustworthiness, path) triples:

  - validity having possible values of true, false, or unverifiable;
  - path being an ordered list of authorities (and the degree of trust 
    placed in each) that were used to establish trustworthiness
  - trustworthiness being an expression of the constraints that should
    be placed on the use of this key.  these constraints would be 
    derived from both locally-supplied information and information
    contained in the certs used to verify the key.

- another which I can ask:
  "please find zero or more public keys for principal X (for purpose
   Y), and assess the trustworthiness of each"

  I would use this when I wanted to encrypt a message to send to X
  while minimizing the potential for disclosing it to other parties.

Each of these oracles would be defined in terms of algorithms (not 
APIs) that take input both from locally-supplied information (in 
standard formats) and information obtained from over the network.

Some Requirements:

- no party or key should be trusted axiomatically for any purpose

- it must be possible for users to specify the degree of trust 
  (or lack thereof) which these oracles invest in any key or cert.

- principals should be able to advertise multiple keys
  (for different purposes, or using different strengths/algorithms)

- principals should be able to advertise multiple paths by which their
  keys can be validated (e.g. via DNS root, via well-known CAs,
  or via mutually-trusted third party) 

- system should be able to validate keys of principals, not just 
  host or service names

- needs to scale to 100s of millions of principals per domain

Keith

Home | Date list | Subject list