INTERNET DRAFT David K. Merriman File: merriman@amaonline.com draft-merriman-realtime-key-00.txt December 27, 1996 Expires: June 27, 1997 Proposal of a suggested protocol for an interactive, real- time cryptographic 'key' server Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract With the increase in privacy-enabling cryptographic software, there exists the growing problem of verification of the 'validity' of a cryptographic 'key'. That is, the recipient of (for example) a PGP-signed email message from an unknown person generally has no ready, convenient means to verify that the 'signature' on the message actually belongs to the sender. To verify the relationship between a cryptographic 'key' and an identity (real or anonymous), it is necessary for an individual to contact one of several existing "manual" keyservers as a separate process, request the key (if it exists on that keyserver), and retrieve it before being able to use it for any reference or validation purposes. This draft is meant to propose a protocol/system that would both enable the automatic retrieval of cryptographic keys, and the exchange of keys between servers (both new keys, and those deleted through revocation certificates). This proposal could be extended to allow retrieval of cryptographic certificates and/or 'credentials' with relatively minor difficulty. 1 draft-merriman-realtime-key-00.txt David K. Merriman 1. Introduction It is proposed that the keyserver 'listen' on port 1076, and reply on port 1099; these ports have been selected arbitrarily, and may be changed as needed. 1.1 Operations It is expected that the operations required of the keyserver will be limited to requests for, and submissions of, key data. 1.2 Key Data Initially, it is proposed that a minimum amount of information be available for request. A 'minimum' set of data would include: 1. User ID (in the form of a bracket-delimited email address) 2. Key Fingerprint (ascii hexadecimal string) 3. Key (ascii-armored character string) 4. Key ID (ascii hexadecimal string) 1.3 Server Actions The keyserver may initially respond to a limited number of commands: 1. Requests for keys, by User ID or Key ID 2. Requests for key fingerprints, by User ID or Key ID 3. Requests for User ID, by Key or Key ID 4. Requests to be added to the keyserver database 5. Requests to revoke a key 6. Requests for key additions and deletions 7. Requests for listing(s) of alternative keyservers 1.4 Command/Response To minimize usage of bandwidth, the exchange of data and/or commands between systems should be minimized. Toward this end, commands could be limited to 3-characters. Due to the limited number of actions that the keyserver would be called on to perform, the command set could be limited to: 2. REQ (Client request for information) 3. IAM (Client declaration of identity for security purposes) 4. FND (Server response to REQ, indicating search in progress) 5. CHK (Server declaration of checksum value) 6. ERR (Server declaration of error condition) 7. FIN (Server declaration of end of repetitive action sequence) 8. DEL (Client request deletion of key from server) 9. VFY (Server request for verification of deletion) 10. KIL (Client verification response to VFY) 11. CAN (Client cancel response to VFY) 12. HLO (Server response to connection) 13. VAL (response that data received was valid) 14. INV (response that data received was invalid) 2 draft-merriman-realtime-key-00.txt David K. Merriman 2. Key Data Retrieval 2.1 Requests Criteria A client may request one of: key ID, key Fingerprint, a key itself, or a User ID, using either of the other items as the search criteria. In other words, if requesting a key, the search may be done using the Key ID, Key Fingerprint, or User ID as the criteria. If a Client wishes/needs more that one item, the Client should request the Key, and extract the information needed locally. 2.2 Request Format A request shall be in the format: REQ [KEY|FPT|UID|KID|SVR|NKY] where KEY is an ascii-armored key, FPT is an ascii key fingerprint, UID is an ascii User ID, KID is an ascii Key ID, SVR is an ascii list of keyservers known to the current host, NKY is an ascii list of keys added/removed since , with in the format YYYYMMDD:HHMM 3. Key Data Submittals 3.1 Submission Criteria A client may request submission of a key through the use of the ADD command. Similarly, a request for the removal of a key may be submitted through the DEL command. Deletions should also require a signed, valid Key Revocation certificate. 4. Security Issues 4.1 Server Security A keyserver should exercise the highest security measures consistent with the nature of the transaction/request. Steps should be taken to protect against falsified submissions, perhaps through verification that the Client's domain is included in the domain for the submitted item (ie, disallow requests affecting mykey@foo.com that originate from lugnut@bar.org) 4.2 Data Transfer It is suggested that all data transfers between Server and Client be in the form of ascii text (Uuencoded, etc). Further, it is suggested that the nature of each transaction, and the amount of data to be transferred, be made explicit prior to the start of actual data exchange. Finally, a simple means of checksum or data validation should be included to minimize data corruption. 3 draft-merriman-realtime-key-00.txt David K. Merriman 5. Other Considerations This proposal explicitly declines to address the means and methods of local storage of keyserver data. Futher, it explicitly discourages the use of any binary protocol or data format, so as to ensure widest possible implementation of the protocol, and computing platform independence. It is STRONGLY suggested that any additions to, or modifications of, this protocol retain the spirit of this proposal. 6. Examples The following are examples of typical exchanges that might occur under this proposal. 6.1 Request for User Key, based on User ID (successful) ... [connect] ... S: HLO keyserver.foobar.com C: IAM S: VFY C: REQ KEY S: FND S: KEY :LEN 1053 C: VFY S: {sends ascii key data} S: CHK {CHECKSUM} C: VFY C: BYE S: BYE ... [disconnect] ... 6.2 Request for User Key, based on User ID (failure) ... [connect] ... S: HLO keyserver.foobar.com C: IAM S: VFY C: REQ KEY S: FND S: ERR NOT FOUND C: VFY ;if bad UID, Client sends INV, Server waits for new command C: BYE S: BYE ... [disconnect] ... 4 draft-merriman-realtime-key-00.txt David K. Merriman 6.3 Request for Keyserver list ... [connect] ... S: HLO keyserver.foobar.com C: IAM S: VFY C: REQ SVR S: FND S: SERVERS:{number of servers} C: VFY ;start loop - parse next line to ensure synch S: SERVER_{COUNT}:LEN {LENGTH} S: {sends server data} S: CHK {CHECKSUM} C: VFY ;end loop, increment count C: BYE S: BYE ... [disconnect] ... 6.4 Request for keylist changes ... [connect] ... S: HLO keyserver.foobar.com C: IAM S: VFY C: REQ NKY S: KEYS:{number of servers} C: VFY ;start loop - parse next line to ensure synch S: (ADD|DEL) KID_{COUNT}:LEN {LENGTH} S: {sends keyID} S: CHK {CHECKSUM} C: VFY ;end loop, increment count C: BYE S: BYE ... [disconnect] ... NOTE: transfers between keyservers may elect to bypass validation process for key addition/removal. Author's Addresses: David K. Merriman 209 S. Jackson Amarillo, TX 79101 merriman@amaonline.com 5