We present an infrastructure which permits secure publication of material in a decentralized environment. The system is secure against unauthorized publication and could with minor modification employ encryption to provide confidentiality. The costs and structure of the proposal are presented.
This design note presents a draft design for a secure document publishing system. The particular application considered is the publication of announcements of government tenders. For the sake of simplicity we deal only with the actual tendering process and not the evaluation of tenders or assignment of contracts. The principal security concern is thus authenticity as opposed to privacy. Tenders are by their nature public documents, confidentially is therefore of limited concern. Authenticity is a very major concern however.
A dishonest bidder might attempt to win a contract by preventing the receipt of a tender announcement by a competitor or by modifying it in such a way as to cause the competitor to submit a higher bid or one which would be disqualified for failing to meet certain criteria. A dishonest bidder might also gain through having prior knowledge that a tender was to be issued. We do not address this concern directly in this note since it is assumed that the interval between preparation of a tender and its publication should be short compared to the time allowed for recipe of bids.
The publication system involves four parties, two of which are internal and two of which are external. the external parties are the agencies which prepares the request for tenders, the contractors who wish to make bids. The internal parties are an editor and a publisher.
The principle technological platforms used are secure email and the World-Wide Web. Secure email such as PGP [Zimmerman95], S/MIME [RSA] permits email to be cryptographically enhanced using a combination of digital signatures and/or encryption. Secure protocols for the World-Wide Web such as S-HTTP [Schiffman95] offer similar functionality.
The Whitehouse documents publication system provides a model and proof of concept for much of this design. In particular the combination of email and Web interfaces and the use of self organization.
The editor's function is to check tender requests for presentation and categorize them correctly.
Agencies communicate with the editor by a combination of email and a World-Wide Web forms interface depending upon convenience. In general it is likely to be more convenient to use email for the initial communication of an offer to the editor and the Web interface for review operations.
In order to reduce costs it is desirable to reduce to an absolute minimum the number of manual interventions required by the editor. This implies that much of the work of cataloging the tender requests must be performed by the agencies themselves. Care must be taken to avoid cutting costs at one agency simply by pushing them onto another. The interface to the editor should therefore be simple to use, whether by a newly hired clerk ordering a new paper clip supply or an engineer requesting tenders for specialist steel work.
In a typical configuration the agency clerk would prepare the tender using standard word processing package then submit it to the editor server via secure email. The editor server would then authenticate the digital signature of the message and check that it was authorized. The clerk would then relieve an email notification of receipt together with a hypertext link to a page where the entry procedure would be completed.
The clerk would then visit the link supplied and check that the text of the tender had been correctly rendered in HTML. The editor might suggest a suitable category itself based on an analysis of the text of the request, the agency submitting it and a record of similar requests previously submitted. The clerk would then decide on the actual category to use. This process might involve consulting an online hypertext categorization guide.
In some cases a different work flow might be used. The initial tender request might be prepared by a manager who would then leave the editing task to an administrative assistant. The use of email makes this simple to achieve. The manager might submit the request and then forward the editors reply to an assistant.
Once the editor interaction is complete the editor sends it to the publisher. This step is likely to involve traversing a firewall since the editor's function is an internal one while the publisher's role is largely external. This step may be achieved using any authenticated means of communication such as secure email or a secured Web transaction.
The publisher's interest lies in delivering timely and relevant material to the contractor while excluding irrelevant material. If a contractor is presented with a large volume of irrelevant material it is less likely that the relevant material will be identified and an offer made. It is also in the publisher's interest to take whatever steps are possible to reduce the contractor's costs since these will eventually be passed on in higher bids.
This interaction may involve booth the Web and email. Many corporate users find email the most convenient mechanism for accepting information. Email not only delivers information, it provides a notification service. This makes it possible to integrate email into work flow tools which ensure that each message is handled by someone.
Email is also more problematic than the Web. If a Web user does not obtain a page the user knows that there was some problem and can request the down load again. If an Email message is lost the recipient may not know that it did not arrive.
In one model of the Publisher-Contractor Interaction a Web site would provide free access to all information concerning tenders. This site would provide a search engine to assist users in discovering material of relevance to them.
The Web site would be supplemented by an email subscription service. A contractor could request that all tender requests satisfying a given set of criteria would be automatically delivered via email. This service might provide the text of each offer immediately on publication, or a daily or weekly digest. Digests might consist of the full text of each offer or brief summary data and a link to the full offer.
The email service would represent a "value added" service for which the contractor might be charged. It would be advantageous to make such charges low enough for contractor personnel to be able to subscribe on an individual basis, thus ensuring both a wider revenue base and also maximizing the possibility that the information will be dealt with by the most appropriate person.
A critical problem in the establishment of secure electronic communication lies in establishing the authenticity of cryptographic keys themselves used by the parties. It is of limited value to know that a document was signed using a particular digital key unless one also knows that the key is genuinely that of the party concerned.
The traditional approach to this problem is to use a chain of certificates such that a trusted certificate is used to verify an untrusted one [Solins]. The main difficulty in this approach lies in establishing large scale, broadband systems of trust. These difficulties have delayed the establishment of secure email.
For the example described the difficulty of administering the trust hierarchy is relatively small. The only party which needs to establish its identity is that making the offers for tender themselves. This means that each agency, the editor and the publisher would require a means of generating a digital signature but not the contractors. This condition would not hold were bidding to be incorporated into the system in which case the certificate infrastructure would also have to cover contractors.
The proposal outlined would require an "industrial strength" protocol implementation. In particular it would be desirable for all key components such as the Editor and Publisher servers to be implemented in a manner providing double or triple redundancy.