RFC1805 日本語訳

Network Working Group                                           A. Rubin
Request for Comments: 1805                                      Bellcore
Category: Informational                                        June 1995

コメントを求めるワーキンググループA.ルービンの要求をネットワークでつないでください: 1805年のBellcoreカテゴリ: 情報の1995年6月

         Location-Independent Data/Software Integrity Protocol

位置から独立しているデータ/ソフトウェア保全プロトコル

Status of this Memo

この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.

ファイルの保全について確かめるどんなシステムに関する1つの問題も検証プログラム自体が攻撃されるかもしれないということです。 したがって、ユーザが彼らのソフトウェアによってファイルが変化していないのが再保証されるかもしれませんが、ほんとうはファイル、および検証はともに変化したかもしれません。 この危険のために、何らかの特別なソフトウェアの分配、しかし、むしろ当てにされないプロトコルは、広く使用された規格に完全に基づいていて、非常に役に立ちます。 それで、ユーザは、それら自身のソフトウェアを組立てるか、または独自にチェックする保全をするために信じられたコピーのソフトウェアを入手します。 したがって、このメモで説明されたプロトコルは電子メールかいかなる他の手段も使用させられるかもしれないASCIIメッセージで構成されます。 既存の実装、このように設計されているBetsi[1]があります。 Betsiは1994年8月以来現存していて、インターネットで操作上です。 対象の'助け'、または http://info.bellcore.com/BETSI/betsi.html の世界的なウェブでメールを certify@bellcore.com に送ることによって、それにアクセスできます。

Rubin                        Informational                      [Page 1]

RFC 1805 Location-Independent Data/Software Integrity Protocol June 1995

[1ページ]RFC1805の位置から独立しているデータ/ソフトウェア保全プロトコル1995年6月の情報のルービン

   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

I. 登録IIを書いてください。 検証IIIを書いてください。 証明IVをファイルしてください。 ファイル分配V.ファイル保全検証

   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.

フェーズ私、III、IV、およびVはプロトコルで定義されます。 フェーズIIは故意に定義されません。 異なったアプリケーションにおいて、作者検証は異なる場合があります、そして、フェーズIIに選ばれた特定のメソッドはフェーズIIIで特定されます、そして、V.Itは一層のインターネットDraftsがフェーズIIのために様々な可能性について説明するという望みです。 このメモは、Betsiシステムにおける作者検証のためのメソッドを説明して、いくつかの推薦状をします。

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.

保全と時間情報がファイルの位置から独立しているのは、重要です。 ロウリー[2]は位置から独立しているオブジェクトのために構文とプロトコルを定義します。 彼のシステムは、エンドユーザには特別なソフトウェアがあるのが必要であり、まだプロトタイプ段階にあります。 このメモで説明されたプロトコルは、実装されて、インターネットの向こう側に既に広範囲に使用中です。 それは、簡単で、コンパクトで分かり易いです。 非常に複雑なシステムの難点はそれがどのように働くかを理解できないならユーザがデザイナーのクレームを信じる傾向がないかもしれないということです。

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.

プロトコルの3つの実体が、Authors(A)と、Users(U)と、Trusted第三者(T)です。 ここで説明されたプロトコルはアルゴリズム独立者です、そして、ASCIIにはメッセージのすべてがあります。 使用されるそれぞれの署名体系のために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.

デジタル署名の標準のASCII表現がある限り、どんな署名体系も使用されるかもしれません。 また、暗号化を必要とします、そして、PGP[3]は上記の要件のすべてに会いますが、輸出制限はその結果、何人かのユーザを思いとどまらせるかもしれません。 DSS[4]はお勧めですが、或るものは、いくつかの結果に基づいているシモンズ[6]の跳ね上げ戸[5]を含むと疑います。 また、DSSを使用することでASCII署名を生成する規格があるのも、明確ではありません。

Rubin                        Informational                      [Page 2]

RFC 1805 Location-Independent Data/Software Integrity Protocol June 1995

[2ページ]RFC1805の位置から独立しているデータ/ソフトウェア保全プロトコル1995年6月の情報のルービン

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.

プロトコルは以下の通り働いています。 作者は、信頼できる第三者機関とともに記名するようAny登録された作者が分配できるT.が保全と時間保証で第1段階でファイルされるよう要求します。 時間保証は、ファイルが一時に存在したという保証があることを意味します。 2番目のフェーズでは、Tはどうにか登録するよう要求する作者のアイデンティティについて確かめます。 この検証が行われるまで、登録は完全ではありません。

   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.

登録された作者は、ファイルを分配するために、ファイルの暗号のハッシュを計算して、T.への保全の保護されたチャンネルの上にそれを送ります。Tは、次に、ハッシュ、現在の時間、作者の名前、ファイルの名前、およびある他の情報を含むオブジェクトを作成して、オブジェクトの封をして、それを作者に返します。 そして、作者はファイルの保全とタイムリーさの位置独自の証拠として密封されたオブジェクトを使用できます。

   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.

信頼できる第三者機関は広く利用可能で、時代遅れの、そして、署名している証明書失効リスト(CRL)を維持しなければなりません。 証明書でファイルにアクセスするユーザはCRLが現在であって完全であり、証明書が記載されていないのをチェックしなければなりません。

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 < >.

作者は、信頼できる第三者機関とともに記名するようT. 作者が第1段階で値があとに続いたキーワードを含むTにASCIIメッセージを送るよう要求します。 分野のいくつかが、任意であり、*でマークされます。値は角ブラケット<>で表されます。

     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>

AUTHOR-NAMEは<社、最後の<最初m.の>*AUTHOR-ORGANIZATION=学校などと等しいです。>* <Eメールアドレス>AUTHOR-LOCATION=<AUTHOR-メール=都市、追加分野の署名システム>*MISC-FIELD-n=<Any番号の州の>*AUTHOR電話-1=<ホーム電話>*AUTHOR電話-2=<Work電話>SIGNATURE-SYSTEM=<名はここで定義されて、>*AUTHOR-PUBLIC-KEYが作者>の*<公開鍵と等しいということであるかもしれません。

   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

それぞれの分野は公開鍵以外の同じ系列にキーワードと値を含んでいます。 キーのASCII版はAUTHOR-PUBLIC-KEYキーワードの後の系列で貼られます。 形式

Rubin                        Informational                      [Page 3]

RFC 1805 Location-Independent Data/Software Integrity Protocol June 1995

[3ページ]RFC1805の位置から独立しているデータ/ソフトウェア保全プロトコル1995年6月の情報のルービン

   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.

このASCIIでは、キーは使用される署名システムによるでしょう。 公開鍵分野は任意です。 ユーザが彼自身のを入れるかもしれませんか、またはTは段階IIの間、1つを供給できます。 Tはユーザが要求を受け取って、オフライン検証を待つべきであるというメッセージで応じます。 ユーザがこの確認メッセージを受け取って、彼が、登録するために、だれかが、彼に代わって登録するのを試みているかもしれないのを知っているよう要求しなかったなら。

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.

信頼できる第三者機関(T)はフェーズI.で要求メッセージを送った作者のアイデンティティについて確かめなければなりません。また、要求における、情報の残りは確認されます。 このプロセスはオフラインで行われます。 使用されるメソッドは故意に開くままにされますが、フェーズIIIと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.

Betsi実装では、Tは電話会社のインフラストラクチャを使用します。 Tは、作者の都市にディレクトリ支援を(1-xxx-555-1212)と呼んで、作者の番号を求めます。 次に、その数は呼ばれます、そして、Tは要求で送られた情報について確かめるように作者に頼みます。 特に、Tは、作者が彼の正しい公開鍵を登録したのを保障します。 または、いくつかの場合、Tは公開鍵を作者に割り当てます。 Betsiが単に合衆国で操作上であるときに、他のメカニズムは、人々のアイデンティティについて国際的に確かめるために適所にある必要があります。 うまくいけば、これをする規格は起こるでしょう。 プロトコルの残りはオフラインアイデンティティと公開鍵検証に使用されるどんなメカニズムからも独立しています。

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.

登録された作者は信頼できる第三者機関、どんなファイルの保全と時間にも太鼓判を押すTから位置から独立しているオブジェクトを入手できます。

   An author generates the following ASCII message and signs it with the
   signature key that corresponds to the public key that was registered.

作者は、以下のASCIIメッセージを生成して、登録された公開鍵に対応する署名キーでそれに署名します。

     AUTHOR-NAME= <first m. last>
     HASH-FUNCTION= <md5,sha, etc.>
   * FILE-LOCATION= <ftp site/directory>
     <list of hashes>

最後の<最初m.の>AUTHOR-NAME=HASH-FUNCTIONは<md5、shaなどと等しいです。>* FILE-LOCATIONはハッシュ>の<FTPサイト/ディレクトリ><リストと等しいです。

   Each entry in the <list of hashes> consists of two mandatory fields
   and one optional one, as follows:

ハッシュ>の<リストにおける各エントリーは以下の通り2つの義務的な分野と1つ任意のものから成ります:

     <fixed-length hash of file> <name of file> <version number>

ファイル><バージョン番号>のファイル><名の<固定長ハッシュ

Rubin                        Informational                      [Page 4]

RFC 1805 Location-Independent Data/Software Integrity Protocol June 1995

[4ページ]RFC1805の位置から独立しているデータ/ソフトウェア保全プロトコル1995年6月の情報のルービン

   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.

ファイル>の<固定長ハッシュはファイルのコンテンツのハッシュに対応する固定長16進価値です。 MD5に関しては、出力は32の16進数字です。 分野の間には、1つのスペースがあります、そして、ファイルの名前は空間を全く含んでいません。 <バージョン番号>は任意です。 ハッシュ>の<リストは、少なくとも1つのエントリーを含んでいて、作者が欲しいのと同じくらい多くを含むかもしれません。 信頼できる第三者機関、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:

Tがファイル証明を求める要求を受け取るとき、彼は、要求のときに署名について確かめて、要求のために位置から独立している証明書を作成します。 証明書は、Tによって署名されて、以下の情報を含んでいます:

     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>

TRUSTED-パーティは最後の>AUTHOR-ORGANIZATION=<会社、<最初m.の作者が確かめられたオフライン>AUTHOR-NAMEであるT>AUTHOR-VERIFICATION-METHOD=<の<のアイデンティティ=学校などと等しいです。>ハッシュ関数は<md5、shaなどと等しいです。DATEが<日付の><リストと等しい>は>を論じ尽くします。

   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.

ハッシュ>の<リストは作者の要求におけるものと同じです。 Tは、作者にメッセージに署名して、それを送ります。(その作者は、証明書の署名とコンテンツについて確かめます)。 オフライン作者検証のためのメソッドが証明書に含まれていることに注意してください。

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.

ファイル振分けフェーズでは、作者は彼のファイルを分配して、T.からの証明書と共に、ファイルと証明書は位置から独立しています。 ファイルと証明書の位置からすなわち、ファイルの保全とタイムリーさであるのについて独自に確かめることができます。 これは、不安定なサイトと、そして、不安定なネットワークの上にファイルを分配できることを意味します。

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

最終段階はファイル保全検証です。 ユーザは信頼できる第三者機関の公開鍵を得ます、T、数人の個人記者からの情報から、彼は信憑性を確信するまで。 ユーザは、次に、ファイルのための証明書について確かめて、彼がT.Ifによって使用されたオフライン検証のメソッドを信じるか否かに関係なく、したがって、次に、証明書でハッシュ関数の名前を抜粋して、実際のファイルにハッシュ関数を実行すると決めます。 最終的に、ユーザはファイルのハッシュを証明書のハッシュにたとえます。 また、この情報に関係があるなら、ユーザは証明書の日付をチェックします。 最後のステップで、ユーザが電流であるなら見るためにTの非常に利用可能な証明書失効リストをチェックするので

Rubin                        Informational                      [Page 5]

RFC 1805 Location-Independent Data/Software Integrity Protocol June 1995

[5ページ]RFC1805の位置から独立しているデータ/ソフトウェア保全プロトコル1995年6月の情報のルービン

   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.

「[1] ルービン、A.、「インターネットの上のソフトウェアの信じられた分配」、NetworkとDistributed System Securityの上のインターネット協会Symposium」、ページ 47-53, 1995.

   [2] Lowrey, J., "Location-Independent Information Object Security",
       Internet Society Symposium on Network and Distributed System
       Security," pp. 54-62, 1995.

「[2] ロウリー、J.、「位置から独立している情報オブジェクトセキュリティ」、NetworkとDistributed System Securityの上のインターネット協会Symposium」、ページ 54-62, 1995.

   [3] Zimmerman, P., "PGP User's Guide", 1992.

[3] ジンマーマン、P.、「PGP使用手引書」、1992。

   [4] National Institute for Standards and Technology, Digital
       Signature Standard (DSS), Federal Register 56(169), 1991.

規格と技術の[4]の国家の研究所、デジタル署名基準(DSS)、官報56(169)、1991。

   [5] Schneier, B., "Applied Cryptography", ISBN 0-471-59756-2.

[5] シュナイアー、B.、「適用された暗号」、ISBN0-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.

[6] シモンズ、G.、「米国デジタル署名アルゴリズム(DSA)の識閾下のチャンネル」、以下の第3SymposiumのProceedings Cryptography、ページにおける研究の状態とProgress 35-54, 1993.

Security Considerations

セキュリティ問題

   Security issues are discussed throughout this memo.

このメモ中で安全保障問題について議論します。

Author's Address

作者のアドレス

   Aviel D. Rubin
   Bellcore
   Morristown, NJ 07960
   USA

Aviel D.ルービン・Bellcoreニュージャージー07960モリスタウン(米国)

   Phone: +1 201 829 5922
   Fax: +1 201 829 2645
   EMail: rubin@bellcore.com

以下に電話をしてください。 +1 201 829、5922Fax: +1 2645年の201 829メール: rubin@bellcore.com

Rubin                        Informational                      [Page 6]

ルービンInformationalです。[6ページ]