ids/2/738.txt

#?SuikaWiki/0.9
'''The Content-MD5 Header Field ([INS[Content-MD5 頭欄]])'''

[INS[
訳注: [[Content-MD5:]] 欄を定義する RFC は、 RFC 1544 が廃止され
RFC 1864 になりました。ここでは両者を同時に (訳文も含めて)
示しています。[INS[1864 での追加分]], [DEL[1864 での削除分]]にご注意下さい。
]INS]

-Network Working Group                                            
-Request for Comments: [DEL[1544]] [INS[1864]]                  
-[DEL[Category: Standards Track]]
-[INS[Obsoletes: 1544]]
-[INS[J. Myers]]
-[INS[Carnegie Mellon]]
-M. Rose
-Dover Beach Consulting, Inc.
-[DEL[November 1993]] [INS[October 1995]]
*Status of this Memo [INS[このメモの位置付け]]
>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.
*Abstract [INS[概要]]
>This memo specifies an optional header field, Content-MD5, for use
with MIME-conformant messages.

このメモは、 MIME 適合メッセージで使う省略可能な頭欄、
Content-MD5 を規定します。

*Table of Contents [INS[目次]]
   1. Introduction ..........................................    1
   2. Generation of the Content-MD5 Field ...................    2
   3. Processing the Content-MD5 field ......................    [DEL[2]][INS[3]]
   4. Security Considerations ...............................    3
   5. Acknowledgements ......................................    3
   6. References ............................................    3
   7. Author's Address ......................................    [DEL[3]][INS[4]]
*1.  Introduction [INS[はじめに]]
>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. [INS[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]] で提供されていますが、それでも一度復号されたデータが手を加えられていないか確認する方法があるのが望ましいです。この理由から、
このメモは省略可能な頭欄 Content-MD5 を定義します。
これは、メッセージ完全性確認 (MIC)
として、復号したデータが最初に送られたのと同じデータかを確認するのに使うことが出来ます。 [INS[(1864 追加) Content-MD5 頭は message/external-body 型の物体のカプセル化された頭に置いて、取り出して復号したデータが最初に参照されたのと同じデータであるか検証するのに使っても構いません。]]

>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
algorithm itself is defined in [2].  This memo specifies how the
algorithm may be used as an integrity check for MIME mail.

MD5 は、任意の長さのデータの128ビットの「要約」を、
データの変更が要約の変更となって反映される、
高い信頼性を持った計算算法です。 MD5 算法は [2]
で定義されています。このメモは、 MIME 
メイルの完全性確認にこの算法をどう使うことが出来るかを規定します。

*2.  Generation of the Content-MD5 Field [INS[Content-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-Enhanced) 
メイル・サービスが利用できない時には常に使うことを推奨します。
(詳しくは第4章を御覧下さい。)
Content-MD5 欄は「葉っぱ」性の MIME 
実体にのみ加えることが出来ます。つまり、
Content-MD5 欄は複数部分や message/rfc822 
を除く内容型と共に使うことが出来ます。

[INS[
[4] 訳注: [[HTTP]] は、複数部分や message/rfc822
にも使って良いと規定しています。
]INS]

>To generate the value of the Content-MD5 field, the MD5 algorithm is
computed on the canonical form of the [DEL[data]][INS[MIME entity's object]]. 
In particular, this
means that the sender applies the MD5 algorithm on the [DEL[raw]] 
data [INS[immediately after conversion to canonical form]],
before applying any content-transfer-encoding, and that the receiver
also applies the MD5 algorithm on the [DEL[raw data]][INS[canonical form]],
after undoing any
content-transfer-encoding.  For textual data, [INS[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. [INS[The canonical  encoding model of MIME is described in Appendix G of [1].]]

Content-MD5 欄の値を生成するには、 MD5 
算法で[DEL[データ]][INS[MIME 実体の物体]]の正規形を計算します。
すなわち、送信者は MD5 算法を [INS[正規形に変換したすぐ後で]]、内容転送符号化を適用する前の[DEL[生]]データに対して使用し、また受信者も内容転送符号化を解いた後の生データに対して
MD5 算法を使います。
文字データの場合、 MD5 算法において改行の正規形、つまり改行が CR-LF
組で表される状態のデータで計算しなければな[DEL[りません]][INS[らないということです]]。[INS[MIME の正規符号化モデルについては 1 の附属書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オクテットの2進データの列と見なせます。この16ビットを、
Content-MD5 欄に入れる値にするため、 [[Base64]]
算法で符号化します。このようにして、 MIME 実体の生データの MD5
算法の応用が (ありそうもないですが) 「Check Integrity!」
(完全か確認!) という値の要約を出したとすると、
MIME [[実体]]の頭にはこのような欄が入ります。

               Content-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] の附属書 B で議論しているように、
文字データはメイルの通常の配送で規則的に改められます。末尾の空白間隔の追加や削除により要約が違ってくるので、
Content-MD5 欄を使うときは [[Quoted-Printable]]
または base64 算法を使うのが良いでしょう。

*3.  Processing the Content-MD5 field [INS[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 its 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 [INS[安全性に関して]]

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

この文書は、送信者から受信者への転送中の偶発的変更からデータを護るデータ正当性サービスを規定します。高度秘密メイル
([[PEM]]) が提供するような安全データ正当性サービスはあらゆる変更からデータを護ると推測されます。

*5.  Acknowledgements [INS[謝辞]]

>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 の Nathaniel Borenstein
が最初書いた文章をもとにしています。また、幾つかの改良を
University of Tennessee, Knoxville の Keith Moore
が提案してくれました。

*6.  References [INS[参考文献]]

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

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

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

*7.  Author's Address [INS[著者の連絡先]]
[INS[
   John G. Myers
   Carnegie Mellon University

   EMail: jgm+@cmu.edu
]INS]
   Marshall T. Rose
   Dover Beach Consulting, Inc.
   [DEL[420 Whisman Court]]
   [DEL[Mountain View, CA 94043-2112]]

   [DEL[Phone: (415) 968-1052]]
   EMail: mrose@dbc.mtview.ca.us

*LICENSE
[[RFCのライセンス]]
*メモ
1	#?SuikaWiki/0.9
2	'''The Content-MD5 Header Field ([INS[Content-MD5 頭欄]])'''
3
4	[INS[
5	訳注: [[Content-MD5:]] 欄を定義する RFC は、 RFC 1544 が廃止され
6	RFC 1864 になりました。ここでは両者を同時に (訳文も含めて)
7	示しています。[INS[1864 での追加分]], [DEL[1864 での削除分]]にご注意下さい。
8	]INS]
9
10	-Network Working Group
11	-Request for Comments: [DEL[1544]] [INS[1864]]
12	-[DEL[Category: Standards Track]]
13	-[INS[Obsoletes: 1544]]
14	-[INS[J. Myers]]
15	-[INS[Carnegie Mellon]]
16	-M. Rose
17	-Dover Beach Consulting, Inc.
18	-[DEL[November 1993]] [INS[October 1995]]
19	*Status of this Memo [INS[このメモの位置付け]]
20	>This document specifies an Internet standards track protocol for the
21	Internet community, and requests discussion and suggestions for
22	improvements. Please refer to the current edition of the "Internet
23	Official Protocol Standards" (STD 1) for the standardization state
24	and status of this protocol. Distribution of this memo is unlimited.
25	*Abstract [INS[概要]]
26	>This memo specifies an optional header field, Content-MD5, for use
27	with MIME-conformant messages.
28
29	このメモは、 MIME 適合メッセージで使う省略可能な頭欄、
30	Content-MD5 を規定します。
31
32	*Table of Contents [INS[目次]]
33	1. Introduction .......................................... 1
34	2. Generation of the Content-MD5 Field ................... 2
35	3. Processing the Content-MD5 field ...................... [DEL[2]][INS[3]]
36	4. Security Considerations ............................... 3
37	5. Acknowledgements ...................................... 3
38	6. References ............................................ 3
39	7. Author's Address ...................................... [DEL[3]][INS[4]]
40	*1. Introduction [INS[はじめに]]
41	>Despite all of the mechanisms provided by MIME [1] which attempt to
42	protect data from being damaged in the course of email transport, it
43	is still desirable to have a mechanism for verifying that the data,
44	once decoded, are intact. For this reason, this memo defines the use
45	of an optional header field, Content-MD5, which may be used as a
46	message integrity check (MIC), to verify that the decoded data are
47	the same data that were initially sent. [INS[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.]]
48
49	電子メイル転送の経路での損傷からデータを護るあらゆる方法が
50	[[MIME]] で提供されていますが、それでも一度復号されたデータが手を加えられていないか確認する方法があるのが望ましいです。この理由から、
51	このメモは省略可能な頭欄 Content-MD5 を定義します。
52	これは、メッセージ完全性確認 (MIC)
53	として、復号したデータが最初に送られたのと同じデータかを確認するのに使うことが出来ます。 [INS[(1864 追加) Content-MD5 頭は message/external-body 型の物体のカプセル化された頭に置いて、取り出して復号したデータが最初に参照されたのと同じデータであるか検証するのに使っても構いません。]]
54
55	>MD5 is an algorithm for computing a 128 bit "digest" of
56	arbitrary-length data, with a high degree of confidence that any
57	alterations in
58	the data will be reflected in alterations in the digest. The MD5
59	algorithm itself is defined in [2]. This memo specifies how the
60	algorithm may be used as an integrity check for MIME mail.
61
62	MD5 は、任意の長さのデータの128ビットの「要約」を、
63	データの変更が要約の変更となって反映される、
64	高い信頼性を持った計算算法です。 MD5 算法は [2]
65	で定義されています。このメモは、 MIME
66	メイルの完全性確認にこの算法をどう使うことが出来るかを規定します。
67
68	*2. Generation of the Content-MD5 Field [INS[Content-MD5 欄の生成]]
69
70	>The Content-MD5 field is generated by only an originating user agent.
71	Message relays and gateways are expressly forbidden from generating a
72	Content-MD5 field.
73
74	Content-MD5 欄は原[[利用者エージェント]]によってのみ生成されます。
75	メッセージ中継者及び[[関門]]が Content-MD5 欄を作ることは明白に禁止します。
76
77	>Use of the Content-MD5 field is completely optional, but its use is
78	recommended whenever data integrity is desired, but Privacy-Enhanced
79	Mail services [3] are not available. (Consult Section 4 for further
80	details.) The Content-MD5 field may only be added to MIME entities of
81	a `leaf' nature, i.e., the Content-MD5 field may be used with any
82	content type other than multipart or message/rfc822.
83
84	Content-MD5 欄の使用は完全に任意でありますが、
85	データの完全性が望まれ、しかし高度秘密 (Privacy-Enhanced)
86	メイル・サービスが利用できない時には常に使うことを推奨します。
87	(詳しくは第4章を御覧下さい。)
88	Content-MD5 欄は「葉っぱ」性の MIME
89	実体にのみ加えることが出来ます。つまり、
90	Content-MD5 欄は複数部分や message/rfc822
91	を除く内容型と共に使うことが出来ます。
92
93	[INS[
94	[4] 訳注: [[HTTP]] は、複数部分や message/rfc822
95	にも使って良いと規定しています。
96	]INS]
97
98	>To generate the value of the Content-MD5 field, the MD5 algorithm is
99	computed on the canonical form of the [DEL[data]][INS[MIME entity's object]].
100	In particular, this
101	means that the sender applies the MD5 algorithm on the [DEL[raw]]
102	data [INS[immediately after conversion to canonical form]],
103	before applying any content-transfer-encoding, and that the receiver
104	also applies the MD5 algorithm on the [DEL[raw data]][INS[canonical form]],
105	after undoing any
106	content-transfer-encoding. For textual data, [INS[this means]]
107	the MD5 algorithm must
108	be computed on data in which the canonical form for newlines applies,
109	that is, in which each newline is represented by a CR-LF pair. [INS[The canonical encoding model of MIME is described in Appendix G of [1].]]
110
111	Content-MD5 欄の値を生成するには、 MD5
112	算法で[DEL[データ]][INS[MIME 実体の物体]]の正規形を計算します。
113	すなわち、送信者は MD5 算法を [INS[正規形に変換したすぐ後で]]、内容転送符号化を適用する前の[DEL[生]]データに対して使用し、また受信者も内容転送符号化を解いた後の生データに対して
114	MD5 算法を使います。
115	文字データの場合、 MD5 算法において改行の正規形、つまり改行が CR-LF
116	組で表される状態のデータで計算しなければな[DEL[りません]][INS[らないということです]]。[INS[MIME の正規符号化モデルについては 1 の附属書Gで説明されています。]]
117
118	>The output of the MD5 algorithm is a 128 bit digest. When viewed in
119	network byte order (big-endian order), this yields a sequence of 16
120	octets of binary data. These 16 octets are then encoded according to
121	the base64 algorithm in order to obtain the value that is placed in
122	the Content-MD5 field. Thus, if the application of the MD5 algorithm
123	over the raw data of a MIME entity results in a digest having the
124	(unlikely) value of "Check Integrity!", then that MIME entity's
125	header could contain the field
126
127	MD5 算法の出力は 128 ビット要約です。[[ネットワーク・バイト順]]
128	(大エンディアン順)
129	で、16オクテットの2進データの列と見なせます。この16ビットを、
130	Content-MD5 欄に入れる値にするため、 [[Base64]]
131	算法で符号化します。このようにして、 MIME 実体の生データの MD5
132	算法の応用が (ありそうもないですが) 「Check Integrity!」
133	(完全か確認!) という値の要約を出したとすると、
134	MIME [[実体]]の頭にはこのような欄が入ります。
135
136	Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
137
138	>Finally, as discussed in Appendix B of [1], textual data is regularly
139	altered in the normal delivery of mail. Because the addition or
140	deletion of trailing white space will result in a different digest,
141	either the quoted-printable or base64 algorithm should be employed as
142	a content-transfer-encoding when the Content-MD5 field is used.
143
144	最後に、 [1] の附属書 B で議論しているように、
145	文字データはメイルの通常の配送で規則的に改められます。末尾の空白間隔の追加や削除により要約が違ってくるので、
146	Content-MD5 欄を使うときは [[Quoted-Printable]]
147	または base64 算法を使うのが良いでしょう。
148
149	*3. Processing the Content-MD5 field [INS[Content-MD5 欄の処理]]
150
151	>If the Content-MD5 field is present, a recipient user agent may
152	choose to use it to verify that the contents of a MIME entity have
153	not been modified during transport. Message relays and gateways are
154	expressly forbidden to alter its processing based on the presence of
155	the Content-MD5 field. However, a message gateway is allowed to
156	remove the Content-MD5 field if the corresponding MIME entity is
157	translated into a different content-type.
158
159	Content-MD5 欄があった場合、受信した利用者エージェントはこれを
160	MIME 実体の内容が転送中に改竄されなかったか確認するために使っても構いません。メッセージ中継者及び関門が Content-MD5
161	欄の有無により処理を変えることは明確に禁止します。しかし、メッセージ関門は対応する
162	MIME 実体が違う content-type (内容型) に変換された場合に、
163	Content-MD5 欄を削除しても構いません。
164
165	*4. Security Considerations [INS[安全性に関して]]
166
167	>This document specifies a data integrity service that protects data
168	from accidental modification while in transit from the sender to the
169	recipient. A secure data integrity service, such as that provided by
170	Privacy Enhanced Mail [3], is conjectured to protect data from all
171	modifications.
172
173	この文書は、送信者から受信者への転送中の偶発的変更からデータを護るデータ正当性サービスを規定します。高度秘密メイル
174	([[PEM]]) が提供するような安全データ正当性サービスはあらゆる変更からデータを護ると推測されます。
175
176	*5. Acknowledgements [INS[謝辞]]
177
178	>This memo is based almost entirely on text originally written by
179	Nathaniel Borenstein of Bellcore. In addition, several improvements
180	were suggested by Keith Moore of the University of Tennessee, Knoxville.
181
182	このメモは、ほとんど全てを、 Bellcore の Nathaniel Borenstein
183	が最初書いた文章をもとにしています。また、幾つかの改良を
184	University of Tennessee, Knoxville の Keith Moore
185	が提案してくれました。
186
187	*6. References [INS[参考文献]]
188
189	[1] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
190	Extensions) Part One: Mechanisms for Specifying and Describing
191	the Format of Internet Message Bodies", RFC 1521, Bellcore,
192	Innosoft, September 1993.
193
194	[2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT
195	Laboratory for Computer Science and RSA Data Security, Inc.,
196	April 1992.
197
198	[3] Linn, J., "Privacy Enhancement for Internet Electronic Mail, Part
199	I: Message Encryption and Authentication Procedures", RFC 1421,
200	IAB IRTF PSRG, IETF PEM WG, February 1993.
201
202	*7. Author's Address [INS[著者の連絡先]]
203	[INS[
204	John G. Myers
205	Carnegie Mellon University
206
207	EMail: jgm+@cmu.edu
208	]INS]
209	Marshall T. Rose
210	Dover Beach Consulting, Inc.
211	[DEL[420 Whisman Court]]
212	[DEL[Mountain View, CA 94043-2112]]
213
214	[DEL[Phone: (415) 968-1052]]
215	EMail: mrose@dbc.mtview.ca.us
216
217	*LICENSE
218	[[RFCのライセンス]]
219	*メモ