Location-Independent Data/Software Integrity Protocol
RFC 1805

Document Type RFC - Informational (June 1995; No errata)
Was draft-rubin-lid-sip (individual)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1805 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           A. Rubin
Request for Comments: 1805                                      Bellcore
Category: Informational                                        June 1995

         Location-Independent Data/Software Integrity Protocol

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This memo describes a protocol for adding integrity assurance to
   files that are distributed across the Internet.  This protocol is
   intended for the distribution of software, data, documents, and any
   other file that is subject to malicious modification.  The protocol
   described here is intended to provide assurances of integrity and
   time.  A trusted third party is required.

Introduction

   One problem with any system for verifying the integrity of a file is
   that the verifying program itself may be attacked. Thus, although
   users may be reassured by their software that a file has not changed,
   in reality, the file, and the verifier might have both changed.
   Because of this danger, a protocol that does not rely on the
   distribution of some special software, but rather, is based entirely
   on widely used standards, is very useful. It allows users to build
   their own software, or obtain trusted copies of software to do
   integrity checking independently. Therefore, the protocol described
   in this memo is composed of ASCII messages that may be sent using e-
   mail or any other means. There is an existing implementation, Betsi
   [1], that is designed this way. Betsi has been in existence since
   August, 1994, and is operational on the Internet. It can be accessed
   by sending e-mail to certify@bellcore.com with subject 'help', or via
   the world wide web at http://info.bellcore.com/BETSI/betsi.html.

Rubin                        Informational                      [Page 1]
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                      [Page 2]
RFC 1805 Location-Independent Data/Software Integrity Protocol June 1995

High level view

   The protocol works as follows. In the first phase, authors request to
   register with the trusted third party, T.  Any registered author can
   distribute files with integrity and time assurance. Time assurance
   means that there is a guarantee that a file existed at a given time.
   In the second phase, T somehow verifies the identity of an author who
   requests to register.  Registration is not complete until this
Show full document text