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