doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc1805.txt b/doc/rfc/rfc1805.txt
new file mode 100644
index 0000000..d64c108
--- /dev/null
+++ b/doc/rfc/rfc1805.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+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
+   verification takes place.
+
+   To distribute a file, a registered author computes a cryptographic
+   hash of the file, and sends it over an integrity protected channel to
+   T. T then creates an object containing the hash, the current time,
+   the name of the author, the name of the file, and some other
+   information, seals the object, and returns it to the author. The
+   author can then use the sealed object as a location-independent proof
+   of the integrity and timeliness of the file.
+
+   Any user who obtains the file and the sealed object, can compute the
+   cryptographic hash of the file, check the seal on the object, and
+   verify that the object has not changed.
+
+   The trusted third party must maintain a widely available, dated, and
+   signed, certificate revocation list (CRL). Users who access a file
+   with a certificate must check that the CRL is current and complete,
+   and that the certificate is not listed.
+
+Author registration
+
+   In the first phase, authors request to register with the trusted
+   third party, T. The author sends an ASCII message to T containing
+   keywords followed by values. Some of the fields are optional, and are
+   marked with a *. The values are represented with angle brackets < >.
+
+     AUTHOR-NAME= <first m. last>
+   * AUTHOR-ORGANIZATION= <Company, school, etc.>
+   * AUTHOR-EMAIL= <e-mail address>
+     AUTHOR-LOCATION= <city, state>
+   * AUTHOR-PHONE-1= <Home phone>
+   * AUTHOR-PHONE-2= <Work phone>
+     SIGNATURE-SYSTEM= <name of signature system>
+   * MISC-FIELD-n= <Any number of additional fields can be defined here>
+   * AUTHOR-PUBLIC-KEY=
+   * <public key of author>
+
+   Each of the fields contains the keyword and the value on the same
+   line, except for the public key. An ASCII version of the key is
+   pasted on the line after the AUTHOR-PUBLIC-KEY keyword.  The format
+
+
+
+Rubin                        Informational                      [Page 3]
+
+RFC 1805 Location-Independent Data/Software Integrity Protocol June 1995
+
+
+   of this ASCII key will depend on the signature system used.  The
+   public key field is optional. The user may include his own, or one
+   can be supplied by T during phase II.  T responds with a message that
+   the request was received, and that the user should wait for off-line
+   verification.  If a user receives this confirmation message, and he
+   did not request to register, he knows that somebody may be attempting
+   to register on his behalf.
+
+Author verification
+
+   The trusted third party, T, must verify the identity of the author
+   who sent the request message in phase I.  The rest of the information
+   in the request is also confirmed.  This process takes place off-line.
+   The method used is intentionally left open, but whatever technique is
+   used must be identified in phases III and V.
+
+   In the Betsi implementation, T uses the phone company infrastructure.
+   T calls directory assistance (1-xxx-555-1212) in the city of the
+   author and asks for the author's number. Then, that number is called,
+   and T asks the author to verify the information sent in the request.
+   In particular, T insures that the author has registered his correct
+   public key. Or, in some cases, T assigns a public key to the author.
+   As Betsi is only operational in the United States, other mechanisms
+   need to be in place for verifying identities of people
+   internationally. Hopefully, standards for doing this will arise. The
+   rest of the protocol is independent of whatever mechanism is used for
+   off-line identity and public key verification.
+
+File certification
+
+   Registered authors can obtain location-independent objects from the
+   trusted third party, T, that vouch for the integrity and time of any
+   file.
+
+   An author generates the following ASCII message and signs it with the
+   signature key that corresponds to the public key that was registered.
+
+     AUTHOR-NAME= <first m. last>
+     HASH-FUNCTION= <md5,sha, etc.>
+   * FILE-LOCATION= <ftp site/directory>
+     <list of hashes>
+
+   Each entry in the <list of hashes> consists of two mandatory fields
+   and one optional one, as follows:
+
+     <fixed-length hash of file> <name of file> <version number>
+
+
+
+
+
+Rubin                        Informational                      [Page 4]
+
+RFC 1805 Location-Independent Data/Software Integrity Protocol June 1995
+
+
+   The <fixed-length hash of file> is a fixed-length hexadecimal value
+   corresponding to the hash of the contents of the file.  For MD5, the
+   output is 32 hexadecimal digits. There is one space between the
+   fields, and the name of the file contains no spaces.  The <version
+   number> is optional.  The <list of hashes> contains at least one
+   entry, and may contain as many as the author wants.  The message is
+   signed and sent to the trusted third party, T.
+
+   When T receives the request for file certification, he verifies the
+   signature on the request and creates a location-independent
+   certificate for the request. The certificate is signed by T, and
+   contains the following information:
+
+     TRUSTED-PARTY= <identity of T>
+     AUTHOR-VERIFICATION-METHOD= <how authors are verified off-line>
+     AUTHOR-NAME= <first m. last>
+     AUTHOR-ORGANIZATION= <company, school, etc.>
+     HASH-FUNCTION= <md5,sha, etc.>
+     DATE= <date>
+     <list of hashes>
+
+   The <list of hashes> is the same as the one in the author's request.
+   T signs the message and sends it to the author, who verifies the
+   signature and the contents of the certificate.  Note that the method
+   for off-line author verification is included in the certificate.
+
+File distribution
+
+   In the file distribution phase, the author distributes his file,
+   along with the certificate from T. The file and certificate are
+   location-independent. That is,  the integrity and timeliness of the
+   file can be verified independently from the location of the file and
+   the certificate. This means that files can be distributed from
+   insecure sites, and over insecure networks.
+
+File integrity verification
+
+   The final phase is file integrity verification. A user obtains the
+   public key of the trusted third party, T, from several independent
+   sources, until he is convinced of its authenticity.  The user then
+   verifies the certificate for a file, and decides whether or not he
+   trusts the method of off-line verification that was used by T. If so,
+   then he extracts the name of the hash function in the certificate,
+   and performs the hash function on the actual file. Finally, the user
+   compares the hash of the file to the hash in the certificate. The
+   user also checks the date in the certificate if he is concerned with
+   this information.  As a last step, the user checks the highly
+   available certificate revocation list of T, to see if the current
+
+
+
+Rubin                        Informational                      [Page 5]
+
+RFC 1805 Location-Independent Data/Software Integrity Protocol June 1995
+
+
+   certificate is listed.  When all of this has concluded, if none of
+   the assumptions of the system has been violated, then the user is
+   assured of the integrity and timeliness of the file.
+
+References
+
+   [1] Rubin, A., "Trusted Distribution of Software over the Internet",
+       Internet Society Symposium on Network and Distributed System
+       Security," pp. 47-53, 1995.
+
+   [2] Lowrey, J., "Location-Independent Information Object Security",
+       Internet Society Symposium on Network and Distributed System
+       Security," pp. 54-62, 1995.
+
+   [3] Zimmerman, P., "PGP User's Guide", 1992.
+
+   [4] National Institute for Standards and Technology, Digital
+       Signature Standard (DSS), Federal Register 56(169), 1991.
+
+   [5] Schneier, B., "Applied Cryptography", ISBN 0-471-59756-2.
+
+   [6] Simmons, G., "The Subliminal Channels of the U.S.  Digital
+       Signature Algorithm (DSA)", Proceedings of the 3rd Symposium on:
+       State and Progress of research in Cryptography, pp. 35-54, 1993.
+
+Security Considerations
+
+   Security issues are discussed throughout this memo.
+
+Author's Address
+
+   Aviel D. Rubin
+   Bellcore
+   Morristown, NJ 07960
+   USA
+
+   Phone: +1 201 829 5922
+   Fax: +1 201 829 2645
+   EMail: rubin@bellcore.com
+
+
+
+
+
+
+
+
+
+
+
+
+Rubin                        Informational                      [Page 6]
+