[671] in cryptography@c2.net mail archive
Request for Information
daemon@ATHENA.MIT.EDU (Robert Hettinga)
Thu May 1 22:35:46 1997
Date: Thu, 1 May 1997 22:16:55 -0400
To: cryptography@c2.net
From: Robert Hettinga <rah@shipwright.com>
--- begin forwarded text
X-Sender: danielg@tiac.net
Mime-Version: 1.0
Date: Thu, 01 May 1997 19:53:07 -0400
To: rah@shipwright.com
From: Daniel Greenwood <dan@civics.com>
Subject: Request for Information
Would you please help spread this Request for Information by posting it to
the DCBS list? Thanks!
====================================================
Since many of the participants on this list are interested in secure online
transactions, I would like to share the below Request for Information
issued by the Commonwealth of Massachusetts. The Commonwealth is seeking
informaiton from vendors and others to assist us in drafting future
procurements. I would encourage anyone on this list to reply or to pass
this document widely for others to reply. Thank you.
Best,
Dan
=========================
Request for Information
Secure On-Line Transactions
Thursday, April 24, 1997
The Commonwealth of Massachusetts, acting through the on-line Government
Task Force, is contemplating the release of one or more procurements for
electronic commerce products and/or services. This Request for Information
(RFI) is intended to solicit information that could be useful in drafting
subsequent RFRs. This RFI specifically seeks information on products and/or
services that will enable the Commonwealth of Massachusetts to use the
Internet and internal networks for secure messaging and transactions.
Section 1: Background
The Chief Information Officer for the Commonwealth of Massachusetts has
convened the On-Line Government Task Force to chart the immediate future
course of on-line government in Massachusetts. The Task Force consists of
representatives from a number of different agencies, departments and
offices of the Commonwealth. The Task Force is investigating solutions that
improve efficiency and service quality using internal and Internet-based
electronic communications that possess authentication (to achieve access
control as well as non-repudiation), integrity, and confidentiality.
The Commonwealth has made information technology (IT) development and
electronic communications a priority, spending approximately $350 million
on IT annually. The Commonwealth seeks to make a large number of routine
business transactions available over the Internet and internal networks,
with the intent that they will be performed for less cost and conducted at
a higher quality service level for citizens, regulated entities, vendors
and others. The Commonwealth seeks to create methods for secure access to a
number of business transactions via electronic media, including licensing,
permitting, applications, filings, procurement and a host of other
functions. Internally, the Intranet is being looked at as a potential
mechanism to alleviate the crush of paper associated with a large number of
routine state government functions, including personnel, procurement
drafting, and other collaborative data sharing, work flow or messaging
applications.
Today, the Registry of Motor Vehicles (RMV) processes a number of
transactions and accepts credit card payment over the state web site. The
RMV transactions assure the confidentiality of credit card data over the
Internet by use of public key cryptography implemented with the SSL 2
protocol. The Division of Banks (DOB) has embarked on a pilot project to
receive authenticated on-line filings by banks over the state web site. The
DOB pilot assures the data is confidential and the identity of the filing
bank and individual filer is authenticated by use of public key
cryptography implemented with the SSL 3 protocol. The banks participating
in the DOB pilot are issued standard X.509v3 digital certificates
associated with the bank public key.
While the Task Force is interested in all relevant replies to this request
for information, responses that propose cost effective and currently
available methods to assure non-repudiation are of particular interest.
Non-repudiation means a method to prevent or sufficiently rebut subsequent
denial of transmittal or receipt of a given message or participation in a
given transaction. In some cases, this non-repudiation must be capable of
tying an individual to a particular piece or set of data at a particular
time. For non-repudiation, mere access control based on an SSL 3
implementation of public key cryptography and digital certificates will not
suffice, unless some additional technique exists to bind the identity of a
given party to the message or transaction engaged in by that party.
Section 2: Purpose of RFI
The Task Force seeks responses from vendors which offer information about
currently- available solutions to any or all of the following business
needs and example applications:
2.1 Internet access with Authentication.
Such an application would involve access via the Internet to Commonwealth
data located behind the firewall.
Example:
Certain companies, for a legitimate business purpose, need to know the
driving records of certain employees. A solution is needed that will allow
a pre-selected group of companies to access employee driver histories and
determine driver status from a state database. Access control is required
to allow companies to access only the driving records of their employees.
General Considerations:
Authentication, in the example above, is being utilized to assure access
control to defined data on the network. Assuming the data is being viewed
with a web browser, then some provision may also be required to assure the
data remains confidential and has not been altered while in transit over
the Internet.
2.2 Internet-based data submission with non-persistent connection.
Such an application would involve access via the Internet to a Commonwealth
database behind the firewall for the purpose of submitting information.
Example 1:
For the purpose of posting requests for response as part of a procurement,
certain users would be allowed access to a state procurement services
database, provided authentication and non-repudiation is available for each
submission.
Example 2:
For the purpose of applying for a professional or commercial license
renewal, certain users would be allowed access to a state license database,
where the application form would be electronically delivered. As in the
previous example, non-repudiation is required to prevent the applicant from
denying information submitted in the application and to provide proof that
the state received a particular application.
General Considerations:
The posting of bids in response to a procurement and the submission of a
license application raise a number of issues that are unique to those
processes. The Commonwealth will be performing a number of other
transactions as well, including grant applications, on-line permitting and
various filings with state agencies. The Commonwealth will pursue some
transactions under this category (Internet-based data submission with
non-persistent connection) that will not require non-repudiation. Some of
these transactions would require only front-end authentication for access
control, other transactions would not require authentication of the
identity of the person submitting data for either access control or
non-repudiation. However, the Task Force is particularly interested in
information relating to non-repudiation.
2.3 Internet-based data exchange with persistent connection.
Such an application would involve access via the Internet to an on-line
application located behind the firewall such that the user would be
authenticated once, and the system would maintain the identity of the user
in all portions of the application throughout the duration of the session.
Example:
For the purpose of negotiating and crafting contract agreements, both state
users and non-governmental users would be allowed access to a common
document management and electronic workflow application, with all users
considered "members" of the workflow and able to perform tasks in the
workflow. The application front-end allows users to submit documents, edit
documents and query databases behind the firewall.
Section 3: Environment
The following diagram describes the Commonwealth's current and near-term
computing and communications environment. See Attachment 1.
Section 4: Other Considerations
Interested vendors may provide information regarding products, services
and/or integrated solutions that address either some or all of the
above-mentioned business needs. The purpose of this RFI is to provide the
Commonwealth with information that could be useful in developing one or
more RFRs for secure on-line transactions and messaging. Please feel free
to respond to any specific questions in this RFI or to offer any other
information that you feel could be useful to the Commonwealth in making
decisions about an RFR. In addition to the questions raised in the previous
sections, the Commonwealth is interested in information on the following.
4.1 Identify and describe all software or hardware required on a
client workstation for the proposed product/service/solution.
4.2 Identify and describe any back-end software or hardware required
of the proposed product/service/solution.
4.3 Describe how your product/service/solution scales to the
enterprise.
4.4 What are the short, mid and long term electronic records archival
ramifications of the proposed product/service/solution, including
suitability for audit and admissibility in evidence in a court?
4.5 How is the product/service/solution compliant with the provisions
of the Americans with Disabilities Act?
4.6 How is the product/service/solution Year 2000 compliant?
4.7 What, if any, privacy concerns are raised by the authentication
techniques proposed and how are those concerns addressed?
4.8 Does the proposed product/service/solution offer any on-line
payment capabilities? Please describe.
4.9 Describe any current implementations of your
product/service/solution and note any business partners involved with that
implementation.
4.10 Provide information about your company and its history.
4.11 Provide cost information about the proposed
product/service/solution.
Section 5: Procedural Information
This RFI is not an offer or solicitation and does not obligate or bind the
Commonwealth to procure any goods or services as a consequence. Responses
to this RFI do not constitute bids or proposals and are not legally binding
on the responding party. Respondents may not charge ITD or the Commonwealth
of Massachusetts for any costs associated with the preparation of responses
to this RFI. This RFI is being released on Commonwealth's Procurement
Access and Solicitation System (Comm-PASS). A copy of this RFI is also
available at ITD's legal department web site at
<http://www.state.ma.us/itd/legal>.
The schedule of events for this RFI, subject to amendment, is:
Thursday, April 24, 1997 RFI released on Comm-PASS
Friday, May 2, 1997 Informational session
Monday, May 12, 1997 Responses due
The informational session will be held at One Ashburton Place, Room 801,
Boston, MA 02108 from 10:00 am to 11:00 am. Please inform the chairman of
the procurement management team (preferably by e-mail) if you will attend
the session so that adequate seating can be made available. Organizations
or individuals responding to this RFI should submit ten copies of their
response in writing, accompanied by any attachments, exhibits or software,
to the chairman of the procurement management team by 5:00 pm on Monday,
May 12, 1997. Responses must also be submitted via e-mail or on floppy disk
in Word for Windows, WordPerfect format, or as a Text-Only document. The
chairman of the procurement management team is:
Dan Greenwood, Deputy General Counsel, Information Technology Division
On-Line Government Task Force, Team Leader
One Ashburton Place, Room 801
Boston, MA 02108
617.973.0071
dgreenwood@state.ma.us
--- end forwarded text
-----------------
Robert Hettinga (rah@shipwright.com), Philodox
e$, 44 Farquhar Street, Boston, MA 02131 USA
Lesley Stahl: "You mean *anyone* can set up a web site and compete
with the New York Times?"
Andrew Kantor: "Yes." Stahl: "Isn't that dangerous?"
The e$ Home Page: http://www.shipwright.com/
