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

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

On Sun, 15 Sep 1996, Geoff Dale wrote:
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
--------------------------------------------------------------------------- [snip]
is that the Judean People's Key Front, or the People's Key Front of Judea? :-j (old british joke, for the monty-python impaired...) -- Jonathan AH Hogg, Computing Science, The University, Glasgow G12 8RZ, Scotland. jonathan@dcs.gla.ac.uk http://www.dcs.gla.ac.uk/~jonathan (+44)141 3398855x2069
participants (2)
-
Geoff Dale
-
jonathan