HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 11:06:15 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 02 Sep 1996 22:20:00 GMT ETag: "36209a-3811-322b5d90" Accept-Ranges: bytes Content-Length: 14353 Connection: close Content-Type: text/plain INTERNET-DRAFT Expires February 1997 INTERNET-DRAFT Network Working Group Jim Dixon (SDR Technologies, Inc.) INTERNET-DRAFT August 1996 Category: Informational Political Disclosure Transmission Protocol (DISCLOSE) Status of this Document 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract This document details a protocol which allows political candidates and related committees to electronically transfer financial disclosure filings (as now often required by law) to their associated governmental entities, for the purpose of review, and then making these filings easily publicly accessible. History and Overview Political candidates, parties, committees and such have been required to file financial disclosure information (such as contribution, and expenditure data) related to their campaign, and sometimes even while in office, to their associated governmental entities for a number of years. Recently, some governments have started requiring these filings to be submitted electronically, so that the data can be easily processed, and made available publicly (e.g. via the Internet) in an expedient manner. Until now, these electronic submissions have been made via floppy disk (in various formats) and have been nearly impossible to manage. This document details a protocol whereby a filer of such disclosure information is able to transmit their filing electronically, either via the Internet, or via other means (such as dial-up lines) in a secure and accountable manner. Implementation of this protocol, both for the roles of client and server, should be fairly simple, and apply to many different hardware and software platforms equally well. This will allow for many different vendors' products to easily communicate with each other within this realm, thus allowing both the filers and governments to have a wide variety of options from which to choose when deciding how to implement the use of this protocol. Jim Dixon [Page 1] INTERNET-DRAFT Expires February 1997 INTERNET-DRAFT DISCLOSE Protocol The DISCLOSE specification Overview The DISCLOSE server specified by this document uses a stream connection (such as TCP or direct modem) and text-based commands and responses. It is designed to accept connections from hosts, and to provide a simple and secure method of transferring disclosure filings. This server is only an interface between client programs and the entity to which they are filing. It does not perform any user interaction or presentation-level functions. These "user-friendly" functions are better left to the client programs, which have a better understanding of the environment in which they are operating. When used via Internet TCP, the port assigned for this service is 667. The protocol is designed to work in the same manner, regardless of the transmission media (whether it is via TCP or direct modem, etc.). If used via direct modem, it is highly recommended that an error- correction protocol be used within the modem, such as MNP5. Character Codes Commands and replies are composed of characters from the ASCII character set. When the transport service provides an 8-bit byte (octet) transmission channel, each 7-bit character is transmitted right justified in an octet with the high order bit cleared to zero. Line formatting All data sent to and received from the server is contained in lines of ASCII text terminated by the ASCII carriage return character (0d hex) and the ASCII linefeed character (0a hex). In this specification, [Blank Line] refers to line containing no text, terminated by carriage return/linefeed (the characters 0d/0a by themselves). Jim Dixon [Page 2] INTERNET-DRAFT Expires February 1997 INTERNET-DRAFT DISCLOSE Protocol Transmission formatting Server to Client When the client connects to the server, the server transmits a header, consisting of some (random) sign-on text, server identity and entity identity information. It then waits (a maximum of 600 seconds) for a response from the client. After the response has been received (or a time-out occurs) the server responds with a single line response code (see below), and closes the connection. If the server receives a pre-mature closure of the connection from the client, it aborts the operation. Client to Server The client connects to the server, and then waits for the server to send its header. If the server has not finished sending the header within 600 seconds, the client should abort the operation and close the connection. The client then sends a PGP-ASCII-armor file (with the line endings of the physical file either ASCII linefeed (0a hex) alone or carriage return/linefeed (0d/0a hex)), consisting of a header (see below) and the filing in the governmental entity's file format. This file format varies from entity to entity, and therefore cannot be documented here. The client then waits for the server to give a one-line response. If this response is not received within 600 seconds of the end of the transmission of the PGP-ASCII-armor file, the client should abort the operation and close the connection. Client/Server Interaction When the client first connects to the server, the server sends out an optional welcome message (of random size and content, as long as it does not contain the word DISCLOSE: at the beginning of the line) and a header, consisting of the Site ID of the server, and the Entity ID(s), and other information about the entity(s) for which it is providing service, and its PGP Public Key information in the following example format: Jim Dixon [Page 3] INTERNET-DRAFT Expires February 1997 INTERNET-DRAFT DISCLOSE Protocol [Connection open] SDR Technologies DISCLOSE server version 1.1 7/27/96 Brought to you by SDR Technologies, Inc. Agoura Hills, CA For more information on this system, call (818) 865-1310 Serving State of Hawaii, State of Washington, City/County of San Francisco Access to this system is limited to authorized persons only. Unauthorized access is subject to criminal prosecution. DISCLOSE: SDRTECH1 Entity: HI State of Hawaii Entity: SF City/County of San Francisco Entity: WA State of Washington [Blank Line] -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 ([Blank Line] - Part of PGP public key block) mQBtAzHkANQAAAEDAMqT9WNBT6d8eDbzqtL3WKXrKPaZGwNSoRfkDmMA/ze2aDye be+giWklnzj4h9QfD/b8Rdm+mpdBcBb29gRR8gMxUX/gxzYc0WDT26WXKbs3IIsc pDfB7+CtgySy+uYYjQAFEbQIU0RSVEVDSDE= =MWyu -----END PGP PUBLIC KEY BLOCK----- [Blank Line] [Blank Line] Note: the Header starts with the line that begins with DISCLOSE: and allows for any number of lines of random text before it, to be ignored. It ends with two consecutive blank lines. Note: The SiteID sent by the server is the username of the PGP public key. This can be used to more easily manipulate key information in the client program. The client then sends a header consisting of the entity with whom they intend to file, their filer ID, their filer password, their Email address, and/or their Fax number, followed by the filing in the serving entity's file format all encrypted with the PGP Public Key that the server just sent in PGP ASCII format. The FilerID and FilerPassword are assigned to them in advance (usually in writing) via secure means, by the entity with whom they are filing. Jim Dixon [Page 4] INTERNET-DRAFT Expires February 1997 INTERNET-DRAFT DISCLOSE Protocol Note: One of FilerEmail or FilerFAX must be specified. Client is to send whichever one (or both) that is to be used for notification of the outcome of the filing. The Entity, FilerID and FilerPassword must always be specified. The FilerEmail must be specified as only the E-mail address of the person who wishes to receive confirmation of the transmission of the filing. Do not include any other information (such as personal name, etc.). The FilerFax must be specified as only the 10 digit telephone number of the person who wishes to receive confirmation of the transmission of the filing. Do not include any other information (such as personal name, extension, mailbox, etc.). Note: The client program must verify that the server serves the entity with whom the filer wishes to file (by searching through the header that the server sends). If it is not the correct server, the client should close the connection, and report an error to the user. For example, the client might send (viewed after decryption by the server): Entity: SF FilerID: marie.smith FilerPassword: mysecret FilerEmail: marie@antoine.net FilerFAX: (415)555-1212 [Blank Line] File contents..... etc...... [Blank Line] The server then responds with a status (and other information as appropriate) followed by a blank line. The status line consists of a one word response (see below) followed by other information, if appropriate. Jim Dixon [Page 5] INTERNET-DRAFT Expires February 1997 INTERNET-DRAFT DISCLOSE Protocol Server responses are: BADDATA (PGP data not accepted (like bad key or transmission error)) TIMEOUT (client did not send in time) BADFORMAT (Successful decryption, but file format bad) ACCEPTED Filing_ID [NOTE: Filing_ID is the unique ID of the Filing (generated by the server) that has been accepted by the server. It is used to reference the filing when response of its outcome is sent to the filer, and also to reference the submission (if any) done in writing by the filer.] The connection is then closed by both parties. The client may also disconnect immediately after the client connects and the server finishes sending its header information, since encryption (in certain cases) may take a little while. In doing so, a client would not have to waste time (and money) staying connected to the server while the data is being encrypted, and then re-connect (and, of course get the header information once again) to send the data when it is finally finished encrypting. Security and Data Integrity Since the transmission of the filing uses PGP technology, the integrity and consistency of the data is automatically ensured to be valid by virtue of the internal CRC/error checking of the PGP encryption and ASCII-armor file conversions. Encryption is done by using the Public Key sent by the server to encrypt the data sent by the client. Thus, only the server will be able to decrypt the transmitted data, ensuring privacy of any sensitive data (such as telephone numbers, social security numbers, etc.) which might be sent as part of the filing (obviously parts that would never be displayed to the public, for entity internal use only). Since the client sends a password (within the encrypted data) that is privately and securely assigned to them (usually by paper mail), and is known only to the filer and the entity to which they are filing, their identity is positively verified to the serving entity. Also, since the password is part of the encrypted data, persons who might be monitoring the transmission will not be able to see the password, unless they somehow manage to decrypt the whole filing, which with PGP, seems highly unlikely. Jim Dixon [Page 6] INTERNET-DRAFT Expires February 1997 INTERNET-DRAFT DISCLOSE Protocol Typical Server Implementation Typical implementation of the server side is usually done on a good- sized multi-user platform, capable of many high-speed database transactions simultaneously, since this protocol usually is accompanied by a public database lookup facility, such as an HTTP/Web server, to give public access to the filed information. This is, after all, the whole purpose of electronic filing, in general. Several analog dial-up modem lines (and perhaps also an ISDN, 56/64k V.120 suggested) should be provided for people who wish to file, but either do not have access to use the Internet to file, or do not wish to file via the Internet, for whatever reasons. Author's Address Jim Dixon SDR Technologies 5210 Lewis Rd., Suite 1 Agoura Hills, CA 91301 Tel: (818) 865-1310 Fax: (818) 865-1315 Email: jim@lambda.com Jim Dixon [Page 7] INTERNET-DRAFT Expires February 1997 INTERNET-DRAFT