Network Working Group M. Elkins Request for Comments: 2015 The Aerospace Corporation Category: Standards Track October 1996 PGP による MIME セキュリティ このメモの位置付け この文書は,インターネットコミュニティのための標準を規定すると ともに,それを改良するための議論や提言を求めるものである. 本プロトコルの標準化状態,および,ステータスについては "Internet Official Protocol Standards" (STD 1) の最新版を参照 すること. このメモの配布に制限はない. 要約 この文書では,RFC1847で述べられたMIMEセキュリティ Content-Type を用いた PGP によるプライバシーと認証を実現するための方法を述 べる. 1. 始めに PGPをMIMEに統合しようとしたこれまでの試み (その後撤回された application/pgp コンテントタイプを含む) では多くの問題が発生し て苦労させられている. 最も顕著な問題は PGP 固有のデータ構造を解析する事無しに署名付 きメッセージを復元できない事である. 本文書では, MIME のためのセキュリティ・マルチパート形式を定め た RFC1847 で提案されているエレガントな解決方法を利用している. セキュリティ・マルチパートは,メッセージ部と署名部とが明確に分 かれており,多くの望ましい属性を持っている. この文書は,セキュリティと認証のために MOSS (MIME Object Security Services) を定義している RFC1848 の形式を踏襲している. PGP を用いたセキュリティとプライバシーの実現のために,以下の 3 つの新しい Content-Type を定義している. ・application/pgp-encrypted ・application/pgp-signature ・application/pgp-keys 1.1 承諾 この仕様に忠実な実装を実施するには, MUST または REQUIRED を付 けている項目について全て従うことが必要不可欠である. 2. PGPデータ形式 PGP ではデータの暗号化,電子署名,公開鍵抽出に際してアスキー装 甲ファイル,又はバイナリファイルのいずれでも生成する事ができる. アスキー装甲出力はデータ転送のためには必須(REQUIRED)機能である. これにより,この文書中で述べる PGP/MIME の形式を解釈できないユー ザーでも,メッセージ中の PGP による情報を取り出し利用する事が可 能となる. 大量のデータを多くの部分に分けて送信する場合は,マルチパート・ アスキー装甲 PGP 形式よりも MIME message/partial 機構を使うべき である. 3. Content-Transfer-Encoding の規定 multipart/signedとmultipart/encryptedはエージェントによって『不 透明なデータ』として扱われる.これはどのようにも内容を変更され ない事を意味する. しかし,既存のメールゲートウェイの多くは配送先が MIME や 8bit データをサポートしていない事を検出するとデータを Quoted-Printable や Base64 を用いて変換してしまう. このような処理が行われた場合, multipart/signed に対して署名デー タは全く無効なものになってしまうという重大な問題を引きおこして しまう. こういった理由により本プロトコルに従って署名されたデータは (8bit のデータは Quoted-Printable や Base64 を用いて) 7bit デー タに変換しておかなければならない. この件は署名された対象が暗号化される場合にも適用されることに注 意せよ.(6節参照) この規定は,受領時に署名が正当であるという可能性を増やす. 暗号化*のみ*行うデータは,8-bit 文字を含む事を許され,それゆえ に 7bit 形式へ変換する必要はない. 実装者メモ: この標準を利用するアプリケーションは, MIME 規格の中で暗に示 されている以下の思想に従うべきであり,このことは,いくら強調 しても強調しすぎる事はないだろう.すなわち, 「あなたが生成するものについては保守的であれ, あなたが受け入れるものには寛大であれ」 今回の場合,この格言の意味は 「あらゆる Content-Transfer-Encoding メッセージを受け取れる ように,しかしメッセージ生成はこの文書で要求されているよう に 7-bit 形式で行うように実装するのがよい」 となる. そうすれば,将来,インターネットの SMTP 構成が, 8-bitスルー になった場合でも互換性を保つ事ができる. 4. PGP 暗号化データ PGP にて暗号化を行う前に,データを MIME の正準な形式 (body と header)で整形しておかねばならない. 参考文献[1]で述べられている通り, PGP にて暗号化されたデータの Content-Type は "multipart/encrypted" と示される. これには,値 "application/pgp-encrypted" を持つ "protocol" パラメータが必要である(MUST). パラメータの値は引用符にて括らなくてはならない(MUST)ことに注意 せよ. multipart/encrypted は正確に2つのパートが必要(MUST)である. 最初のパートのMIMEボディの Content-Type は "application/pgp-encrypted" でなくてはならない. このボディ部は,制御情報からなる. 本標準を満たすためには,メッセージはボディ部に "Version: 1" フィールドを含まなくてはならない(MUST). PGP パケットは復号化に必要な情報を全て含んでいるので,このパー トに他の情報は必要無い. 第2の MIME ボディパートは,実際の暗号化データを含まなくてはな らない(MUST). Content-Type は "application/octet-stream" でなければならない. メッセージ例: 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署名データ 参考文献[1]で述べられている通り, PGP 署名メッセージは "multipart/signed" コンテントタイプで示され, 値 "application/pgp-signature" を持つ "protocol" パラメータが 必要(MUST)である. (引用符で括ることが必要(MUST)) "micalg" パラメータには "pgp-" が必要である(MUST). には,署名作成に使用するメッセージ完全性検査 (MIC) を指定する. 現在のところ の値としては MD5 チェックサムを指定 する "md5" と, SHA.1 アルゴリズムを指定する "sha1" が定義され ている. multipart/signed のボディは,正確に2つのパートで構成されなくて はならない(MUST). 最初のパートは適切なヘッダーを含む署名されたデータが MIME の正 準な形式に従い格納される. 第2のパートは,PGPデジタル署名を含んでいなければならない(MUST). またこのパートは"application/pgp-signature" コンテントタイプで なければならない(MUST). PGPデジタル署名を作る時には: (1) 署名されるデータはまずはじめに,その type/subtype に特有 の標準形に変換されなければならない. 例えば text/plain の場合では,適切な文字コードへ変換する ことと行末を正準の 列へ変換することを意味する. (2) 次に,適切な Content-Transfer-Encoding が適用される. エンコードされたデータの各々の行は正準の 列で終わっ ていなければならない(MUST). (3) さらに各々の行末を正準の 列にしながら, MIME コンテントヘッダ部がボディ部に追加される. (4) 参考文献[1]で述べられている通り,デジタル署名の計算は,署 名されるデータと,それに付加されるコンテントヘッダ一式に対 して行われなければならない(MUST). (5) 署名処理自身によって署名されたデータが改変される事が無いよ うに,署名は署名されるデータと分離して生成しなければならな い(MUST). メッセージ例: 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-- 例の中の"&"記号は,署名の計算に使われる部分を示す. 必須ではないが,最初のステップとしてデータを Quoted-Printable を用いてエンコードしておく (すなわち署名されるデータを正準の MIME 形式に従って出力しておく) 事は一般的によい方法である. もし,データの中に "From" ではじまる行があれば,その "F" をエ ンコードするように. この作業によってMTA が行頭に">" を挿入して署名データを無効にし てしまう事を防ぐ事ができる. 署名されたメッセージを受け取ったら,アプリケーションは,次のこ とをしなければならない(MUST) (1) 署名を検証する前に行末を正準の 列にする. これは MTA が行末をローカルシステムのコードに変換している 場合があるので必要である. (2) 署名されたデータと,関連するコンテントヘッダ(署名と一緒に) を合わせて署名の検証を行う. 6. 暗号化され,かつ署名されたデータ 送信すべきメッセージに電子署名を行い更に暗号化することが望まし い場合がある.本プロトコルではその為の2つの方法について考慮し ている. 6.1 RFC1847 カプセル化 参考文献[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-- (行頭に "&" 記号のある部分は,本当は暗号化されているが,説明の ためにテキストとして示している.) 6.2 同時方式 PGP 2.x では,署名と暗号化を一回の操作で同時に行うこともできる. この方法は受け入れられるべき手っ取り早い手段であり,負荷軽減効 果がある. 結果として生ずるデータは,上記で説明した multipart/encryptedi と して生成される. この同時方式で暗号化,および署名されたメッセージは,multipart/signed オブジェクトと同じ正規化規則に従わなくてはならない(REQUIRED). メールエージェントが,同時方式のメッセージを復号し,暗号化され て埋め込まれた署名を用いた multipart/signed オブジェクトとして 書き直すことは,明示的に許可されている. 7. PGP公開鍵の配布 Content-Type: application/pgp-keys Required parameters: none Optional parameters: none これは,公開鍵ブロックを伝達するための Content-Type である. 8. 注意 PGPとPretty Good Privacy は Philip Zimmermann の商標である. 9. セキュリティについての考察 本プロトコルを使用することにより, PGP と同等のセキュリティを 得られる. ただし,それによりメッセージのセキュリティが改善されるか改悪さ れるかは不明である. 詳細は参考文献[3]を参照のこと. 10. 著者連絡先 Michael Elkins P.O. Box 92957 - M1/102 Los Angeles, CA 90009-2957 Phone: +1 310 336 8040 Fax: +1 310 336 4402 10.1 訳者(順不同) 佐藤佳征 Satoh Yoshiyuki あるいは 瀬戸川教彦 SETOGAWA Michihiko 10.2 協力者(順不同) 小薮隆史 KOYABU, Takashi 塚本尚伸 Tsukamoto Takanobu 参考文献 [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.