Network Working Group M. Stecher
Request for Comments: 4902 Secure Computing
Category: Informational May 2007
Integrity, Privacy, and Security
in Open Pluggable Edge Services (OPES) for SMTP
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework. Previous work has focused on HTTP and work for SMTP is in progress. These protocols differ fundamentally in the way data flows, and it turns out that existing OPES requirements and IAB considerations for OPES need to be reviewed with regards to how well they fit for SMTP adaptation. This document analyzes aspects about the integrity of SMTP and mail message adaptation by OPES systems and about privacy and security issues when the OPES framework is adapted to SMTP. It also lists requirements that must be considered when creating the "SMTP adaptation with OPES" document.
オープンプラグイン可能なエッジ・サービス（OPES）フレームワークはアプリケーションに依存しないです。アプリケーション固有の適応は、そのフレームワークを拡張します。前の仕事は、SMTPのためのHTTPや仕事に焦点を当てている進行中です。これらのプロトコルは、データフローの方法で根本的に異なり、それがOPESのための既存のOPES要件とIABの考慮事項は、彼らがSMTP適応に収まるどれだけに関して検討する必要があること。判明しますこの文書では、SMTPの完全性とOPESシステムにより、メールメッセージの適応についてとOPESのフレームワークはSMTPに適応され、プライバシーとセキュリティの問題についての側面を分析します。また、文書「OPESとSMTPの適応」を作成する際に考慮しなければならない要件を示します。
The intent of this document is to capture this information before the current OPES working group shuts down. This is to provide input for subsequent working groups or individual contributors that may pick up the OPES/SMTP work at a later date.
このドキュメントの目的は、現在のOPESワーキンググループがシャットダウンする前に、この情報を収集することです。これは後日OPES / SMTPの作業を拾うことがあり、その後の作業グループまたは個々の貢献者のための入力を提供することです。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Differences between Unidirectional and
Bidirectional Application Protocols ........................3
1.2. Non-Standardized SMTP Adaptations at SMTP Gateways .........3
1.3. Non-OPES Issues of SMTP ....................................4
1.4. Opportunities of OPES/SMTP to Address Some Issues ..........4
1.5. Limitations of OPES in Regards to Fixing SMTP Issues .......4
2. Terminology .....................................................5
3. Integrity, Privacy, and Security Considerations .................5
3.1. Tracing Information in OPES/SMTP ...........................5
3.2. Bypass in OPES/SMTP ........................................6
3.3. Compatibility with Cryptographic Protection Mechanisms .....7
4. Protocol Requirements for OPES/SMTP .............................8
5. IAB Considerations for OPES/SMTP ................................9
5.1. IAB Consideration (2.1) One-Party Consent ..................9
5.2. IAB Consideration (2.2) IP-Layer Communications ............9
5.3. IAB Consideration (3.1) Notification .......................9
5.4. IAB Consideration (3.2) Notification ......................10
5.5. IAB Consideration (3.3) Non-Blocking ......................10
5.6. IAB Consideration Application Layer Addresses (4.x) .......10
5.7. IAB Consideration (5.1) Privacy ...........................10
5.8. IAB Consideration Encryption ..............................11
6. Security Considerations ........................................11
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
Appendix A. Acknowledgements ......................................13
Because OPES is a protocol that is built over application layer transports, its security may depend on the specifics of the transport. OPES designs are guided by the IAB considerations for OPES document [2], and those considerations are revisited here in the context of the SMTP protocol.
OPESは、アプリケーション層トランスポート上で構築されているプロトコルであるため、そのセキュリティは、トランスポートの仕様に依存してもよいです。 OPES設計はOPES文献[2]のためにIABを考慮して導かれ、そしてそれらの考察はSMTPプロトコルの文脈でここに再訪されます。
Section 3 of the OPES SMTP use cases document [6] maps some email and SMTP elements to OPES names that are used in this document.
OPES SMTPユースケースドキュメント[6]の第3章では、本書で使用されているOPES名に一部の電子メールおよびSMTPの要素をマッピングします。
1.1. Differences between Unidirectional and Bidirectional Application Protocols
1.1. 単方向および双方向アプリケーションプロトコルの違い
The IAB listed considerations for Open Pluggable Edge Services (OPES) in [2] and OPES treatment of those considerations has been discussed in [3]. Both documents make use of HTTP as an example for the underlying protocol in OPES flows, and focus on web protocols that have requests and responses in the classic form (client sends a request to a server that replies with a response of the same protocol within a single protocol transaction).
IAB [2]で開くプラグイン可能なエッジサービスのための考慮事項（OPES）を列挙し、これらの考慮事項のOPES処理[3]で議論されてきました。どちらの文書は、OPESフローの基本的なプロトコルの例として、HTTPを利用して、クライアントが同じプロトコル内の応答を返信するサーバにリクエストを送信する（古典的な形で要求と応答を持っているウェブプロトコルに焦点を当てます単一のプロトコルトランザクション）。
RFC 3914 [3] already indicates that other protocols may not fit in this context, for example in Section 5.3, "Moreover, some application protocols may not have explicit responses...".
RFC 3914 [3]は、既に他のプロトコルは、5.3節では、たとえば、このコンテキストでは収まらない可能性があることを示している「また、いくつかのアプリケーションプロトコルは、明示的な応答を持っていないかもしれません...」。
When using SMTP there are still client and server applications, and requests and responses handled within SMTP, but email messages are sent by the data provider to the recipients (data consumers) without a previous request. At that abstraction layer, email delivery via SMTP is a unidirectional process and different from the previously handled web protocols such as HTTP. For example, bypass has been defined for OPES, so far, by the data consumer requesting an OPES bypass by adding information to the application protocol request; the OPES system can then react on the bypass request in both the application request and response. For SMTP, the data consumer (email recipient) cannot request in-band that the OPES bypass handling of his/her messages.
SMTPを使用している場合があり、クライアントとサーバのアプリケーションが残っている、と要求と応答は、SMTP内で処理が、電子メールメッセージは、前の要求なしで受信者（データコンシューマ）にデータプロバイダーによって送信されます。その抽象化層では、SMTPを介して電子メールの配信は、一方向プロセスであり、HTTPなどの先に取り扱わウェブプロトコルとは異なります。例えば、バイパスは、アプリケーション・プロトコル要求に情報を追加することによって、OPESバイパスを要求するデータコンシューマによって、これまでのところ、OPESのために定義されています。 OPESシステムは、アプリケーションの要求と応答の両方でバイパス要求に反応することができます。 SMTPの場合、データコンシューマ（電子メールの受信者は）彼/彼女のメッセージのOPESバイパス処理することを帯域内で要求することはできません。
The IAB considerations need to be revisited and special requirements may be needed for OPES handling of SMTP.
IABの考慮事項が再考されると特別な要件は、SMTPのOPES処理に必要になることが必要です。
A large number of email filters are deployed at SMTP gateways today. In fact, all use cases listed in "OPES SMTP Use Cases" [6] are already deployed, often in non-standardized ways. This opens a number of integrity, privacy, and security concerns that are not addressed, and SMTP itself does not provide effective measures to detect and defend against compromised implementations.
メールフィルターの多数は、今日のSMTPゲートウェイで展開されています。実際には、「OPES SMTPユースケース」に記載されているすべてのユースケースは、[6]、すでに多くの場合、非標準化された方法で、配備されています。これは対処されていない整合性、プライバシー、セキュリティ上の懸念の数を開き、SMTP自体が検出し、妥協の実装を防御するための効果的な対策を提供していません。
OPES will most likely not be able to solve these issues completely, but at least should be able to improve the situation to some extent.
OPESは、ほとんど完全にこれらの問題を解決することはできませんが、少なくともある程度は状況を改善することができるはずです。
The SMTP specifications [4] require that NDRs (Non-Delivery Reports) be sent to the originator of an undeliverable mail that has been accepted by an SMTP server. But it has become common practice for some sorts of mail (spam, worms) to be silently dropped without sending an NDR, a violation of the MUST statement of SMTP (see Section 3.7 of [4]). While the user of a web protocol notices if a resource cannot be fetched, neither the email sender nor email recipient may notice that an email was not delivered. These kind of issues already exist and are not introduced by OPES.
SMTPの仕様は、[4]のNDR（配信不能レポート）がSMTPサーバーによって承認された不達メールの発信者に送信する必要があります。しかし、それは静かに、NDRを送信せずにSMTPのMUST文の違反をドロップするために、メール（スパム、ワーム）のいくつかの種類のために一般的になってきている（[4]のセクション3.7を参照）。ウェブプロトコル通知のユーザーがリソースをフェッチすることができない場合が、電子メールの送信者や電子メールの受信者のいずれも電子メールが配信されなかったことに気づくことがあります。問題のこれらの種類は、すでに存在しており、OPESによって導入されていません。
Adding SMTP adaptations with OPES allows us to define a standardized way for SMTP gateway filtering, to offload filtering services to callout servers and address a number of the integrity, privacy, and security issues. OPES offers methods to add OPES tracing information and to request a bypass of filtering, and by that can make email gateway filtering a more reliable and standardized function. But OPES won't make email delivery via SMTP a reliable communication.
OPESとSMTPの適応を追加すると、私たちは、SMTPゲートウェイ・フィルタリングのための標準化された方法を定義するためにコールアウトサーバにフィルタリングサービスをオフロードすることと整合性の数、プライバシー、およびセキュリティ上の問題に対処することができます。 OPESは、より信頼性と標準化された機能をフィルタリングメールゲートウェイを作ることができますOPESトレース情報を追加するとフィルタリングのバイパスを要求し、そのことにより、メソッドを提供しています。しかし、OPESは、SMTP信頼性の高い通信を経由してメール配信をすることはありません。
The biggest concerns when adding OPES services to a network flow are that compromised, misconfigured, or faulty OPES systems may change messages in a way that the consumer can no longer read them or that messages are no longer delivered at all.
最大の懸念ネットワークフローにOPESサービスを追加する妥協、誤って設定、または故障しOPESシステムは、消費者は、もはやそれらを読むことができないことや、メッセージがもはやまったく配信されているような方法でメッセージを変更することがあります。
Defining a standard way to mark mails that have been handled by OPES systems is fairly simple and does not require new techniques by SMTP gateways; they already today MUST leave tracing information by adding "Received" headers to mails. Therefore, recipients receiving broken mail have a fair chance of finding the compromised OPES system by using the trace information. There is still no guarantee, as the email may have been broken in a way that makes even the tracing information unreadable. But the chance will be even better than with other protocols such as HTTP, because most email clients allow the user to display mail headers, while many browsers have no mechanism to show the HTTP headers that might include tracing info.
OPESシステムによって処理されているメールをマークするための標準的な方法を定義することは非常に簡単ですし、SMTPゲートウェイによって、新たな技術を必要としません。彼らはすでに、今日はメールに「受信」ヘッダを追加することにより、トレース情報を残しておく必要があります。そのため、壊れたメールを受信する受信者は、トレース情報を使用して妥協OPESシステムを見つけるの公平な機会を持っています。電子メールでもトレース情報が読めなくなりますように壊れている可能として保証は、まだありません。ほとんどの電子メールクライアントは、多くのブラウザでは、トレース情報が含まれる可能性があるHTTPヘッダを表示するメカニズムを持っていない一方で、ユーザは、メールヘッダを表示することができますので、しかし、チャンスは、HTTPなどの他のプロトコルと比べてさらに良くなります。
Email that cannot be delivered, because a compromised OPES system prevented the delivery of legitimate mail, MUST result in a an NDR to be sent to the originator of the mail according to the SMTP specifications [4]. OPES should not be forced to fix the issue that NDRs are not reliable over SMTP.
妥協OPESシステムは、正当なメールの配信を防止するため、配信できないメールは、SMTP仕様に従ってメールの発信者に送信されるNDRをもたらさなければなりません[4]。 OPESは、NDRのは、SMTPを介して信頼できないという問題を修正することを強制すべきではありません。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. When used with the normative meanings, these keywords will be all uppercase. Occurrences of these words in lowercase comprise normal prose usage, with no normative implications.
キーワード "MUST"、 "MUST NOT"、 "REQUIRED" は、 "NOT SHALL" "ものと" この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" はにあります[1]で説明されるように解釈されます。規範的な意味で使用する場合、これらのキーワードは、すべて大文字になります。小文字でこれらの単語の出現は、無規範的な意味で、通常の散文の使用を含みます。
Tracing OPES operations is an important requirement for OPES systems. Tracing information added to email should follow a similar syntax and structure to that defined for OPES/HTTP in HTTP Adaptation with Open Pluggable Edge Services [5], and with the same guidelines as the SMTP specifications [4] defined for the "Received" headers. (We do not specify here whether "Received" headers would be used to carry the OPES information, or new trace headers should be defined, such as OPES-System and OPES-Via.)
OPES操作をトレースするとOPESシステムのための重要な要件です。電子メールに付加された情報を追跡する[4]「受信」ヘッダーに定義された[5]、およびSMTPの仕様と同じガイドラインに開くプラグイン可能なエッジサービスとHTTP適応にOPES / HTTPのために定義されたものと同様の構文および構造に従うべきです。 （私たちは、「受信」ヘッダがOPES情報を運ぶために使用される、または新しいトレースヘッダは、このようなOPES-システムとOPESビアとして、定義されるべきかどうか、ここで指定しないでください。）
OPES/SMTP specifications defining tracing requirements MUST be compliant with the general OPES tracing requirements defined in OPES Entities & End Points Communication [12], but MAY further restrict those. For example, they might require the following: that the OPES processor must add tracing information for the OPES system before calling the first callout server; that it has to augment the tracing information with additional data if necessary after the message returns from each service it is calling; and that it must ensure that the tracing information has not been deleted by an OPES service before it forwards the SMTP message.
トレース要件の定義OPES / SMTPの仕様は、OPESエンティティとエンドポイント通信[12]で定義された要件を追跡する一般的なOPESに準拠する必要がありますが、さらにそれらを制限することができます。例えば、彼らは次のよう必要な場合があります：OPESプロセッサは最初のコールアウトサーバを呼び出す前に、OPESシステムのトレース情報を追加しなければならないことを。メッセージは、それが呼び出している各サービスから戻った後は、必要に応じて追加のデータとトレース情報を増強しなければならないこと。そしてそれはSMTPメッセージを転送する前に、トレース情報は、OPESサービスによって削除されていないことを確認しなければならないこと。
Trace information can then be seen by mail recipients when the mail message reaches the recipient.
メールメッセージが受信者に到達したときにトレース情報は、メールの受信者が見ることができます。
Mail that cannot be delivered or that is blocked by the OPES service will either be rejected or cannot be delivered after it has been accepted by an SMTP server. In the latter case, SMTP specifications [4] require that an NDR MUST be sent to the originator; OPES further requires that an NDR generated due to OPES processing MUST also contain information about the OPES system so that the sender gets informed. If an email is rejected at the SMTP protocol level due to OPES processing, an OPES system MUST also include trace data in the SMTP response so that the originator can find out why and where the mail was rejected.
配信できないか、それはOPESサービスによってブロックされたメールは拒否されるか、それはSMTPサーバーによって承認された後にお届けすることができません。後者の場合、SMTP仕様[4] NDRが発信者に送信されなければならないことを必要とします。さらにOPESは、NDRが送信者に通知されますように、また、OPESシステムに関する情報を含まなければならないため、OPES処理に生成されている必要があります。電子メールはOPES処理によるSMTPプロトコルレベルで拒否された場合、発信者は、なぜ、どこでメールが拒否された見つけることができるように、OPESシステムは、SMTP応答のトレースデータを含まなければなりません。
If a mail message was rejected or could not be delivered (and an NDR was sent), the originator of the message may want to bypass the OPES system that blocked the message.
メールメッセージが拒否されたか、配信することができませんでした（とNDRが送信された）場合は、メッセージの発信者はメッセージをブロックしOPESシステムをバイパスすることもできます。
If the recipient of a message receives a mail with OPES trace information, he may want to receive a non-OPES version of the message. Although there is no direct in-band request from the recipient back to the OPES system, the recipient can contact the sender and ask her to send the message again and to add a bypass request for the OPES system. Not all OPES systems will be allowed to fulfill a bypass request according to their policy. For example, malware scanners should not be bypassed. But other OPES services are good candidates for bypass requests, such as language translation of the email message. Translation could be bypassed after the recipient has noticed that the translated result does not meet his/her expectations and that the original message would be preferred.
メッセージの受信者がOPESトレース情報でメールを受信した場合、彼はメッセージの非OPESバージョンを受信したいことがあります。バックOPESシステムへの受信者からの直接のインバンド要求はありませんが、受信者は送信者に連絡して、再度メッセージを送信するとOPESシステム用のバイパス要求を追加するために彼女を求めることができます。すべてのOPESのシステムは、そのポリシーに従ってバイパス要求を満たすために許可されるわけではありません。たとえば、マルウェアスキャナーをバイパスするべきではありません。しかし、他のOPESサービスは、電子メールメッセージの言語翻訳などのバイパス要求のための良好な候補です。翻訳は、受信者が、翻訳結果が彼/彼女の期待を満たしていないことに気づいた後にバイパスすることができ、元のメッセージが好ましいであろうということ。
An OPES system MAY also define out-of-band methods to request a bypass, for example, a web interface or an email message sent to the server that results in the creation of a white list entry for the sender/recipient pair. Examples for these out-of-band methods are email systems that keep a copy of the original email in a quarantine queue and only send the recipient a block notification, plus either a direct link or a digest notification, with the ability to retrieve the original message from quarantine. These out-of-band methods are typically offered by spam filters today.
OPESシステムは、バイパス、例えば、ウェブインターフェースまたは送信者/受信者ペアのホワイトリストエントリの生成をもたらすサーバに送信された電子メールメッセージを要求するために、アウトオブバンド方法を定義してもよい（MAY）。これらのアウトオブバンド方法の例は、元を検索する能力と、直接リンクまたはダイジェスト通知のいずれかを隔離キューに元の電子メールのコピーを保持し、受信者だけにブロック通知を送信する、プラスの電子メールシステムです検疫からのメッセージ。これらのアウトオブバンドの方法は、典型的には今日のスパムフィルタによって提供されています。
OPES MUST implement methods to request a bypass, but there cannot be a guarantee that the bypass request will be approved. The security needs of the receiver or the receiver's network may demand that certain filters must not be bypassed (such as virus scanners). In general, the receiver should be able to configure a client centric OPES system, i.e. the receiver should be able to indicate if he/she wants to receive a non-OPES version if it is available.
OPESは、バイパスを要求するためのメソッドを実装する必要がありますが、バイパス要求が承認される保証はすることはできません。受信機または受信機のネットワークのセキュリティニーズは、特定のフィルタが（例えばウイルススキャナのような）をバイパスしてはならないことを要求することができます。一般に、受信機は、すなわち、受信機は、彼/彼女は、それが利用可能な場合非OPESのバージョンを受け取りたいかどうかを示すことができる必要があり、クライアント中心のOPESシステムを構成することができるはずです。
Bypass requests could be added to the mail message or within the SMTP dialog. Bypass request data added to the mail message cannot bypass OPES services that operate on other SMTP dialog commands, which are sent before the mail message has been received (such as RCPT commands).
バイパス要求は、メールメッセージまたはSMTPダイアログの中に追加することができます。メールメッセージに追加バイパス要求データは、（RCPTコマンドのような）電子メールメッセージが受信される前に送信され、他のSMTPダイアログコマンド、上で動作するOPESサービスをバイパスすることができません。
Bypass request data sent using an ESMTP extension as part of the SMTP dialog may not reach the OPES system if intermediate SMTP relays do not support those bypass request commands and don't forward that information.
中間SMTPリレーは、これらのバイパス要求コマンドをサポートしていないと、その情報を転送しない場合は、SMTPダイアログの一部としてESMTPの拡張機能を使用して送信されたバイパス要求データは、OPESシステムに達していなくてもよいです。
Cryptography can be used to assure message privacy, to authenticate the originator of messages, and to detect message modification. There are standard methods for achieving some or all these protections for generic messages ([9], [10], [11]), and these can be used to protect SMTP data without changing the SMTP protocol.
暗号化は、メッセージのプライバシーを確保するために、メッセージの発信元を認証するために、メッセージの変更を検出するために使用することができます。標準のいくつかを達成するための方法または汎用メッセージに対するすべてのこれらの保護がある（[9]、[10]、[11]）、及びこれらのSMTPプロトコルを変更せずにSMTPデータを保護するために使用することができます。
The content of encrypted mail messages cannot be inspected by OPES systems because only the intended recipient has the information necessary for decryption. The IAB and others have suggested that users might want to share that information with OPES systems, thus permitting decryption by intermediates. For most cryptographic systems that are compatible with email, this would require end users to share their most valuable keys, in essence their "identities", with OPES machines. Some key management systems, particularly those which have centralized administrative control of keys, might have trust models in which such sharing would be sensible and secure.
対象とする受信者だけが復号化に必要な情報を持っているので、暗号化されたメールメッセージの内容は、OPESシステムによって検査することができません。 IABなどは、このような中間体で復号化を許可する、ユーザーがOPESシステムとその情報を共有したいと思うかもしれないことを示唆しています。電子メールと互換性のあるほとんどの暗号システムでは、これはOPESマシンと本質的には、彼らの「アイデンティティ」を、彼らの最も貴重な鍵を共有するために、エンドユーザーが必要となります。いくつかの鍵管理システムは、特にキーの中央集中管理制御を有するものは、そのような共有が賢明かつ安全であると思われるに信頼モデルを持っているかもしれません。
After decrypting the message, an OPES box that modified the content would be faced with the task of re-encrypting it in order to maintain some semblance of "end-to-end" privacy.
メッセージを復号化した後、内容を修正OPESボックスは、「エンド・ツー・エンドの」プライバシーのいくつかのうわべだけを維持するためにそれを再暗号化の課題に直面することでしょう。
If OPES/SMTP had a way to interact with end users on a per-message basis, it might be possible to communicate cryptographic key information from individual messages to end users, have them compute the message encrypting key for particular message, and to send that back to the OPES box. This would perhaps ameliorate the need to share a user's "master" message decrypting key with the OPES box. This kind of communication has not been defined for OPES.
OPES / SMTPは、メッセージごとに、エンドユーザーと対話するための方法を持っていた場合、彼らが特定のメッセージのための鍵を暗号化メッセージを計算しており、それを送信するために、エンドユーザに個々のメッセージから暗号鍵情報を伝達することができるかもしれませんバックOPESボックスへ。これはおそらく、OPESボックスを持つユーザーの「マスター」のメッセージの復号鍵を共有する必要性を改善するでしょう。通信のこの種は、OPESのために定義されていません。
Message protection systems generally include some message integrity mechanisms by which a recipient can check for a message modification that may have occurred after the sender released the message. This protection can be applied to encrypted or plaintext messages and can be accomplished through either symmetric or asymmetric cryptography. In the case of symmetric cryptography, the key sharing problem is exactly similar to the encryption case discussed previously. If the OPES box modified the content, then the message integrity (or authentication) code would have to be recalculated and included with the modified message.
メッセージ保護システムは、一般的に、受信者が送信者がメッセージをリリースした後に発生した可能性があるメッセージの変更を確認することができるいくつかのメッセージの完全性機構を含みます。この保護は、暗号化またはプレーンテキストメッセージに適用することができ、いずれかの対称または非対称暗号方式により達成することができます。対称暗号化の場合は、鍵共有の問題は、前述した暗号化の場合とまったく同じです。 OPESボックスがコンテンツを変更した場合、メッセージの完全性（または認証）コードが変更されたメッセージを用いて再計算し、含まなければなりません。
For asymmetric cryptography the situation is more complicated. The message integrity is tied to the sender's public key, and although anyone who can get the sender's public key can also check for a message modification, no one but the sender can compute the sender's signature on a modified message. Thus, an OPES system could not modify messages and have them appear to come from the purported sender. The notion of sharing the sender's signing key with the OPES system is unpalatable because few trust models would be compatible with sharing digital identities across organization boundaries. However, if the OPES system doing the modification were under the control of the sender's local administration, the sharing might be sensible (as discussed for decryption, above).
非対称暗号の場合、状況はより複雑です。メッセージの完全性は、送信者の公開鍵に縛られ、送信者の公開鍵を取得することができ、誰もが、メッセージの変更を確認することができますが、誰が、送信者が変更されたメッセージに送信者の署名を計算することはできません。このように、OPESシステムは、メッセージを変更し、それらを主張送信者から来るように表示されていませんでした。いくつかの信頼モデルは、組織の境界を越えてデジタルIDを共有しているとの互換性になるのでOPESシステムで、送信者の署名鍵を共有するという概念は不愉快です。修正を行ってOPESシステムは、送信者の地方行政の制御下にあった場合は、共有が（上記、復号化のために説明したように）賢明かもしれません。
OPES/SMTP systems could present modified content showing the modified regions in a form that permits the authentication of the original message and authentication of the OPES modifications (assuming the OPES box had a digital signature identity and key). One method for doing this is outlined in [13], but to our knowledge this method is not in any standard.
OPES / SMTPシステムは、（OPESボックスはデジタル署名アイデンティティ及びキーを持っていたと仮定して）OPES修飾の元のメッセージおよび認証の認証を可能にする形で変更された領域を示す修正されたコンテンツを提示することができました。これを行うための一つの方法は、[13]に概説されますが、私たちの知る限り、この方法は、任意の標準ではありません。
There are security risks associated with sharing cryptographic keys that must be addressed by implementers. Because this is not a simple task, it is not a requirement for OPES/SMTP.
実装によって対処されなければならない暗号鍵を共有することに関連するセキュリティ上のリスクがあります。これは単純な作業ではありませんので、それはOPES / SMTPの要件ではありません。
In addition to other documents listing requirements for OPES, the discussion in this document implies specific requirements for designing and implementing SMTP adaptations with OPES:
OPESのための要件をリストアップし、他の書類に加えて、この文書の議論は、OPESとSMTPの適応を設計および実装するための特定の要件を意味します：
o OPES Systems MUST add tracing headers to mail messages
O OPESシステムは、メッセージをメールにトレースヘッダを追加しなければなりません
o If an email message that has been accepted by an OPES system cannot be delivered, the non-delivery report MUST include trace information of the OPES system.
OPESシステムによって受理された電子メールメッセージを配信できない場合は、O、配信不能レポートは、OPESシステムのトレース情報を含まなければなりません。
o The OPES/SMTP specifications MUST define a bypass request option that can be included in mail messages.
O OPES / SMTPの仕様は、メールメッセージに含めることができるバイパス要求オプションを定義しなければなりません。
o The OPES/SMTP specifications MUST define a bypass request option as an extension for SMTP dialogs.
O OPES / SMTP仕様は、SMTPダイアログの拡張としてのバイパス要求オプションを定義しなければなりません。
This section lists the IAB considerations for OPES [2] and summarizes how OPES/SMTP addresses them.
このセクションでは、[2] OPESのためのIAB考慮事項をリストし、OPES / SMTPは、それらを解決する方法を要約しています。
The IAB recommends that all OPES services be explicitly authorized by one of the application-layer end-hosts (that is, either the data consumer application or the data provider application). For OPES/ SMTP, this means consent of either the email message sender or the recipient.
IABは、すべてのOPESサービスが明示的にアプリケーション層のエンドホストの一つ（すなわち、データ・コンシューマ・アプリケーションまたはデータ・プロバイダ・アプリケーションのいずれか）によって認可されることをお勧めします。 OPES / SMTPの場合、これは、電子メールメッセージの送信者または受信者のいずれかの同意を意味しています。
The application agnostic architecture of OPES [7] requires that "OPES processors MUST be consented to by either the data consumer or data provider application" (OPES processor is the email gateway for OPES/ SMTP). This cannot prevent the consent-less introduction of OPES processors by noncompliant OPES entities.
OPESのアプリケーションにとらわれないアーキテクチャ[7]（OPESプロセッサはOPES / SMTPのメールゲートウェイである）「OPESプロセッサは、データコンシューマまたはデータ・プロバイダ・アプリケーションのいずれかによってに同意しなければならない」ことを必要とします。これは、非準拠OPESエンティティによってOPESプロセッサの同意レス導入を防ぐことはできません。
The IAB recommends that OPES processors must be explicitly addressed at the IP layer by the end user (data consumer application).
IABは、OPESプロセッサが明示的にエンドユーザー（データ・コンシューマ・アプリケーション）によってIPレイヤで対処しなければならないことをお勧めします。
This requirement has been addressed by the architecture requirements in Section 2.1 of [7] and has been further clarified in Section 2.2 of [3].
この要件は、[7]のセクション2.1にアーキテクチャの要件によって対処されており、さらに、[3]のセクション2.2で明らかにされています。
"The overall OPES framework needs to assist content providers in detecting and responding to client-centric actions by OPES intermediaries that are deemed inappropriate by the content provider" [2].
[2]「全体OPESフレームワークは、検出およびコンテンツプロバイダによって不適切と見なされるOPES仲介によるクライアント中心のアクションに応答して、コンテンツプロバイダを支援する必要があります」。
For OPES/SMTP this translates into assistance for the email message sender to detect and respond to recipient-centric actions that are deemed inappropriate by the sender.
OPES / SMTPの場合、これを検出し、送信者が不適切と判断され、受信者中心のアクションに応答する電子メールメッセージの送信者の支援につながります。
This has been addressed in Section 3.1 and by the second tracing requirements in Section 4. As discussed in Section 1.3, OPES/SMTP cannot fix cases where NDRs are not sent or get blocked before reaching the sender of the original message.
セクション1.3で説明したようにこれは、3.1節にし、第4節第二のトレースの要件によって対処されてきた、OPES / SMTPは、NDRのが送信されないか、元のメッセージの送信者に到達する前にブロックされます例を修正することはできません。
"The overall OPES framework should assist end users in detecting the behavior of OPES intermediaries, potentially allowing them to identify imperfect or compromised intermediaries" [2].
「全体的なOPESフレームワークは、OPES仲介の挙動を検出することで、エンドユーザーを支援する可能性それらが不完全または損なわ仲介者を識別することを可能にするべきである」[2]。
This is addressed in Section 3.1 and by the first tracing requirement in Section 4. It must be noted that some email systems do not make the email headers available to the end user, although the headers belong to the payload that is transferred via SMTP. Building an OPES architecture with those email systems should be avoided or requires that the tracing information be made available to the end users in a different way.
ヘッダはSMTPを介して転送されるペイロードに属しているが、これは、3.1節でそしていくつかの電子メールシステムは、エンドユーザーへの電子メールのヘッダを利用可能にしていないことに注意しなければならない第4の最初のトレースの要件によって対処されます。これらの電子メールシステムとOPESアーキテクチャを構築することは避けるか、トレース情報が異なる方法でエンドユーザーに利用可能になることを要求しなければなりません。
"If there exists a "non-OPES" version of content available from the content provider, the OPES architecture must not prevent users from retrieving this "non-OPES" version from the content provider" [2].
非OPES「が存在する場合、 『[2]『コンテンツプロバイダからバージョン』非OPES』コンテンツプロバイダから利用可能なコンテンツのバージョンが、OPESアーキテクチャは、これを取得することからユーザーを妨げてはなりません」。
For OPES/SMTP, this has been discussed in Section 3.2 and is addressed by the two bypass requirements of Section 4.
OPES / SMTPのために、これはセクション3.2で議論されており、第4の2つのバイパス要件によって対処されます。
While "most application layer addressing revolves around URIs" (section 8 of [2]), SMTP uses email addresses, for which the considerations only apply to some degree.
「URIを中心に展開に対処するほとんどのアプリケーション層」（[2]のセクション8）が、SMTPを考慮のみある程度適用される電子メールアドレスを使用します。
The SMTP use cases document [6] includes a use case for Mail Rerouting and Address Rewriting. Alias and email list address resolution are standard functions of an email gateway described in [4].
SMTPのユースケース文書[6]メール再ルーティングおよびアドレス書き換えのためのユースケースを含みます。エイリアスとメールリストアドレス解決[4]に記載のメールゲートウェイの標準機能です。
Translating the reference validity consideration regarding inter- and intra-document reference validity to SMTP, OPES services mapping internal to external email addresses MUST ensure the proper mapping of addresses in all affected email headers.
外部の電子メールアドレスへの内部SMTPの間および文書内の参照妥当性に関する参考妥当性検討、OPESサービスマッピングを翻訳すると、すべての感染した電子メールのヘッダ内のアドレスの適切なマッピングを確保しなければなりません。
This consideration recommends that the overall OPES framework must provide for mechanisms for end users to determine the privacy policies that were used by OPES intermediaries.
この考慮事項は、全体的なOPESフレームワークは、OPESの仲介で使用されたプライバシーポリシーを決定するために、エンドユーザーのためのメカニズムを提供しなければならないことをお勧めします。
The application agnostic part for OPES has been discussed in Section 10 of [3]. Email-specific trace information that will be added to OPES/SMTP according to the requirements in Section 4 may raise
OPES用アプリケーションにとらわれない部分は、[3]のセクション10で議論されてきました。上げることができる第4節では要件に応じてOPES / SMTPに追加されますメールに固有のトレース情報
additional privacy issues that MUST be added to the privacy policy description of the OPES system.
OPESシステムのプライバシーポリシーの記述に追加する必要があり、追加のプライバシーの問題。
"If OPES was compatible with end-to-end encryption, this would effectively ensure that OPES boxes would be restricted to ones that are known, trusted, explicitly addressed at the IP layer, and authorized (by the provision of decryption keys) by at least one of the ends" [2].
「OPESは、エンドツーエンドの暗号化に対応していた場合、これは事実でで（復号鍵を提供することによって）OPESボックスが、知られているものに限定され信頼され、明示的にIP層で対処し、かつ認可されることを確実にします端部の少なくとも1つの」[2]。
This has been discussed in Section 3.3.
これは、3.3節で議論されてきました。
The document itself discusses security considerations of OPES/SMTP. General security threats of OPES are described in Security Threats for OPES [8]
文書自体は、OPES / SMTPのセキュリティの考慮事項について説明します。 OPESの一般的なセキュリティ上の脅威は、OPESのためのセキュリティの脅威に記述されている[8]
Section 3.3 ("Compatibility with Cryptographic Protection Mechanisms") mentions that an OPES system could eventually deal with cryptographic keys. This raises security issues (such as availability and storage of cryptographic keys) that must be addressed by the implementer.
3.3節（「暗号保護機構との互換性」）OPESシステムは、最終的に暗号鍵を扱うことができることを言及しています。これは、実装によって対処しなければならない（例えば、暗号鍵の可用性やストレージなど）のセキュリティ問題を提起します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[2]フロイド、S.とL. Daigle氏、 "オープン・プラグイン可能なエッジサービスのためのIAB建築・ポリシーに関する注意事項"、RFC 3238、2002年1月。
[3] Barbir, A. and A. Rousskov, "Open Pluggable Edge Services (OPES) Treatment of IAB Considerations", RFC 3914, October 2004.
[3] Barbir、A.とA. Rousskov、 "IABの考慮事項のオープンプラグイン可能なエッジ・サービス（OPES）治療"、RFC 3914、2004年10月。
[4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[4] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[5] Rousskov, A. and M. Stecher, "HTTP Adaptation with Open Pluggable Edge Services (OPES)", RFC 4236, November 2005.
[5] Rousskov、A.およびM. Stecherを、 "HTTP適応オープンプラグイン可能なエッジサービス（OPES）と"、RFC 4236、2005年11月。
[6] Stecher, M. and A. Barbir, "Open Pluggable Edge Services (OPES) SMTP Use Cases", RFC 4496, May 2006.
[6] Stecher、M.とA. Barbirは、RFC 4496、2006年5月 "プラグイン可能なエッジサービス（OPES）SMTPのユースケースを開きます"。
[7] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, August 2004.
[7] Barbir、A.、Penno、R.、陳、R.、ホフマン、M.、およびH.オーマン、 "オープン・プラグイン可能なエッジサービスのためのアーキテクチャ（OPES）"、RFC 3835、2004年8月。
[8] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H. Orman, "Security Threats and Risks for Open Pluggable Edge Services (OPES)", RFC 3837, August 2004.
[8] Barbir、A.、Batuner、O.、スリニバス、B.、ホフマン、M.、およびH.オーマン、 "オープン・プラグイン可能なエッジサービスのセキュリティ脅威とリスク（OPES）"、RFC 3837、2004年8月。
[9] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[9]エルキンズ、M.、デルTorto、D.、Levien、R.、およびT.レスラー、 "OpenPGPのとMIMEセキュリティ"、RFC 3156、2001年8月。
[10] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[10] Housley氏、R.、 "暗号メッセージ構文（CMS）"、RFC 3852、2004年7月。
[11] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[11]イーストレーク、D.、Reagle、J.、およびD.ソロ "（拡張マークアップ言語）、XML署名の構文および処理"、RFC 3275、2002年3月。
[12] Barbir, A., "Open Pluggable Edge Services (OPES) Entities and End Points Communication", RFC 3897, September 2004.
[12] Barbir、A.、 "オープンプラグイン可能なエッジサービス（OPES）エンティティとエンドポイントのコミュニケーション"、RFC 3897、2004年9月。
[13] Orman, H., "Data Integrity for Mildly Active Content", Proceedings of the Third Annual International Workshop on Active Middleware Services, p.73, August 2001.
[13]オーマン、H.、「データ整合弱アクティブコンテンツのための」アクティブミドルウェアサービス、P.73、2001年8月に第3回国際ワークショップの議事録。
Appendix A. Acknowledgements
付録A.謝辞
Many thanks to everybody who provided input and feedback for this document. Very special thanks to Hilarie Orman for her input and suggestions, especially for the content of Section 3.3 ("Compatibility with Cryptographic Protection Mechanisms").
このドキュメントのための入力とフィードバックを提供し、みんなに感謝します。特に3.3節の内容のための彼女の入力や提案のためのヒラリーオーマンに非常に特別な感謝、（「暗号保護メカニズムとの互換性」）。
Author's Address
著者のアドレス
Martin Stecher Secure Computing Corporation Vattmannstr. 3 33100 Paderborn Germany
マーティンStecherは、コンピューティング株式会社Vattmannstrを固定します。 3 33100パーダーボルン、ドイツ
EMail: martin.stecher@webwasher.com URI: http://www.securecomputing.com/
電子メール：martin.stecher@webwasher.com URI：http://www.securecomputing.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。