RFC2015 日本語訳
2015 MIME Security with Pretty Good Privacy (PGP). M. Elkins. October 1996. (Format: TXT=14223 bytes) (Updated by RFC3156) (Status: PROPOSED STANDARD)
RFC一覧
英語原文
Network Working Group M. Elkins
Request for Comments: 2015 The Aerospace Corporation
Category: Standards Track October 1996
| MIME Security with Pretty Good Privacy (PGP)
PGP による MIME セキュリティ
| Status of this 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.
この文書は，インターネットコミュニティのための標準を規定すると
ともに，それを改良するための議論や提言を求めるものである．
本プロトコルの標準化状態，および，ステータスについては
"Internet Official Protocol Standards" (STD 1) の最新版を参照
すること．
このメモの配布に制限はない．
| Abstract
要約
| This document describes how Pretty Good Privacy (PGP) can be used to
| provide privacy and authentication using the Multipurpose Internet
| Mail Extensions (MIME) security content types described in RFC1847.
この文書では，RFC1847で述べられたMIMEセキュリティ Content-Type
を用いた PGP によるプライバシーと認証を実現するための方法を述
べる．
| 1. Introduction
1. 始めに
| Previous work on integrating PGP with MIME (including the since
| withdrawn application/pgp content type) has suffered from a number of
| problems, the most significant of which is the inability to recover
| signed message bodies without parsing data structures specific to
| PGP. This work makes use of the elegant solution proposed in
| RFC1847, which defines security multipart formats for MIME. The
| security multiparts clearly separate the signed message body from the
| signature, and have a number of other desirable properties. This
| document is styled after RFC 1848, which defines MIME Object Security
| Services (MOSS) for providing security and authentication.
PGPをMIMEに統合しようとしたこれまでの試み (その後撤回された
application/pgp コンテントタイプを含む) では多くの問題が発生し
て苦労させられている．
最も顕著な問題は PGP 固有のデータ構造を解析する事無しに署名付
きメッセージを復元できない事である．
本文書では， MIME のためのセキュリティ・マルチパート形式を定め
た RFC1847 で提案されているエレガントな解決方法を利用している．
セキュリティ・マルチパートは，メッセージ部と署名部とが明確に分
かれており，多くの望ましい属性を持っている．
この文書は，セキュリティと認証のために MOSS (MIME Object
Security Services) を定義している RFC1848 の形式を踏襲している．
| This document defines three new content types for implementing
| security and privacy with PGP: application/pgp-encrypted,
| application/pgp-signature and application/pgp-keys.
PGP を用いたセキュリティとプライバシーの実現のために，以下の 3
つの新しい Content-Type を定義している．
・application/pgp-encrypted
・application/pgp-signature
・application/pgp-keys
| 1.1 Compliance
1.1 承諾
| In order for an implementation to be compliant with this
| specification, is it absolutely necessary for it to obey all items
| labeled as MUST or REQUIRED.
この仕様に忠実な実装を実施するには， MUST または REQUIRED を付
けている項目について全て従うことが必要不可欠である．
| 2. PGP data formats
2. PGPデータ形式
| PGP can generate either ASCII armor (described in [3]) or 8-bit
| binary output when encrypting data, generating a digital signature,
| or extracting public key data. The ASCII armor output is the
| REQUIRED method for data transfer. This allows those users who do
| not have the means to interpret the formats described in this
| document to be able extract and use the PGP information in the
| message.
PGP ではデータの暗号化，電子署名，公開鍵抽出に際してアスキー装
甲ファイル，又はバイナリファイルのいずれでも生成する事ができる．
アスキー装甲出力はデータ転送のためには必須(REQUIRED)機能である．
これにより，この文書中で述べる PGP/MIME の形式を解釈できないユー
ザーでも，メッセージ中の PGP による情報を取り出し利用する事が可
能となる．
| When the amount of data to be transmitted requires that it be sent in
| many parts, the MIME message/partial mechanism should be used rather
| than the multipart ASCII armor PGP format.
大量のデータを多くの部分に分けて送信する場合は，マルチパート・
アスキー装甲 PGP 形式よりも MIME message/partial 機構を使うべき
である．
| 3. Content-Transfer-Encoding restrictions
3. Content-Transfer-Encoding の規定
| Multipart/signed and multipart/encrypted are to be treated by agents
| as opaque, meaning that the data is not to be altered in any way [1].
| However, many existing mail gateways will detect if the next hop does
| not support MIME or 8-bit data and perform conversion to either
| Quoted-Printable or Base64. This presents serious problems for
| multipart/signed, in particular, where the signature is invalidated
| when such an operation occurs. For this reason all data signed
| according to this protocol MUST be constrained to 7 bits (8- bit data
| should be encoded using either Quoted-Printable or Base64). Note
| that this also includes the case where a signed object is also
| encrypted (see section 6). This restriction will increase the
| likelihood that the signature will be valid upon receipt.
multipart/signedとmultipart/encryptedはエージェントによって『不
透明なデータ』として扱われる．これはどのようにも内容を変更され
ない事を意味する．
しかし，既存のメールゲートウェイの多くは配送先が MIME や 8bit
データをサポートしていない事を検出するとデータを Quoted-Printable
や Base64 を用いて変換してしまう．
このような処理が行われた場合， multipart/signed に対して署名デー
タは全く無効なものになってしまうという重大な問題を引きおこして
しまう．
こういった理由により本プロトコルに従って署名されたデータは
(8bit のデータは Quoted-Printable や Base64 を用いて) 7bit デー
タに変換しておかなければならない．
この件は署名された対象が暗号化される場合にも適用されることに注
意せよ．(6節参照)
この規定は，受領時に署名が正当であるという可能性を増やす．
| Data that is ONLY to be encrypted is allowed to contain 8-bit
| characters and therefore need not be converted to a 7-bit format.
暗号化*のみ*行うデータは，8-bit 文字を含む事を許され，それゆえ
に 7bit 形式へ変換する必要はない．
| Implementor's note: It cannot be stressed enough that applications
| using this standard should follow MIME's suggestion that you "be
| conservative in what you generate, and liberal in what you accept."
| In this particular case it means it would be wise for an
| implementation to accept messages with any content-transfer-
| encoding, but restrict generation to the 7-bit format required by
| this memo. This will allow future compatibility in the event the
| Internet SMTP framework becomes 8-bit friendly.
実装者メモ：
この標準を利用するアプリケーションは， MIME 規格の中で暗に示
されている以下の思想に従うべきであり，このことは，いくら強調
しても強調しすぎる事はないだろう．すなわち，
「あなたが生成するものについては保守的であれ，
あなたが受け入れるものには寛大であれ」
今回の場合，この格言の意味は
「あらゆる Content-Transfer-Encoding メッセージを受け取れる
ように，しかしメッセージ生成はこの文書で要求されているよう
に 7-bit 形式で行うように実装するのがよい」
となる．
そうすれば，将来，インターネットの SMTP 構成が， 8-bitスルー
になった場合でも互換性を保つ事ができる．
| 4. PGP encrypted data
4. PGP 暗号化データ
| Before encryption with PGP, the data should be written in MIME
| canonical format (body and headers).
PGP にて暗号化を行う前に，データを MIME の正準な形式
(body と header）で整形しておかねばならない．
| PGP encrypted data is denoted by the "multipart/encrypted" content
| type, described in [1], and MUST have a "protocol" parameter value of
| "application/pgp-encrypted". Note that the value of the parameter
| MUST be enclosed in quotes.
参考文献[1]で述べられている通り， PGP にて暗号化されたデータの
Content-Type は "multipart/encrypted" と示される．
これには，値 "application/pgp-encrypted" を持つ "protocol"
パラメータが必要である(MUST)．
パラメータの値は引用符にて括らなくてはならない(MUST)ことに注意
せよ．
| The multipart/encrypted MUST consist of exactly two parts. The first
| MIME body part must have a content type of "application/pgp-
| encrypted". This body contains the control information. A message
| complying with this standard MUST contain a "Version: 1" field in
| this body. Since the PGP packet format contains all other
| information necessary for decrypting, no other information is
| required here.
multipart/encrypted は正確に２つのパートが必要(MUST)である．
最初のパートのMIMEボディの Content-Type は
"application/pgp-encrypted" でなくてはならない．
このボディ部は，制御情報からなる．
本標準を満たすためには，メッセージはボディ部に "Version: 1"
フィールドを含まなくてはならない(MUST)．
PGP パケットは復号化に必要な情報を全て含んでいるので，このパー
トに他の情報は必要無い．
| The second MIME body part MUST contain the actual encrypted data. It
| must be labeled with a content type of "application/octet- stream".
第２の MIME ボディパートは，実際の暗号化データを含まなくてはな
らない(MUST)．
Content-Type は "application/octet-stream" でなければならない．
| Example message:
メッセージ例：
From: Michael Elkins
To: Michael Elkins
Mime-Version: 1.0
Content-Type: multipart/encrypted; boundary=foo;
protocol="application/pgp-encrypted"
--foo
Content-Type: application/pgp-encrypted
Version: 1
--foo
Content-Type: application/octet-stream
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
=zzaA
-----END PGP MESSAGE-----
--foo--
| 5. PGP signed data
5. PGP署名データ
| PGP signed messages are denoted by the "multipart/signed" content
| type, described in [1], with a "protocol" parameter which MUST have a
| value of "application/pgp-signature" (MUST be quoted). The "micalg"
| parameter MUST have a value of "pgp-", where identifies the message integrity check (MIC) used to generate
| the signature. The currently defined values for are
| "md5" for the MD5 checksum, and "sha1" for the SHA.1 algorithm.
参考文献[1]で述べられている通り， PGP 署名メッセージは
"multipart/signed" コンテントタイプで示され，
値 "application/pgp-signature" を持つ "protocol" パラメータが
必要(MUST)である．
(引用符で括ることが必要(MUST))
"micalg" パラメータには "pgp-" が必要である(MUST)．
には，署名作成に使用するメッセージ完全性検査 (MIC)
を指定する．
現在のところ の値としては MD5 チェックサムを指定
する "md5" と， SHA.1 アルゴリズムを指定する "sha1" が定義され
ている．
| The multipart/signed body MUST consist of exactly two parts. The
| first part contains the signed data in MIME canonical format,
| including a set of appropriate content headers describing the data.
multipart/signed のボディは，正確に2つのパートで構成されなくて
はならない(MUST)．
最初のパートは適切なヘッダーを含む署名されたデータが MIME の正
準な形式に従い格納される．
| The second body MUST contain the PGP digital signature. It MUST be
| labeled with a content type of "application/pgp-signature".
第２のパートは，PGPデジタル署名を含んでいなければならない(MUST)．
またこのパートは"application/pgp-signature" コンテントタイプで
なければならない(MUST)．
| When the PGP digital signature is generated:
PGPデジタル署名を作る時には：
| (1) The data to be signed must first be converted to its
| type/subtype specific canonical form. For text/plain, this
| means conversion to an appropriate character set and conversion
| of line endings to the canonical sequence.
(1) 署名されるデータはまずはじめに，その type/subtype に特有
の標準形に変換されなければならない．
例えば text/plain の場合では，適切な文字コードへ変換する
ことと行末を正準の 列へ変換することを意味する．
| (2) An appropriate Content-Transfer-Encoding is then applied. Each
| line of the encoded data MUST end with the canonical
| sequence.
(2) 次に，適切な Content-Transfer-Encoding が適用される．
エンコードされたデータの各々の行は正準の 列で終わっ
ていなければならない(MUST)．
| (3) MIME content headers are then added to the body, each ending
| with the canonical sequence.
(3) さらに各々の行末を正準の 列にしながら， MIME
コンテントヘッダ部がボディ部に追加される．
| (4) As described in [1], the digital signature MUST be calculated
| over both the data to be signed and its set of content headers.
(4) 参考文献[1]で述べられている通り，デジタル署名の計算は，署
名されるデータと，それに付加されるコンテントヘッダ一式に対
して行われなければならない(MUST)．
| (5) The signature MUST be generated detached from the signed data
| so that the process does not alter the signed data in any way.
(5) 署名処理自身によって署名されたデータが改変される事が無いよ
うに，署名は署名されるデータと分離して生成しなければならな
い(MUST)．
| Example message:
メッセージ例：
From: Michael Elkins
To: Michael Elkins
Mime-Version: 1.0
Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
protocol="application/pgp-signature"
--bar
& Content-Type: text/plain; charset=iso-8859-1
& Content-Transfer-Encoding: quoted-printable
&
& =A1Hola!
&
& Did you know that talking to yourself is a sign of senility?
&
& It's generally a good idea to encode lines that begin with
& From=20because some mail transport agents will insert a greater-
& than (>) sign, thus invalidating the signature.
&
& Also, in some cases it might be desirable to encode any =20
&railing whitespace that occurs on lines in order to ensure =20
& that the message signature is not invalidated when passing =20
& a gateway that modifies such whitespace (like BITNET). =20
&
& me
--bar
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
HOxEa44b+EI=
=ndaj
-----END PGP MESSAGE-----
--bar--
| The "&"s in the previous example indicate the portion of the data
| over which the signature was calculated.
例の中の"&"記号は，署名の計算に使われる部分を示す．
| Though not required, it is generally a good idea to use Quoted-
| Printable encoding in the first step (writing out the data to be
| signed in MIME canonical format) if any of the lines in the data
| begin with "From ", and encode the "F". This will avoid an MTA
| inserting a ">" in front of the line, thus invalidating the
| signature!
必須ではないが，最初のステップとしてデータを Quoted-Printable
を用いてエンコードしておく (すなわち署名されるデータを正準の
MIME 形式に従って出力しておく) 事は一般的によい方法である．
もし，データの中に "From" ではじまる行があれば，その "F" をエ
ンコードするように．
この作業によってMTA が行頭に">" を挿入して署名データを無効にし
てしまう事を防ぐ事ができる．
| Upon receipt of a signed message, an application MUST:
署名されたメッセージを受け取ったら，アプリケーションは，次のこ
とをしなければならない(MUST)
| (1) Convert line endings to the canonical sequence before
| the signature can be verified. This is necessary since the
| local MTA may have converted to a local end of line convention.
(1) 署名を検証する前に行末を正準の 列にする．
これは MTA が行末をローカルシステムのコードに変換している
場合があるので必要である．
| (2) Pass both the signed data and its associated content headers
| along with the PGP signature to the signature verification
| service.
(2) 署名されたデータと，関連するコンテントヘッダ(署名と一緒に)
を合わせて署名の検証を行う．
| 6. Encrypted and Signed Data
6. 暗号化され，かつ署名されたデータ
| Sometimes it is desirable to both digitally sign and then encrypt a
| message to be sent. This protocol allows for two methods of
| accomplishing this task.
送信すべきメッセージに電子署名を行い更に暗号化することが望まし
い場合がある．本プロトコルではその為の２つの方法について考慮し
ている．
| 6.1 RFC1847 Encapsulation
6.1 RFC1847 カプセル化
| [1], it is stated that the data should first be signed as a
| multipart/signature body, and then encrypted to form the final
| multipart/encrypted body, i.e.,
参考文献[1] に述べられているように，まず multipart/signed のボ
ディとして署名データを作成し，最終的に multipart/encrypted の
ボディ形式となるように暗号化を行う．つまり下記の例のように行う．
Content-Type: multipart/encrypted;
protocol="application/pgp-encrypted"; boundary=foo
--foo
Content-Type: application/pgp-encrypted
Version: 1
--foo
Content-Type: application/octet-stream
-----BEGIN PGP MESSAGE-----
& Content-Type: multipart/signed; micalg=pgp-md5
& protocol="application/pgp-signature"; boundary=bar
&
& --bar
& Content-Type: text/plain; charset=us-ascii
&
& This message was first signed, and then encrypted.
&
& --bar
& Content-Type: application/pgp-signature
&
& -----BEGIN PGP MESSAGE-----
& Version: 2.6.2
&
& iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
& jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
& uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
& HOxEa44b+EI=
& =ndaj
& -----END PGP MESSAGE-----
&
& --bar--
-----END PGP MESSAGE-----
--foo--
| (The text preceded by '&' indicates that it is really
| encrypted, but presented as text for clarity.)
(行頭に "&" 記号のある部分は，本当は暗号化されているが，説明の
ためにテキストとして示している．)
| 6.2 Combined method
6.2 同時方式
| Versions 2.x of PGP also allow data to be signed and encrypted in one
| operation. This method is an acceptable shortcut, and has the
| benefit of less overhead. The resulting data should be formed as a
| "multipart/encrypted" object as described above.
PGP 2.x では，署名と暗号化を一回の操作で同時に行うこともできる．
この方法は受け入れられるべき手っ取り早い手段であり，負荷軽減効
果がある．
結果として生ずるデータは，上記で説明した multipart/encryptedi と
して生成される．
| Messages which are encrypted and signed in this combined fashion are
| REQUIRED to follow the same canonicalization rules as for
| multipart/signed objects.
この同時方式で暗号化，および署名されたメッセージは，multipart/signed
オブジェクトと同じ正規化規則に従わなくてはならない(REQUIRED)．
| It is explicitly allowed for an agent to decrypt a combined message
| and rewrite it as a multipart/signed object using the signature data
| embedded in the encrypted version.
メールエージェントが，同時方式のメッセージを復号し，暗号化され
て埋め込まれた署名を用いた multipart/signed オブジェクトとして
書き直すことは，明示的に許可されている．
| 7. Distribution of PGP public keys
7. PGP公開鍵の配布
Content-Type: application/pgp-keys
Required parameters: none
Optional parameters: none
| This is the content type which should be used for relaying public key
| blocks.
これは，公開鍵ブロックを伝達するための Content-Type である．
| 8. Notes
8. 注意
| PGP and Pretty Good Privacy are trademarks of Philip Zimmermann.
PGPとPretty Good Privacy は Philip Zimmermann の商標である．
| 9. Security Considerations
9. セキュリティについての考察
| Use of this protocol has the same security considerations as PGP, and
| is not known to either increase or decrease the security of messages
| using it; see [3] for more information.
本プロトコルを使用することにより， PGP と同等のセキュリティを
得られる．
ただし，それによりメッセージのセキュリティが改善されるか改悪さ
れるかは不明である．
詳細は参考文献[3]を参照のこと．
| 10. Author's Address
10. 著者連絡先
Michael Elkins
P.O. Box 92957 - M1/102
Los Angeles, CA 90009-2957
Phone: +1 310 336 8040
Fax: +1 310 336 4402
| References
参考文献
[1] Galvin, J., Murphy, G., Crocker, S., and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, October 1995.
[2] Galvin, J., Murphy, G., Crocker, S., and N. Freed, "MIME Object
Security Services", RFC 1848, October 1995.
[3] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
Exchange Formats", RFC 1991, August 1996.
一覧
スポンサーリンク
