From: Geoff Dale <geoff1@home.net>
Date: Mon, 16 Sep 1996 06:52:18 +0800
To: cypherpunks@toad.com
Subject: (Long) RFC: Public Key Finger: A preliminary proposal for a distributed key publishing system
Message-ID: <199609151909.MAA10901@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

The original (html) document may be obtained at:

http://www.fqa.com/geoff/pkf.htm

- ---------------------------------------------------------------------------
                                                         Version 0.2, Draft

                             Public Key Finger

                        (aka the People's Key Front)

       A preliminary proposal for a distributed key publishing system

- ---------------------------------------------------------------------------

Wouldn't it be nice if distributing your public key(s) was as easy as
publishing your e-mail address? As a matter of fact, it would be nice if
you didn't even have to do anything more than giving out your e-mail
address.

Keyfinger is a way to make this possible.

Requirements:

Simplicity

Components must be easy to understand, use, integrate, set-up and maintain.

Scalability

The system must be designed to be distributed and scale to accommodate 
large
users like Netcom and AOL. To this end keyfinger uses the convention of
connecting to keys.host.domain.com, allowing the administrator to use
various methods to handle request traffic.

Flexibility

The system should be designed to allow interim solutions and phased
deployment. Because of the fact that this system will not be deployed all
at once, interim methods will be designed into the protocol.

Security

Ideally the fetching of keys should be across secure links, signed by the
key-server, to avoid man-in-the-middle attacks. The individual keys should
be self-certifying if signed by a known trusted entity (such as the ISP).

Protocol:

Client opens a socket connection to host (keys.host.domain.com or
host.domain.com or domain.com) on designated port (a default port should be
determined). Sends and inquiry string (user@host.domain.com) then the Host
returns the contents of the .keyplan file. If the connection fails, the
client may try to connect using http with a URL of form
(http://host.domain.com/~user/.keyplan). Other supported methods may be
finger and DNS lookup.

Components:

keyfinger

Program for fetching the key. E-mail programs could incorporate this to
allow automated key lookups within the mail authoring and authorization
process. Various search engines could use this to allow key searches.

Usage:

     keyfinger user[@host][.domain.com][@keyserver.domain.com][:port]
     ex: keyfinger geoff1@home.net

Host and domain are resolved in the standard manner, a default port is tbd.
The optional usage is to add an actual keyserver which could be used for a
more traditional key-server system.

keyfingerd

Program (daemon) run on isp's key server. Would automatically serve up
.keyplan files from user's home directories.

Some versions may access a local key database instead. 'Nym servers and
e-mail gateways would require this kind of service. The keyfinger server
would be responsible for keeping the keyplan entries up to date.

keyfinger-proxy

Program (daemon) running on firewall to allow keyfinger to run through
firewalls. Allows keyfinger-ing of foreign systems from within the 
firewall,
but not the reverse.

key-setup

Program that provides a gui interface to aid in the account setup. Should
be able to work with .keyplan files and key databases. Authentication
required to change key info required.

.keyplan

File in the user's home directory that contains the key information. User's
on ISP's that don't provide keyfinger service could publish their .keyplan
files in the top level of their web directory (/~/public_html or whatever).
The contents would be a multipart mime document containing available keys
with key-type (and size) information, perhaps in preference order.
Allowable mime parts would also include key-revocation certificates.

Note: It is a question as to how strictly these allowable types should be
enforced. To allow extension of new key types enforce mime-type: key/...
but not subtype (eg - key/pgp ).

content-handler

Java content-handler for dealing with .keyplan files. Actually a content
handler could be written for each key mime-type. The java code could
actually use http to do retrieval.

protocol-handler

Java protocol-handler for dealing with "keyfinger:" URLs. This would
essentially be an implementation of the keyfinger component.

Usage:

     keyfinger:user[@host][.domain.com][:port]

Action Items

In no particular order:

   * IETF Format Draft
   * Write reference code
   * Need port designation
   * Need mime-types for keys and the .keyplan file.

Important Dates

   * 96-09-07 First Publication to the Coderpunks list.
   * 96-09-14 Presented to SF Bay Cypherpunks Physical Meeting.

- ---------------------------------------------------------------------------
Page Maintained by Geoff Dale
Last Modified: September 15, 1996

_____________________________________________
         Geoff Dale - geoff1@home.net
          Paraphrasing Larry Niven:
- -- Just think of it as economics in action --
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMjxVrv1Xc5SjvRJ5AQEUoAQAnU193QKDiV5wW+Iv+ozfZfEH7cyi/cz3
LqduEO3BGkmW4Xfz/bXCwIwwSph1LEcePt6v0Wv+QUGOTXR/CZqjtxTzr3uCTHvP
0Zd76ZlfLD+JI3NSFniXsAXEeGeYLnQJqSHAa9cGUCYPh3/pgwfBuwNC+ZTgYkJo
ghLkuxHXrLE=
=4icU
-----END PGP SIGNATURE-----