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


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

Home | Date list | Subject list