To:
keydist@cafax.se
CC:
Keith Moore <moore@cs.utk.edu>
From:
Stephen Farrell <stephen.farrell@baltimore.ie>
Date:
Fri, 18 Jan 2002 11:15:42 +0000
Reply-To:
stephen.farrell@baltimore.ie
Sender:
owner-keydist@cafax.se
Subject:
Re: problem statements...
I know its quite a bit distant from DNS, but there's a lot of overlap between this set of requirements and the xkms work being done in w3c [1]. In particular the xkms validate and locate operations seem to me to be very like the oracles you're looking for. Stephen. [1] http://www.w3c.org/2001/XKMS/ Keith Moore wrote: > > > 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 -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com