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