One document matched: draft-rfced-info-dixon-01.txt
Differences from draft-rfced-info-dixon-00.txt
INTERNET-DRAFT INTERNET-DRAFT
Network Working Group Jim Dixon (SDR Technologies, Inc.)
INTERNET-DRAFT January 1997
Category: Informational
Expire in six months
Political Disclosure Transmission Protocol (DISCLOSE)
<draft-rfced-info-dixon-01.txt>
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 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 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 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 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. SuperID is to be sent only when needed.
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.).
The SuperID is an optional field that is used to specify an existing
filing to be superceded by the filing that is about to be sent.
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
SuperID: SF-1234
[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 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 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@lambdatel.com
Jim Dixon [Page 7]
INTERNET-DRAFT INTERNET-DRAFT
| PAFTECH AB 2003-2026 | 2026-04-23 15:43:07 |