RFC 1805 (rfc1805) - Page 2 of 6
Location-Independent Data/Software Integrity Protocol
Alternative Format: Original Text Document
RFC 1805 Location-Independent Data/Software Integrity Protocol June 1995 The purpose of the proposed protocol is for authors to be able to distribute their files to users on the internet with guarantees of time and integrity, by use of a trusted third party. The protocol is divided into several phases: I. Author registration II. Author verification III. File Certification IV. File Distribution V. File Integrity Verification Phases I, III, IV, and V are defined in the protocol. Phase II is intentionally not defined. Author verification can be different for different applications, and the particular method chosen for phase II is identified in phases III and V. It is the hope that further Internet Drafts will describe the various possibilities for phase II. This memo describes the method for author verification in the Betsi system, and makes several recommendations. Requirements It is important that the integrity and time information be independent from the location of the file. Lowry [2] defines a syntax and protocols for location-independent objects. His system requires that end-users possess special software, and is still in the prototype stage. The protocol described in this memo has been implemented, and is already in wide-spread use across the Internet. It is simple, compact and easy to understand. The disadvantage of a very complex system is that users may not be inclined to trust the designers' claims if they cannot understand how it works. Assumptions The three entities in the protocol are Authors (A), Users (U), and a Trusted third party (T). The protocol described here is algorithm independent, and all of the messages are in ASCII. It is assumed that for each signature scheme used, there is a well-known verification key associated with T. Any signature scheme may be used, as long as there is a standard ASCII representation of a digital signature. PGP [3] meets all of the above requirements, but it also requires encryption, and thus, export restrictions may deter some users. The DSS [4] is recommended, but some suspect that it contains a trapdoor [5] based on some results by Simmons [6]. It is also not clear that there is a standard for generating an ASCII signature using the DSS. Rubin Informational
