RFC1864 日本語訳

1864 The Content-MD5 Header Field. J. Myers, M. Rose. October 1995. (Format: TXT=7216 bytes) (Obsoletes RFC1544) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                           J. Myers
Request For Comments: 1864                               Carnegie Mellon
Obsoletes: 1544                                                  M. Rose
                                            Dover Beach Consulting, Inc.
                                                            October 1995

コメントを求めるワーキンググループJ.マイアーズの要求をネットワークでつないでください: 1864 カーネギー・メロンは以下を時代遅れにします。 Inc.1995年10月に相談する1544M.バラドーヴァービーチ

                      The Content-MD5 Header Field

内容-MD5ヘッダーフィールド

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   This memo specifies an optional header field, Content-MD5, for use
   with MIME-conformant messages.

このメモはMIME-conformantメッセージで任意のヘッダーフィールド、Content-MD5を使用に指定します。

Table of Contents

目次

   1. Introduction ..............................................    1
   2. Generation of the Content-MD5 Field .......................    2
   3. Processing the Content-MD5 field ..........................    3
   4. Security Considerations ...................................    3
   5. Acknowledgements ..........................................    3
   6. References ................................................    3
   7. Authors' Addresses ........................................    4

1. 序論… 1 2. 内容-MD5分野世代… 2 3. Content-MD5分野を処理します… 3 4. セキュリティ問題… 3 5. 承認… 3 6. 参照… 3 7. 作者のアドレス… 4

1. Introduction

1. 序論

   Despite all of the mechanisms provided by MIME [1] which attempt to
   protect data from being damaged in the course of email transport, it
   is still desirable to have a mechanism for verifying that the data,
   once decoded, are intact.  For this reason, this memo defines the use
   of an optional header field, Content-MD5, which may be used as a
   message integrity check (MIC), to verify that the decoded data are
   the same data that were initially sent.  The Content-MD5 header may
   also be placed in the encapsulated headers of an object of type
   message/external-body, to be used to verify that the retreived and
   decoded data are the same data that were initially referenced.

メール輸送の間に破損するのからデータを保護するのを試みるMIME[1]で提供されたメカニズムのすべてにもかかわらず、一度解読されたデータが完全であることを確かめるためのメカニズムを持っているのはまだ望ましいです。 この理由で、このメモは、解読されたデータが初めは送られたのと同じデータであることを確かめるために、任意のヘッダーフィールドの使用、Content-MD5を定義します。(Content-MD5はメッセージの保全チェック(MIC)として使用されるかもしれません)。 また、Content-MD5ヘッダーは、retreivedされて解読されたデータが初めは参照をつけられたのと同じデータであることを確かめるのに使用されるためにタイプのオブジェクトのカプセル化されたヘッダーに外部のメッセージ/ボディーで置かれるかもしれません。

   MD5 is an algorithm for computing a 128 bit "digest" of arbitrary-
   length data, with a high degree of confidence that any alterations in
   the data will be reflected in alterations in the digest.  The MD5

MD5は任意の長さのデータの128ビット「ダイジェスト」を計算するためのアルゴリズムです、データにおけるどんな変更もダイジェストにおける変更に反映されるという高度合いの自信をもって。 MD5

Myers & Rose                Standards Track                     [Page 1]

RFC 1864                Content-MD5 Header Field            October 1995

ヘッダーフィールド1995年10月の満足しているMD5のマイアーズとバラ標準化過程[1ページ]RFC1864

   algorithm itself is defined in [2]. This memo specifies how the
   algorithm may be used as an integrity check for MIME mail.

アルゴリズム自体は[2]で定義されます。 このメモはアルゴリズムがMIMEメールに保全チェックとしてどう使用されるかもしれないかを指定します。

2. Generation of the Content-MD5 Field

2. 内容-MD5分野世代

   The Content-MD5 field is generated by only an originating user agent.
   Message relays and gateways are expressly forbidden from generating a
   Content-MD5 field.

Content-MD5分野は起因しているユーザエージェントだけによって生成されます。 メッセージリレーとゲートウェイは、Content-MD5分野を生成するので、明白に禁じられます。

   Use of the Content-MD5 field is completely optional, but its use is
   recommended whenever data integrity is desired, but Privacy-Enhanced
   Mail services [3] are not available.  (Consult Section 4 for further
   details.) The Content-MD5 field may only be added to MIME entities of
   a `leaf' nature, i.e., the Content-MD5 field may be used with any
   content type other than multipart or message/rfc822.

Content-MD5分野の使用は完全に任意ですが、データ保全が望まれているときはいつも、使用はお勧めですが、Privacyによって高められたメールサービス[3]は利用可能ではありません。 (さらに詳しい明細についてはセクション4に相談してください。) Content-MD5分野は'葉'自然のMIME実体に加えられるだけであるかもしれません、すなわち、Content-MD5分野は複合を除いたcontent typeかいずれのもメッセージ/rfc822と共に使用されるかもしれません。

   To generate the value of the Content-MD5 field, the MD5 algorithm is
   computed on the canonical form of the MIME entity's object.  In
   particular, this means that the sender applies the MD5 algorithm on
   the data immediately after conversion to canonical form, before
   applying any content-transfer-encoding, and that the receiver also
   applies the MD5 algorithm on the canonical form, after undoing any
   content-transfer-encoding.  For textual data, this means the MD5
   algorithm must be computed on data in which the canonical form for
   newlines applies, that is, in which each newline is represented by a
   CR-LF pair.  The canonical encoding model of MIME is described in
   Appendix G of [1].

Content-MD5分野の値を生成するために、MD5アルゴリズムはMIME実体のオブジェクトの標準形の上で計算されます。 特に、これは、どんな満足している転送コード化も適用する前に正準への変換が形成される直後送付者がMD5アルゴリズムをデータに適用して、また、受信機がMD5アルゴリズムを標準形に適用することを意味します、どんな満足している転送コード化も元に戻した後に。 原文のデータに関しては、これは、ニューラインのための標準形が適用されるデータでMD5アルゴリズムを計算しなければならないことを意味します、すなわち、各ニューラインがどれであるかに、CR-LF組が表していました。 MIMEのモデルをコード化する正準は[1]のAppendix Gで説明されます。

   The output of the MD5 algorithm is a 128 bit digest.  When viewed in
   network byte order (big-endian order), this yields a sequence of 16
   octets of binary data.  These 16 octets are then encoded according to
   the base64 algorithm in order to obtain the value that is placed in
   the Content-MD5 field.  Thus, if the application of the MD5 algorithm
   over the raw data of a MIME entity results in a digest having the
   (unlikely) value of "Check Integrity!", then that MIME entity's
   header could contain the field

MD5アルゴリズムの出力は128ビットのダイジェストです。 ネットワークバイトオーダー(ビッグエンディアンオーダー)で見られると、これはバイナリ・データの16の八重奏の系列をもたらします。 そして、base64アルゴリズムによると、これらの16の八重奏が、Content-MD5分野に置かれる値を得るためにコード化されます。 したがって、MIME実体に関する生データの上のMD5アルゴリズムの適用が「保全をチェックしてください!」の(ありそうもない)の値を持っているダイジェストをもたらすなら、そのMIME実体のヘッダーは分野を含むかもしれません。

        Content-MD5:  Q2hlY2sgSW50ZWdyaXR5IQ==

満足しているMD5: Q2hlY2sgSW50ZWdyaXR5IQ=

   Finally, as discussed in Appendix B of [1], textual data is regularly
   altered in the normal delivery of mail.  Because the addition or
   deletion of trailing white space will result in a different digest,
   either the quoted-printable or base64 algorithm should be employed as
   a content-transfer-encoding when the Content-MD5 field is used.

最終的に、原文のデータは[1]のAppendix Bで議論するようにメールの正常分娩で定期的に変更されます。 引きずっている余白の追加か削除が異なったダイジェストをもたらすので、Content-MD5分野が使用されているとき、引用されて印刷可能であるかbase64アルゴリズムは満足している転送コード化として使われるべきです。

Myers & Rose                Standards Track                     [Page 2]

RFC 1864                Content-MD5 Header Field            October 1995

ヘッダーフィールド1995年10月の満足しているMD5のマイアーズとバラ標準化過程[2ページ]RFC1864

3. Processing the Content-MD5 field

3. Content-MD5分野を処理します。

   If the Content-MD5 field is present, a recipient user agent may
   choose to use it to verify that the contents of a MIME entity have
   not been modified during transport.  Message relays and gateways are
   expressly forbidden to alter their processing based on the presence
   of the Content-MD5 field.  However, a message gateway is allowed to
   remove the Content-MD5 field if the corresponding MIME entity is
   translated into a different content-type.

Content-MD5分野が存在しているなら、受取人ユーザエージェントは、MIME実体のコンテンツが輸送の間変更されていないことを確かめるのにそれを使用するのを選ぶかもしれません。 メッセージリレーとゲートウェイがContent-MD5分野の存在に基づく彼らの処理を変更するのが明白に禁じられます。 しかしながら、対応するMIME実体が異なったcontent typeに翻訳されるなら、メッセージゲートウェイはContent-MD5野原を取り除くことができます。

4. Security Considerations

4. セキュリティ問題

   This document specifies a data integrity service that protects data
   from accidental modification while in transit from the sender to the
   recipient.  A secure data integrity service, such as that provided by
   Privacy Enhanced Mail [3], is conjectured to protect data from all
   modifications.

このドキュメントはトランジットにはある間に偶然の変更からデータを送付者から受取人まで保護するデータ保全サービスを指定します。 Privacy Enhancedメール[3]によって提供されたそれなどの安全なデータ保全サービスは、すべての変更からデータを保護するために推測されます。

5. Acknowledgements

5. 承認

   This memo is based almost entirely on text originally written by
   Nathaniel Borenstein of Bellcore.  In addition, several improvements
   were suggested by Keith Moore of the University of Tennessee,
   Knoxville.

このメモは元々BellcoreのナザニエルBorensteinによって書かれたテキストにほぼ完全に基づいています。 さらに、いくつかの改良がテネシー、ノクスビルの大学のキース・ムーアによって提案されました。

6. References

6. 参照

   [1] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
       Extensions) Part One: Mechanisms for Specifying and Describing
       the Format of Internet Message Bodies", RFC 1521, Bellcore,
       Innosoft, September 1993.

[1] Borenstein、N.、およびN.フリード、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1521、Bellcore、Innosoft、1993年9月。

   [2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT
       Laboratory for Computer Science and RSA Data Security, Inc.,
       April 1992.

[2] 最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321、MITコンピュータサイエンス研究所、およびRSA Data Security Inc.(1992年4月)。

   [3] Linn, J., "Privacy Enhancement for Internet Electronic Mail, Part
       I: Message Encryption and Authentication Procedures", RFC 1421,
       IAB IRTF PSRG, IETF PEM WG, February 1993.

[3] リン、J.、「インターネット電子メール、部分Iのためのプライバシー増進:、」 「メッセージ暗号化と認証手順」、RFC1421、IAB IRTF PSRG、IETF PEM WG、2月1993日

Myers & Rose                Standards Track                     [Page 3]

RFC 1864                Content-MD5 Header Field            October 1995

ヘッダーフィールド1995年10月の満足しているMD5のマイアーズとバラ標準化過程[3ページ]RFC1864

7. Authors' Addresses

7. 作者のアドレス

   John G. Myers
   Carnegie Mellon University

ジョンG.マイアーズカーネギーメロン大学

   EMail: jgm+@cmu.edu

メール: jgm+@cmu.edu

   Marshall T. Rose
   Dover Beach Consulting, Inc.

マーシャルT.バラドーヴァービーチコンサルティングInc.

   EMail: mrose@dbc.mtview.ca.us

メール: mrose@dbc.mtview.ca.us

Myers & Rose                Standards Track                     [Page 4]

マイアーズとバラ標準化過程[4ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

Linux・WindowsでMTUを変更する方法(ジャンボフレーム)

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る