home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rfced-info-dixon-01.txt < prev    next >
Text File  |  1997-01-17  |  15KB  |  394 lines
  1.  
  2.  
  3. INTERNET-DRAFT                                            INTERNET-DRAFT
  4.  
  5. Network Working Group                 Jim Dixon (SDR Technologies, Inc.)
  6. INTERNET-DRAFT                                              January 1997
  7. Category: Informational
  8. Expire in six months
  9.  
  10.  
  11.          Political Disclosure Transmission Protocol (DISCLOSE)
  12.  
  13.                      <draft-rfced-info-dixon-01.txt>
  14.  
  15. Status of this Document
  16.  
  17.    This document is an Internet Draft.  Internet Drafts are working
  18.    documents of the Internet Engineering Task Force (IETF), its Areas,
  19.    and its Working Groups. Note that other groups may also distribute
  20.    working documents as Internet Drafts.
  21.  
  22.    Internet Drafts are draft documents valid for a maximum of six
  23.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  24.    other documents at any time.  It is not appropriate to use Internet
  25.    Drafts as reference material or to cite them other than as a
  26.    "working draft" or "work in progress."
  27.  
  28.    To learn the current status of any Internet-Draft, please check the
  29.    "1id-abstracts.txt" listing contained in the internet-drafts Shadow
  30.    Directories on:
  31.  
  32.          ftp.is.co.za (Africa)
  33.          nic.nordu.net (Europe)
  34.          ds.internic.net (US East Coast)
  35.          ftp.isi.edu (US West Coast)
  36.          munnari.oz.au (Pacific Rim)
  37.  
  38. Abstract
  39.  
  40.     This document details a protocol which allows political candidates
  41.     and related committees to electronically transfer financial
  42.     disclosure filings (as now often required by law) to their
  43.     associated governmental entities, for the purpose of review, and
  44.     then making these filings easily publicly accessible.
  45.  
  46. History and Overview
  47.  
  48.     Political candidates, parties, committees and such have been
  49.     required to file financial disclosure information (such as
  50.     contribution, and expenditure data) related to their campaign, and
  51.     sometimes even while in office, to their associated governmental
  52.     entities for a number of years.
  53.  
  54.     Recently, some governments have started requiring these filings to
  55.     be submitted electronically, so that the data can be easily
  56.     processed, and made available publicly (e.g. via the Internet) in
  57.     an expedient manner.
  58.  
  59.     Until now, these electronic submissions have been made via floppy
  60.     disk (in various formats) and have been nearly impossible to manage.
  61.  
  62.     This document details a protocol whereby a filer of such
  63.     disclosure information is able to transmit their filing
  64.     electronically, either via the Internet, or via other means (such
  65.     as dial-up lines) in a secure and accountable manner.
  66.  
  67.     Implementation of this protocol, both for the roles of client and
  68.     server, should be fairly simple, and apply to many different
  69.     hardware and software platforms equally well. This will allow for
  70.     many different vendors' products to easily communicate with each
  71.     other within this realm, thus allowing both the filers and
  72.     governments to have a wide variety of options from which to choose
  73.     when deciding how to implement the use of this protocol.
  74.  
  75.  
  76. Jim Dixon                                                       [Page 1]
  77.  
  78. INTERNET-DRAFT                                            INTERNET-DRAFT
  79. DISCLOSE Protocol
  80.  
  81.  
  82. The DISCLOSE specification
  83.  
  84. Overview
  85.  
  86.     The DISCLOSE server specified by this document uses a stream
  87.     connection (such as TCP or direct modem) and text-based commands and
  88.     responses. It is designed to accept connections from hosts, and to
  89.     provide a simple and secure method of transferring disclosure
  90.     filings.
  91.  
  92.     This server is only an interface between client programs and the
  93.     entity to which they are filing. It does not perform any user
  94.     interaction or presentation-level functions. These "user-friendly"
  95.     functions are better left to the client programs, which have a
  96.     better understanding of the environment in which they are operating.
  97.  
  98.     When used via Internet TCP, the port assigned for this service is
  99.     667.
  100.  
  101.     The protocol is designed to work in the same manner, regardless of
  102.     the transmission media (whether it is via TCP or direct modem,
  103.     etc.).
  104.  
  105.     If used via direct modem, it is highly recommended that an error-
  106.     correction protocol be used within the modem, such as MNP5.
  107.  
  108. Character Codes
  109.  
  110.     Commands and replies are composed of characters from the ASCII
  111.     character set.  When the transport service provides an 8-bit byte
  112.     (octet) transmission channel, each 7-bit character is transmitted
  113.     right justified in an octet with the high order bit cleared to zero.
  114.  
  115. Line formatting
  116.  
  117.     All data sent to and received from the server is contained in lines
  118.     of ASCII text terminated by the ASCII carriage return character (0d
  119.     hex) and the ASCII linefeed character (0a hex).
  120.  
  121.     In this specification, [Blank Line] refers to line containing no 
  122.     text, terminated by carriage return/linefeed (the characters 0d/0a
  123.     by themselves).
  124.  
  125.  
  126.  
  127.  
  128.  
  129. Jim Dixon                                                       [Page 2]
  130.  
  131. INTERNET-DRAFT                                            INTERNET-DRAFT
  132. DISCLOSE Protocol
  133.  
  134.  
  135. Transmission formatting
  136.  
  137. Server to Client
  138.  
  139.     When the client connects to the server, the server transmits a
  140.     header, consisting of some (random) sign-on text, server identity
  141.     and entity identity information. It then waits (a maximum of 600
  142.     seconds) for a response from the client. After the response has
  143.     been received (or a time-out occurs) the server responds with a
  144.     single line response code (see below), and closes the connection.
  145.     If the server receives a pre-mature closure of the connection from
  146.     the client, it aborts the operation.
  147.  
  148. Client to Server
  149.  
  150.     The client connects to the server, and then waits for the server to
  151.     send its header. If the server has not finished sending the header
  152.     within 600 seconds, the client should abort the operation and close
  153.     the connection. The client then sends a PGP-ASCII-armor file (with
  154.     the line endings of the physical file either ASCII linefeed (0a
  155.     hex) alone or carriage return/linefeed (0d/0a hex)), consisting of
  156.     a header (see below) and the filing in the governmental entity's
  157.     file format. This file format varies from entity to entity, and
  158.     therefore cannot be documented here. The client then waits for the
  159.     server to give a one-line response. If this response is not
  160.     received within 600 seconds of the end of the transmission of the
  161.     PGP-ASCII-armor file, the client should abort the operation and
  162.     close the connection.
  163.  
  164. Client/Server Interaction
  165.  
  166.     When the client first connects to the server, the server sends out
  167.     an optional welcome message (of random size and content, as long as
  168.     it does not contain the word DISCLOSE: at the beginning of the line)
  169.     and a header, consisting of the Site ID of the server, and the 
  170.     Entity ID(s), and other information about the entity(s) for which it
  171.     is providing service, and its PGP Public Key information in the
  172.     following example format:
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182. Jim Dixon                                                       [Page 3]
  183.  
  184. INTERNET-DRAFT                                            INTERNET-DRAFT
  185. DISCLOSE Protocol
  186.  
  187.  
  188. [Connection open]
  189. SDR Technologies DISCLOSE server version 1.1 7/27/96
  190.  
  191. Brought to you by SDR Technologies, Inc. Agoura Hills, CA
  192. For more information on this system, call (818) 865-1310
  193.  
  194. Serving State of Hawaii, State of Washington, City/County of San Francisco
  195.  
  196. Access to this system is limited to authorized persons only.
  197. Unauthorized access is subject to criminal prosecution.
  198.  
  199. DISCLOSE: SDRTECH1
  200. Entity: HI State of Hawaii
  201. Entity: SF City/County of San Francisco
  202. Entity: WA State of Washington
  203. [Blank Line]
  204. -----BEGIN PGP PUBLIC KEY BLOCK-----
  205. Version: 2.6.2
  206. ([Blank Line] - Part of PGP public key block)
  207. mQBtAzHkANQAAAEDAMqT9WNBT6d8eDbzqtL3WKXrKPaZGwNSoRfkDmMA/ze2aDye
  208. be+giWklnzj4h9QfD/b8Rdm+mpdBcBb29gRR8gMxUX/gxzYc0WDT26WXKbs3IIsc
  209. pDfB7+CtgySy+uYYjQAFEbQIU0RSVEVDSDE=
  210. =MWyu
  211. -----END PGP PUBLIC KEY BLOCK-----
  212. [Blank Line]
  213. [Blank Line]
  214.  
  215.     Note: the Header starts with the line that begins with DISCLOSE:
  216.     and allows for any number of lines of random text before it, to be
  217.     ignored. It ends with two consecutive blank lines.
  218.  
  219.     Note: The SiteID sent by the server is the username of the PGP
  220.     public key. This can be used to more easily manipulate key
  221.     information in the client program.
  222.  
  223.     The client then sends a header consisting of the entity with whom
  224.     they intend to file, their filer ID, their filer password, their
  225.     Email address, and/or their Fax number, followed by the filing in
  226.     the serving entity's file format all encrypted with the PGP Public
  227.     Key that the server just sent in PGP ASCII format. The FilerID and
  228.     FilerPassword are assigned to them in advance (usually in writing)
  229.     via secure means, by the entity with whom they are filing.
  230.  
  231.  
  232.  
  233.  
  234.  
  235. Jim Dixon                                                       [Page 4]
  236.  
  237. INTERNET-DRAFT                                            INTERNET-DRAFT
  238. DISCLOSE Protocol
  239.  
  240.  
  241.     Note: One of FilerEmail or FilerFAX must be specified. Client is to
  242.     send whichever one (or both) that is to be used for notification of
  243.     the outcome of the filing. The Entity, FilerID and FilerPassword
  244.     must always be specified. SuperID is to be sent only when needed.
  245.  
  246.     The FilerEmail must be specified as only the E-mail address of the
  247.     person who wishes to receive confirmation of the transmission of
  248.     the filing. Do not include any other information (such as personal
  249.     name, etc.).
  250.  
  251.     The FilerFax must be specified as only the 10 digit telephone number
  252.     of the person who wishes to receive confirmation of the
  253.     transmission of the filing. Do not include any other information
  254.     (such as personal name, extension, mailbox, etc.).
  255.  
  256.     The SuperID is an optional field that is used to specify an existing
  257.     filing to be superceded by the filing that is about to be sent.
  258.  
  259.     Note: The client program must verify that the server serves the
  260.     entity with whom the filer wishes to file (by searching through the
  261.     header that the server sends). If it is not the correct server, the
  262.     client should close the connection, and report an error to the user.
  263.  
  264.     For example, the client might send (viewed after decryption by the
  265.     server):
  266.  
  267. Entity: SF
  268. FilerID: marie.smith
  269. FilerPassword: mysecret
  270. FilerEmail: marie@antoine.net
  271. FilerFAX: (415)555-1212
  272. SuperID: SF-1234
  273. [Blank Line]
  274. File contents..... etc......
  275. [Blank Line]
  276.  
  277.  
  278.     The server then responds with a status (and other information as
  279.     appropriate) followed by a blank line. The status line consists of
  280.     a one word response (see below) followed by other information, if
  281.     appropriate.
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288. Jim Dixon                                                       [Page 5]
  289.  
  290. INTERNET-DRAFT                                            INTERNET-DRAFT
  291. DISCLOSE Protocol
  292.  
  293.  
  294. Server responses are:
  295. BADDATA    (PGP data not accepted (like bad key or transmission error))
  296. TIMEOUT    (client did not send in time)
  297. BADFORMAT  (Successful decryption, but file format bad)
  298. ACCEPTED Filing_ID   [NOTE: Filing_ID is the unique ID of the Filing
  299.                       (generated by the server) that has been accepted
  300.                       by the server. It is used to reference the filing
  301.                       when response of its outcome is sent to the filer,
  302.                       and also to reference the submission (if any)
  303.                       done in writing by the filer.]
  304.  
  305.  
  306.     The connection is then closed by both parties.
  307.  
  308.     The client may also disconnect immediately after the client connects
  309.     and the server finishes sending its header information, since
  310.     encryption (in certain cases) may take a little while. In doing so,
  311.     a client would not have to waste time (and money) staying connected
  312.     to the server while the data is being encrypted, and then re-connect
  313.     (and, of course get the header information once again) to send the
  314.     data when it is finally finished encrypting.
  315.  
  316. Security and Data Integrity
  317.  
  318.     Since the transmission of the filing uses PGP technology, the
  319.     integrity and consistency of the data is automatically ensured to be
  320.     valid by virtue of the internal CRC/error checking of the PGP
  321.     encryption and ASCII-armor file conversions.
  322.  
  323.     Encryption is done by using the Public Key sent by the server to 
  324.     encrypt the data sent by the client. Thus, only the server will be
  325.     able to decrypt the transmitted data, ensuring privacy of any
  326.     sensitive data (such as telephone numbers, social security numbers,
  327.     etc.) which might be sent as part of the filing (obviously parts
  328.     that would never be displayed to the public, for entity internal
  329.     use only).
  330.  
  331.     Since the client sends a password (within the encrypted data) that
  332.     is privately and securely assigned to them (usually by paper mail),
  333.     and is known only to the filer and the entity to which they are
  334.     filing, their identity is positively verified to the serving entity.
  335.     Also, since the password is part of the encrypted data, persons who
  336.     might be monitoring the transmission will not be able to see the
  337.     password, unless they somehow manage to decrypt the whole filing,
  338.     which with PGP, seems highly unlikely.
  339.  
  340.  
  341. Jim Dixon                                                       [Page 6]
  342.  
  343. INTERNET-DRAFT                                            INTERNET-DRAFT
  344. DISCLOSE Protocol
  345.  
  346.  
  347. Typical Server Implementation
  348.  
  349.     Typical implementation of the server side is usually done on a good-
  350.     sized multi-user platform, capable of many high-speed database
  351.     transactions simultaneously, since this protocol usually is
  352.     accompanied by a public database lookup facility, such as an
  353.     HTTP/Web server, to give public access to the filed information.
  354.     This is, after all, the whole purpose of electronic filing, in
  355.     general. Several analog dial-up modem lines (and perhaps also an
  356.     ISDN, 56/64k V.120 suggested) should be provided for people who
  357.     wish to file, but either do not have access to use the Internet to
  358.     file, or do not wish to file via the Internet, for whatever reasons.
  359.  
  360.  
  361.  
  362. Author's Address
  363.  
  364. Jim Dixon
  365. SDR Technologies
  366. 5210 Lewis Rd., Suite 1
  367. Agoura Hills, CA 91301
  368. Tel: (818) 865-1310
  369. Fax: (818) 865-1315
  370. Email: jim@lambdatel.com
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390. Jim Dixon                                                       [Page 7]
  391. INTERNET-DRAFT                                            INTERNET-DRAFT
  392.  
  393.  
  394.