[要約] RFC 4902は、SMTPのOPESにおける完全性、プライバシー、セキュリティに関する要件を定義しています。その目的は、OPESアーキテクチャにおいてSMTPトラフィックを保護するためのガイドラインを提供することです。
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
SMTPのオープンプラグ可能なエッジサービス（OPES）の整合性、プライバシー、セキュリティ
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）The IETF Trust（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.
Open Pluggable Edge Services（OPES）フレームワークは、アプリケーション不可知論です。アプリケーション固有の適応は、そのフレームワークを拡張します。以前の作業はHTTPに焦点を当てており、SMTPの作業が進行中です。これらのプロトコルは、データが流れる方法が根本的に異なり、既存のOPES要件とOPEのIABの考慮事項を、SMTP適応にどれだけ適しているかについてレビューする必要があることがわかります。このドキュメントは、OPESシステムによるSMTPおよびメールメッセージの適応の整合性と、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ユースケースのセクション3ドキュメント[6]は、このドキュメントで使用されているOPES名にいくつかの電子メールとSMTP要素をマッピングします。
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]におけるOpen Pluggable Edge Services（OPES）およびそれらの考慮事項のOPES治療に関する考慮事項をリストしました。どちらのドキュメントも、OPESフローの基礎となるプロトコルの例としてHTTPを使用し、クラシックフォームのリクエストと応答を持つWebプロトコルに焦点を当てています（クライアントは、クライアントが同じプロトコルの応答で応答するリクエストをサーバーに送信します。単一のプロトコルトランザクション）。
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を使用する場合、Stillクライアントおよびサーバーアプリケーションがあり、SMTP内で処理されるリクエストと応答がありますが、電子メールメッセージは、以前のリクエストなしでデータプロバイダーから受信者（データ消費者）に送信されます。その抽象化レイヤーでは、SMTP経由の電子メール配信は単方向プロセスであり、HTTPなどの以前に処理されたWebプロトコルとは異なります。たとえば、バイパスは、アプリケーションプロトコル要求に情報を追加することにより、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サーバーによって受け入れられた配信不可能なメールの発信者に送信する必要があります。しかし、SMTPの必須声明の違反であるNDRを送信せずに、ある種のメール（スパム、ワーム）が静かに削除されることが一般的な慣行となっています（[4]のセクション3.7を参照）。Webプロトコルのユーザーは、リソースを取得できない場合に気付きますが、電子メール送信者も電子メールの受信者も、電子メールが配信されていないことに気付くことはありません。これらの種類の問題はすでに存在し、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仕様[4]に従ってNDRをメールの発信者に送信する必要があります。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.
キーワードは「必要」、「必要」、「必須」、「shall」、「shall "、" sulld "、" nove "、" becommended "、" "、" 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システムにとって重要な要件です。電子メールに追加されたトレース情報は、オープンプラグ可能なエッジサービス[5]を使用して、HTTP適応でOPES/HTTPで定義されたものと同様の構文と構造に従う必要があります[5]、および「受信」ヘッダーに対して定義されたSMTP仕様[4]と同じガイドラインで。（ここでは、OPES情報を携帯するために「受信」ヘッダーが使用されるか、Opes-SystemやOpes-Viaなどの新しいトレースヘッダーを定義する必要があるかどうかは指定しません。）
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プロセッサは、最初のCallout Serverを呼び出す前に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では、OPES処理のために生成されたNDRが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トレース情報を使用してメールを受信した場合、メッセージの非OPEバージョンを受信したい場合があります。受信者からの直接的なインバンドリクエストは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システムは、バイパス、たとえばWebインターフェイスやサーバーに送信された電子メールメッセージなど、バイパスをリクエストする帯域外のメソッドを定義する場合があります。これらの帯域外の方法の例は、元の電子メールのコピーを検疫キューに保持し、受信者にブロック通知を送信する電子メールシステムに加えて、直接リンクまたはダイジェスト通知のいずれかで、元のものを取得する機能を備えたものです。検疫からのメッセージ。これらの帯域外の方法は、通常、今日のスパムフィルターによって提供されます。
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ダイアログ内に追加できます。メールメッセージに追加されたバイパス要求データは、メールメッセージが受信される前に送信される他のSMTPダイアログコマンド（RCPTコマンドなど）で動作する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システムはメッセージを変更することができず、主張された送信者から来るように見えるようにすることができました。送信者の署名キーを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ボックスにはデジタル署名アイデンティティとキーがあると仮定します）。これを行うための1つの方法は[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:
OPEの他のドキュメントのリスト要件に加えて、このドキュメントの議論は、OPEで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.
o OPESシステムによって受け入れられた電子メールメッセージを配信できない場合、非配信レポートには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.
このセクションには、OPES [2]の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サービスがアプリケーションレイヤーのエンドホストの1つ（つまり、データ消費者アプリケーションまたはデータプロバイダーアプリケーションのいずれか）によって明示的に承認されることを推奨しています。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プロセッサはOPES/ SMTPの電子メールゲートウェイです）。これにより、非複雑な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プロセッサをエンドユーザー（Data Consumer Application）によって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].
「全体的なOPESフレームワークは、コンテンツプロバイダーがコンテンツプロバイダーによって不適切とみなされるOPES仲介者によるクライアント中心のアクションの検出と対応を支援する必要があります」[2]。
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.
これはセクション3.1で対処されており、セクション4の2番目のトレース要件で説明されています。セクション1.3で説明したように、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.
これはセクション3.1で対処され、セクション4の最初のトレース要件で説明されています。一部の電子メールシステムでは、ヘッダーはSMTPを介して転送されるペイロードに属していますが、電子メールヘッダーをエンドユーザーに使用できないことに注意する必要があります。これらの電子メールシステムを使用して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アーキテクチャは、ユーザーがコンテンツプロバイダーからこの「非OPES」バージョンを取得できないようにしてはなりません」[2]。
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.
「urisを中心に展開するほとんどのアプリケーション層」（[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.
document内およびドキュメント内参照の妥当性に関する参照妥当性の考慮事項を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 additional privacy issues that MUST be added to the privacy policy description of the OPES system.
OPESのアプリケーションの不可知論的部分は、[3]のセクション10で説明されています。セクション4の要件に従ってOPES/SMTPに追加される電子メール固有のトレース情報は、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[2] Floyd、S。and L. Daigle、「Open Pluggable Edge Servicesの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。and A. Rousskov、「IABの考慮事項のオープンプラグ可能なエッジサービス（OPES）処理」、RFC 3914、2004年10月。
[4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[4] Klensin、J。、「Simple Mail Transfer Protocol」、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、「Open Pluggable Edge Services（OPES）によるHTTP適応」、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、「Open Pluggable Edge Services（OPES）SMTPユースケース」、RFC 4496、2006年5月。
[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.、Chen、R.、Hofmann、M。、およびH. Orman、「Open Pluggable Edge Services（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.、Srinivas、B.、Hofmann、M。、およびH. Orman、「Open Pluggable Edge Services（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] Elkins、M.、Del Torto、D.、Levien、R。、およびT. Roessler、「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] Eastlake、D.、Reagle、J。、およびD. Solo、「（拡張可能なマークアップ言語）XML-Signature構文と処理」、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] Orman、H。、「マイルドアクティブコンテンツのデータの整合性」、Active Middleware Servicesに関する第3回年次国際ワークショップの議事録、p.73、2001年8月。
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
Martin Stecher Secure Computing Corporation Vattmannnst。3 33100 Paderbornドイツ
EMail: martin.stecher@webwasher.com
URI: http://www.securecomputing.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。