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

(Long) RFC: Public Key Finger: A preliminary proposal for a distributed key publishing system


The original (html) document may be obtained at:


- ---------------------------------------------------------------------------
                                                         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

Keyfinger is a way to make this possible.



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


The system must be designed to be distributed and scale to accommodate 
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.


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.


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).


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 ([email protected]) 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.



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.


     keyfinger user[@host][.domain.com][@keyserver.domain.com][:port]
     ex: keyfinger [email protected]

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.


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.


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


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.


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 ).


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.


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



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 - [email protected]
          Paraphrasing Larry Niven:
- -- Just think of it as economics in action --
Version: 2.6.2