[要約] RFC 2480は、ゲートウェイとMIMEセキュリティマルチパートに関する規格です。このRFCの目的は、MIMEメッセージのセキュリティを向上させるためのゲートウェイの機能とプロトコルを定義することです。
Network Working Group N. Freed
Request for Comments: 2480 Innosoft International, Inc.
Category: Standards Track January 1999
Gateways and MIME Security Multiparts
ゲートウェイと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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. A set of requirements for gateway behavior are defined which provide facilities necessary to properly accomodate the transfer of security multiparts through gateways.
このドキュメントでは、MIMEセキュリティマルチパートと非MIME環境へのゲートウェイの使用に関連する問題について説明します。ゲートウェイを介したセキュリティマルチパートの転送に適切に対応するために必要な機能を提供する、ゲートウェイの動作に関する一連の要件が定義されています。
This document occasionally uses terms that appear in capital letters. When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of the terms "MUST", "SHOULD", and "MAY" appears in RFC 1123 [2]; the terms "MUST NOT" and "SHOULD NOT" are logical extensions of this usage.
このドキュメントでは、大文字で表示される用語を使用することがあります。 「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、および「MAY」という用語は、大文字で表記されている場合、この仕様の特定の要件を示すために使用されています。 「MUST」、「SHOULD」、および「MAY」という用語の意味の説明は、RFC 1123 [2]に記載されています。 「MUST NOT」および「SHOULD NOT」という用語は、この使用法の論理的な拡張です。
Security multiparts [RFC-1847] provide an effective way to add integrity and confidentiality services to protocols that employ MIME objects [RFC-2045, RFC-2046]. Difficulties arise, however, in heterogeneous environments involving gateways to environments that don't support MIME. Specifically:
セキュリティマルチパート[RFC-1847]は、MIMEオブジェクトを使用するプロトコル[RFC-2045、RFC-2046]に完全性と機密性サービスを追加する効果的な方法を提供します。ただし、MIMEをサポートしない環境へのゲートウェイを含む異種環境では、問題が発生します。具体的には：
(1) Security services have to be applied to MIME objects in their entirety. Failure to do so can lead to security exposures.
（1）セキュリティサービスは、MIMEオブジェクト全体に適用する必要があります。そうしないと、セキュリティ上の問題が発生する可能性があります。
For example, a signature that covers only object data and not the object's MIME labels would allow someone to tamper with the labels in an undetectable fashion. Similarly, failure to encrypt MIME label information exposes information about the content that could facilitate traffic analysis.
たとえば、オブジェクトのMIMEラベルではなく、オブジェクトデータのみを対象とする署名では、誰かが検出できない方法でラベルを改ざんする可能性があります。同様に、MIMEラベル情報の暗号化に失敗すると、トラフィック分析を容易にするコンテンツに関する情報が公開されます。
Composite MIME objects (e.g., multipart/mixed, message/rfc822) also have to be secured as a unit. Again, failure to do so may facilitate tampering, reveal important information unnecessarily, or both.
複合MIMEオブジェクト（multipart / mixed、message / rfc822など）も、1つの単位として保護する必要があります。繰り返しますが、これを怠ると、改ざんを促進したり、重要な情報を不必要に明らかにしたりする可能性があります。
(2) Gateways that deal with MIME objects have to be able to convert them to non-MIME formats.
（2）MIMEオブジェクトを処理するゲートウェイは、それらを非MIME形式に変換できる必要があります。
For example, gateways often have to transform MIME labelling information into other forms. MIME type information may end up being expressed as a file extension or as an OID.
たとえば、ゲートウェイは多くの場合、MIMEラベル付け情報を他の形式に変換する必要があります。 MIMEタイプ情報は、ファイル拡張子またはOIDとして表現される場合があります。
Gateways also have to take apart composite MIME objects into their component parts, converting the resulting set of parts into whatever form the non-MIME environments uses for composite objects. Failure to do so makes the objects unusable in any environment that doesn't support MIME. In many cases this also means that multi-level MIME structures have to be converted into a sequential list of parts.
ゲートウェイはまた、複合MIMEオブジェクトをコンポーネントパーツに分解し、結果のパーツのセットを、非MIME環境が複合オブジェクトに使用する形式に変換する必要があります。そうしないと、MIMEをサポートしていない環境ではオブジェクトが使用できなくなります。多くの場合、これは、マルチレベルMIME構造をパーツの順次リストに変換する必要があることも意味します。
(3) Security services have to be deployed in an end-to-end fashion. Failure to do so again can lead to security exposures.
（3）セキュリティサービスは、エンドツーエンドの方法で展開する必要があります。再度これを行わないと、セキュリティ上の問題が発生する可能性があります。
An integrity service deployed at something other than a connection end point means a region exists between the point where the integrity service is applied and the actual end point where object tampering is possible. A confidentiality service deployed at something other than a connection end point means a region exists where the object is transferred in the clear. And worse, distributed private keys are usually necessary whenever someone other than the originator applies an integrity service or someone other than the recipient removes a confidentiality service, which in turn may make theft of private key information a possibility.
整合性サービスが接続エンドポイント以外の場所に配置されているということは、整合性サービスが適用されるポイントとオブジェクトの改ざんが可能な実際のエンドポイントの間に領域が存在することを意味します。接続エンドポイント以外の場所に配置された機密サービスは、オブジェクトがクリアテキストで転送される領域が存在することを意味します。さらに悪いことに、通常、発信者以外の誰かが整合性サービスを適用したり、受信者以外の誰かが機密性サービスを削除したりすると、秘密鍵情報の盗難の可能性があるため、分散秘密鍵が必要になります。
All of these issues can be addressed, of course. For example, it may be possible to use multiple overlapping security services to assure that no exposure exists even though there is no end-to-end security per se. And keys can be distributed in a secure fashion. However, such designs tend to be quite complex, and complexity in a security system is highly undesireable.
もちろん、これらの問題はすべて対処できます。たとえば、複数の重複するセキュリティサービスを使用して、エンドツーエンドのセキュリティ自体がなくてもエクスポージャーが存在しないようにすることができます。また、キーは安全な方法で配布できます。ただし、そのような設計は非常に複雑になる傾向があり、セキュリティシステムの複雑さは非常に望ましくありません。
The preceeding three requirments are fundamentally in conflict: It is possible to satisfy two of them at once, but not all three at once.
上記の3つの要件は根本的に矛盾しています。一度に2つを満たすことは可能ですが、3つすべてを同時に満たすことはできません。
In fact the conflict is even worse than it first appears. In most situations of this sort some sort of compromise is possible which, while not satisfying any of the requirements completely, does optimize some sort of average of all the requirements. Such a solution does not exist in this case, however, because many real world situations exist where any one of these requirements absolutely must be satisfied.
実際、紛争は最初に現れるよりもさらに深刻です。この種のほとんどの状況では、何らかの要件が完全に満たされていなくても、すべての要件のある種の平均を最適化する、何らかの妥協が可能です。ただし、このような解決策はありません。これらの要件のいずれか1つを完全に満たす必要がある実際の状況が多数存在するためです。
Since the previously described problem doesn't allow for a single solution the only viable approach is to require that gateways provide multiple solutions. In particular, gateways
前述の問題は単一のソリューションを許可しないため、唯一の実行可能なアプローチは、ゲートウェイが複数のソリューションを提供することを要求することです。特に、ゲートウェイ
(1) MUST provide the ability to tunnel multipart/signed and multipart/encrypted objects as monolithic entities if there is any chance whatsoever that MIME capabilities exist on the non-MIME side of the gateway. No changes to content of the multipart are permitted, even when the content is itself a composite MIME object.
（1）ゲートウェイの非MIME側にMIME機能が存在する可能性が少しでもある場合は、マルチパート/署名付きおよびマルチパート/暗号化オブジェクトをモノリシックエンティティとしてトンネルする機能を提供する必要があります。コンテンツ自体が複合MIMEオブジェクトである場合でも、マルチパートのコンテンツを変更することはできません。
This option must be provided so that entities behind the gateway that are capable of processing security multiparts and their MIME content will work properly. As mentioned previously, situations exist where application security requirements are absolute and must be accomodated, even when meeting them causes problems for other agents.
このオプションは、セキュリティマルチパートとそのMIMEコンテンツを処理できるゲートウェイの背後にあるエンティティが正しく機能するように提供する必要があります。前述のように、アプリケーションのセキュリティ要件が絶対的なものであり、それらの要件を満たすことが他のエージェントに問題を引き起こしたとしても対応する必要がある場合があります。
Exceptions are allowed only when there is no possibility of MIME support on one side of the gateway. For example, a gateway to a voice messaging system may have no useful way to represent a signed MIME object.
例外は、ゲートウェイの一方の側でMIMEサポートの可能性がない場合にのみ許可されます。たとえば、ボイスメッセージシステムへのゲートウェイには、署名されたMIMEオブジェクトを表す便利な方法がない場合があります。
(2) MUST provide the ability to take apart multipart/signed objects, exposing the content (and in the process ruining the signature). When this approach is selected, gateways SHOULD NOT remove the signature. Instead, gateways SHOULD keep the signature intact and add to it a note that it will probably be invalid for checking the message contents, but may still be contain valuable information about the sender.
（2）multipart / signedオブジェクトを分解してコンテンツを公開する機能を提供する必要があります（およびその過程で署名を台無しにします）。この方法を選択した場合、ゲートウェイは署名を削除してはなりません（SHOULD NOT）。代わりに、ゲートウェイは署名をそのまま保持し、メッセージの内容のチェックにはおそらく無効であるが、送信者に関する貴重な情報が含まれている可能性があることをメモに追加する必要があります（SHOULD）。
This option must be provided so that entities behind the gateway which are incapable of processing MIME will work properly.
このオプションは、MIMEを処理できないゲートウェイの背後にあるエンティティが正しく機能するように提供する必要があります。
(3) SHOULD provide the ability to select between the previous two options on per-user basis.
（3）ユーザーごとに前の2つのオプションから選択する機能を提供する必要があります。
(4) MAY provide facilities to check signatures and decrypt encrypted content. Such facilities MUST NOT be enabled by default; the potential security exposure involved has to be assessed before such capabilities can be used.
（4）署名をチェックし、暗号化されたコンテンツを復号化する機能を提供してもよい（MAY）。このような機能は、デフォルトで有効にしてはなりません（MUST NOT）。このような機能を使用する前に、潜在的なセキュリティ上の危険性を評価する必要があります。
(5) MAY provide facilities to sign and/or encrypt material passing from the non-MIME side to the MIME side of the gateway. Again, such facilities MUST NOT be enabled by default; the potential security exposure involved in the transfer of unsecured content within the application domain behind the gateway has to be assessed before such capabilities can be used.
（5）ゲートウェイの非MIME側からMIME側に渡されるマテリアルに署名および/または暗号化する機能を提供してもよい（MAY）。この場合も、このような機能はデフォルトで有効にしてはなりません（MUST NOT）。このような機能を使用する前に、ゲートウェイの背後にあるアプリケーションドメイン内のセキュリティで保護されていないコンテンツの転送に伴う潜在的なセキュリティの危険性を評価する必要があります。
A gateway which complies with the above requirements is considered to be security multiparts compliant.
上記の要件に準拠するゲートウェイは、セキュリティマルチパートに準拠していると見なされます。
This entire document is about security.
このドキュメント全体はセキュリティに関するものです。
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August, 1982.
[RFC-822] Crocker、D。、「Standard for the Format for ARPA Internet Text Messages」、STD 11、RFC 822、August、1982。
[RFC-1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[RFC-1847] Galvin、J.、Murphy、S.、Crocker、S.、N。Freed、「MIMEのセキュリティマルチパート：Multipart / SignedおよびMultipart / Encrypted」、RFC 1847、1995年10月。
[RFC-1123] Braden, R., Ed., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[RFC-1123] Braden、R。、編、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996.
[RFC-2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年12月。
[RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 1996.
[RFC-2046] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、1996年12月。
[RFC-2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, December 1996.
[RFC-2049] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part 5：Conformance Criteria and Examples」、RFC 2049、1996年12月。
Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA
Ned Freed Innosoft International、Inc. 1050 Lakes Drive West Covina、CA 91790 USA
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: ned.freed@innosoft.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。