RFC 1805 (rfc1805) - Page 2 of 6

Location-Independent Data/Software Integrity Protocol

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