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] <UID|KID|FPT|DATE>
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
<DATE>, with
<DATE> 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 <lugnut@fluffy.org>
S: VFY
C: REQ KEY <lefty@circus.net>
S: FND
S: KEY <lefty@circus.net>: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 <lugnut@fluffy.org>
S: VFY
C: REQ KEY <bigred@pipe.org>
S: FND
S: ERR NOT FOUND <bigred@pipe.org>
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 <lugnut@fluffy.org>
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 <keyserv.moc.com>
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