[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
            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-
                 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).
                 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
                 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.
            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
            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
            4.  FND   (Server response to REQ, indicating search in
            5.  CHK   (Server declaration of checksum value)
            6.  ERR   (Server declaration of error condition)
            7.  FIN   (Server declaration of end of repetitive action
            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)
            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
                 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
            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
            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.
            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] ...
            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