RFC4902 日本語訳

Network Working Group                                         M. Stecher
Request for Comments: 4902                              Secure Computing
Category: Informational                                         May 2007

コメントを求めるワーキンググループM.ステッチャーの要求をネットワークでつないでください: 4902年の安全なコンピューティングカテゴリ: 情報の2007年5月

                   Integrity, Privacy, and Security
            in Open Pluggable Edge Services (OPES) for SMTP

SMTPのための開いているPluggable縁のサービス(作品)における保全、プライバシー、およびセキュリティ

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).

IETFが信じる著作権(C)(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.

オープンPluggable Edge Services(作品)フレームワークはアプリケーション不可知論者です。 アプリケーション特有の適合はそのフレームワークを広げています。 前の仕事はHTTPに焦点を合わせました、そして、SMTPのための仕事は進行しています。 これらのプロトコルは基本的にデータが流れて、作品のための既存の作品要件とIAB問題が、あいさつでそれらがSMTP適合のためにどれくらいよく合うかに見直される必要であると判明する方法で異なります。 作品フレームワークがSMTPに適合させられるとき、このドキュメントは作品システムによるSMTPとメール・メッセージ適合の保全の周りと、そして、プライバシーと安全保障問題の周りに関して局面を分析します。 また、それは「作品との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.

このドキュメントの意図は現在の作品ワーキンググループが閉鎖する前にこの情報を得ることです。 これは、より後日作品/SMTP仕事を再開するかもしれないその後のワーキンググループか個々の貢献者のための入力を提供するためのものです。

Stecher                      Informational                      [Page 1]

RFC 4902                   OPES/SMTP Security                   May 2007

[1ページ]RFC4902作品/SMTPセキュリティ2007年5月の情報のステッチャー

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

1. 序論…3 1.1. 単方向、双方向のアプリケーション・プロトコルの違い…3 1.2. SMTPゲートウェイでの非標準化されたSMTP適合…3 1.3. SMTPの非作品問題…4 1.4. いくつかの問題を扱う作品/SMTPの機会…4 1.5. SMTPに問題を固定することに関する作品の制限…4 2. 用語…5 3. 保全、プライバシー、およびセキュリティ問題…5 3.1. 作品/SMTPの情報をたどります…5 3.2. 作品/SMTPでは、迂回します。6 3.3. 暗号の保護メカニズムとの互換性…7 4. 作品/SMTPのための要件について議定書の中で述べてください…8 5. 作品/SMTPのためのIAB問題…9 5.1. (2.1) IABの考慮の1パーティの同意…9 5.2. IAB考慮(2.2)IP-層のコミュニケーション…9 5.3. IAB考慮(3.1)通知…9 5.4. IAB考慮(3.2)通知…10 5.5. IAB考慮(3.3)非ブロッキング…10 5.6. IAB考慮応用層は(4.x)を扱います…10 5.7. IAB考慮(5.1)プライバシー…10 5.8. IAB考慮暗号化…11 6. セキュリティ問題…11 7. 参照…11 7.1. 標準の参照…11 7.2. 有益な参照…11 付録A.承認…13

Stecher                      Informational                      [Page 2]

RFC 4902                   OPES/SMTP Security                   May 2007

[2ページ]RFC4902作品/SMTPセキュリティ2007年5月の情報のステッチャー

1.  Introduction

1. 序論

   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.

作品が応用層輸送の上で築き上げられるプロトコルであるので、セキュリティは輸送の詳細によるかもしれません。 作品デザインは作品ドキュメント[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.

セクション3 ケースが記録するOPES SMTP使用では、[6]は何らかのメールと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]のオープンPluggable Edge Services(作品)のために問題を記載しました、そして、[3]でそれらの問題の作品処理について議論しました。 両方のドキュメントは、作品の基本的なプロトコルのための例が流れるとき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...".

RFC3914[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などの以前に扱われたウェブプロトコルと、単方向のプロセスであって異なっています。 例えば、迂回は作品のために定義されました、今までのところ、アプリケーション・プロトコル要求に情報を追加することによって作品迂回を要求するデータ消費者で。 そして、作品システムはアプリケーション要求と応答の両方で迂回要求に影響できます。 SMTPに関しては、データ消費者(メール受取人)は、バンドで作品がその人のメッセージの取り扱いを迂回させるよう要求できません。

   The IAB considerations need to be revisited and special requirements
   may be needed for OPES handling of SMTP.

IAB問題は、再訪する必要があります、そして、特別な要件がSMTPの作品取り扱いに必要であるかもしれません。

1.2.  Non-Standardized SMTP Adaptations at SMTP Gateways

1.2. SMTPゲートウェイでの非標準化されたSMTP適合

   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

多くのメールフィルタが今日、SMTPゲートウェイで配布されます。 事実上、しばしば非標準化された道における「OPES SMTPはケースを使用する」という[6]に記載されたケースが既に配布されるすべての使用。 これはそうしない多くの保全、プライバシー、および安全上の配慮を開きます。

Stecher                      Informational                      [Page 3]

RFC 4902                   OPES/SMTP Security                   May 2007

[3ページ]RFC4902作品/SMTPセキュリティ2007年5月の情報のステッチャー

   addressed, and SMTP itself does not provide effective measures to
   detect and defend against compromised implementations.

扱う、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.

作品は、たぶん完全にこれらの問題を解決できるというわけではありませんが、少なくともある程度状況を改善できるべきです。

1.3.  Non-OPES Issues of SMTP

1.3. SMTPの非作品問題

   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]が、NDRs(非配送Reports)が. それが数種類の静かにNDR、a違反を送らないで下げられるべきメール(スパム、ワーム)のために常套手段となったSMTPサーバーによって受け入れられた「非-提出物」メールの創始者に送られるのを必要とする、SMTPの声明、([4])のセクション3.7を見なければならなくなってください。 プロトコル通知は、リソースをとって来ることができないで、どちらもメール送付者でなく、メールが受取人であるならウェブのユーザである間、メールが提供されなかったのに気付くかもしれません。 これらの種類の問題は、既に存在していて、作品によって紹介されません。

1.4.  Opportunities of OPES/SMTP to Address Some Issues

1.4. 作品/SMTPがいくつかの問題を扱う機会

   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.

作品とのSMTP適合を加えるのに、私たちは、calloutサーバに対するフィルタリングサービスを積み下ろすためにSMTPゲートウェイフィルタリングのための標準化された方法を定義して、多くの保全、プライバシー、および安全保障問題を扱います。 作品は、情報をたどりながら作品を加えて、フィルタリングの迂回を要求するメソッドを提供して、それでメールをより信頼できて標準化された機能をフィルターにかけるゲートウェイにすることができます。 しかし、作品はSMTPを通したメール配送を信頼できるコミュニケーションにしないでしょう。

1.5.  Limitations of OPES in Regards to Fixing SMTP Issues

1.5. 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.

ネットワーク流動に対する作品サービスがそんなに感染されると言い足すときの最も大きい関心、misconfiguredされたか、不完全な作品システムは消費者がもうそれらを読むことができないか、またはメッセージがもう全く提供されない方法でメッセージを変えるかもしれません。

   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.

作品システムによって扱われたメールにマークする標準の方法を定義するのは、かなり簡単であり、SMTPゲートウェイのそばで新しいやり方を必要としません。 彼らは今日、既に加えるのによる情報が「受けた」たどるのにメールへのヘッダーを置き去りにしなければなりません。 したがって、壊れているメールを受け取る受取人がトレース情報を使用することによって感染している作品システムを見つけるという十分な機会を持っています。 保証が全くまだありません、メールが追跡情報さえ読みにくくする方法で壊れているとき。 しかし、見込みはHTTPなどの他のプロトコルよりさらに良くなるでしょう、ほとんどのメールクライアントがユーザにメールヘッダを表示させるので、多くのブラウザには、インフォメーションをたどるのを含むかもしれないHTTPヘッダを示しているメカニズムが全くありませんが。

Stecher                      Informational                      [Page 4]

RFC 4902                   OPES/SMTP Security                   May 2007

[4ページ]RFC4902作品/SMTPセキュリティ2007年5月の情報のステッチャー

   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.

感染している作品システムが正統のメールの配送を防いだので提供できないメールは、SMTP仕様[4]通りにメールの創始者に送るためにNDRに結果として生じなければなりません。 作品はやむを得ず、SMTPの上で信頼できた状態でNDRsがそうでない問題を修理するべきではありません。

2.  Terminology

2. 用語

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[1]で説明されるように本書では解釈されることであるべきですか? 標準の意味と共に使用されると、これらのキーワードはすべて大文字するようになるでしょう。 コネが小文字で印刷するこれらの単語の発生は標準の含意なしで正常な散文用法を包括します。

3.  Integrity, Privacy, and Security Considerations

3. 保全、プライバシー、およびセキュリティ問題

3.1.  Tracing Information in OPES/SMTP

3.1. 作品/SMTPの追跡情報

   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.)

作品操作をたどるのは、作品システムのための重要な要件です。メールするために加えられた追跡情報はHTTP Adaptationの作品/HTTPのためにオープンPluggable Edge Services[5]、および「受け取られていている」ヘッダーのために定義されたSMTP仕様[4]と同じガイドラインで定義されたそれに同様の構文と構造に従うべきです。 を通してそして、(私たちが、ここで「受け取られていている」ヘッダーが作品情報を運ぶのに使用されるかどうか指定しないか、または新しい跡のヘッダーは定義されるべきです、作品システムなどのように作品、-、)。

   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.

追跡要件を定義する作品/SMTP仕様は、一般的な作品追跡要件が作品Entities&End Points Communication[12]で定義されている状態で言いなりにならなければなりませんが、さらにそれらを制限するかもしれません。 例えば、彼らは以下を必要とするかもしれません: 最初のcalloutサーバを呼ぶ前に、作品プロセッサは作品システムのための追跡情報を加えなければなりません。 必要なら、それぞれからのメッセージリターンがそれを調整した後に追加データで追跡情報を増大させなければならないのは呼んでいます。 そして、それは、SMTPメッセージを転送する前に追跡情報が作品サービスで削除されていないのを確実にしなければなりません。

   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

それがSMTPサーバーによって受け入れられた後に、提供できないか、または作品サービスで妨げられるメールは、拒絶できないか、提供できません。後者の場合では、SMTP仕様[4]は、NDR MUSTが創始者に送られるのを必要とします。 作品は、また、作品処理のため生成されたNDRが作品システムの情報を含まなければならないので送付者が得るのをさらに必要とします。

Stecher                      Informational                      [Page 5]

RFC 4902                   OPES/SMTP Security                   May 2007

[5ページ]RFC4902作品/SMTPセキュリティ2007年5月の情報のステッチャー

   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.

知識がある。 また、作品処理のため、メールがSMTPプロトコルレベルで拒絶されるなら、作品システムは、創始者が、メールがなぜ、どこで拒絶されたかを見つけることができるように、SMTP応答にトレースデータを含まなければなりません。

3.2.  Bypass in OPES/SMTP

3.2. 作品/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を送りました)、メッセージの創始者はメッセージを妨げた作品システムを迂回させたがっているかもしれません。

   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.

メッセージの受取人が作品トレース情報で郵便を受け取るなら、彼はメッセージの非作品バージョンを受けたがっているかもしれません。 バンドにおけるどんなダイレクト受取人から作品システムまでの要求もありませんが、受取人は、送付者に連絡して、再びメッセージを送って、作品システムを求める迂回要求を加えるように彼女に頼むことができます。 それらの方針によると、すべての作品システムが迂回要求を実現させることができるというわけではないでしょう。 例えば、マルウェアスキャナは迂回するべきではありません。 しかし、他の作品サービスはメールメッセージに関する言語翻訳などの迂回要求の良い候補です。 受取人が、翻訳された結果がその人の期待に合わないで、オリジナルのメッセージが好まれるのに気付いた後に翻訳は迂回できました。

   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 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.

作品は迂回を要求するメソッドを実装しなければなりませんが、迂回が承認されるよう要求する保証があるはずがありません。 フィルタを迂回させてはいけないのを確信していた状態で(ウイルス・スキャナーなどの)、受信機か受信機のネットワークの安全要求はそれを要求するかもしれません。 一般に、受信機がクライアントの中心の作品システムを構成するはずであることができる、すなわち、受信機はそれが利用可能であるならその人が非作品バージョンを受けたがっているかどうかを示すはずであることができます。

   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コマンドなどの)を作動させる作品サービスを迂回させることができません。

Stecher                      Informational                      [Page 6]

RFC 4902                   OPES/SMTP Security                   May 2007

[6ページ]RFC4902作品/SMTPセキュリティ2007年5月の情報のステッチャー

   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拡張子が使用させられる要求データを迂回させてください。

3.3.  Compatibility with Cryptographic Protection Mechanisms

3.3. 暗号の保護メカニズムとの互換性

   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.

意図している受取人だけが情報を復号化に必要にするので、作品システムは暗号化メールメッセージの内容を点検できません。 IABと他のものは、ユーザが作品システムとその情報を共有したがっているかもしれないことを提案しました、その結果、中間介在物は復号化を可能にします。 ほとんどのメールと互換性がある暗号のシステムのために、これは、エンドユーザが彼らの最も貴重なキー、本質におけるそれらの「アイデンティティ」を共有するのを必要とするでしょう、作品マシンで。 いくつかのかぎ管理システム(特にキーの運営管理コントロールを集結したもの)には、そのような共有が分別があって安全である信頼モデルがあるかもしれません。

   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.

メッセージを解読した後に、内容を変更した作品箱は「終わりから終わり」プライバシーの何らかの類似を維持するためにそれを再暗号化するタスクに直面しているでしょう。

   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.

個々のメッセージからエンドユーザまで暗号化キー情報を伝えるのは作品/SMTPに相互作用する方法があったなら1メッセージあたり1個のベースのエンドユーザが彼らに特定のメッセージ、作品箱にそれを送り返すために主要なメッセージ暗号化を計算させるのが可能であるかもしれません。 これは恐らくユーザの作品箱によって主要な「マスター」メッセージの解読することを共有する必要性を改善するでしょう。 この種類に関するコミュニケーションは作品のために定義されていません。

   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.

一般に、メッセージ保護システムは受取人が送付者がメッセージを発表した後に起こったかもしれないメッセージ変更がないかどうかチェックできるいくつかのメッセージの保全メカニズムを含んでいます。 この保護を暗号化されるか平文メッセージに適用できて、どちらの左右対称の、または、非対称の暗号を通しても実行できます。 左右対称の暗号の場合では、主要な共有問題はまさに以前に議論した暗号化ケースと同様です。 作品箱が内容を変更するなら、メッセージの保全(または、認証)コードは、変更されたメッセージで再計算されて、含まれなければならないでしょうに。

Stecher                      Informational                      [Page 7]

RFC 4902                   OPES/SMTP Security                   May 2007

[7ページ]RFC4902作品/SMTPセキュリティ2007年5月の情報のステッチャー

   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/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.

作品/SMTPシステムはそれがオリジナルのメッセージの認証と作品変更の認証を可能にするのを(作品箱を仮定するのにおいて、デジタル署名のアイデンティティとキーがありました)フォームの変更された領域に案内する変更された内容を提示するかもしれません。 これをするための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.

implementersが扱わなければならない暗号化キーを共有すると関連しているセキュリティリスクがあります。 これが簡単な仕事でないので、それは作品/SMTPのための要件ではありません。

4.  Protocol Requirements for OPES/SMTP

4. 作品/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:

作品のための他のドキュメント上場要件に加えて、議論は本書では設計と作品との適合をSMTPに実装するための決められた一定の要求を含意します:

   o  OPES Systems MUST add tracing headers to mail messages

o 作品Systemsは、メッセージを郵送するために追跡ヘッダーを加えなければなりません。

   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 作品システムによって受け入れられたメールメッセージを提供できないなら、非配送レポートは作品システムに関するトレース情報を含まなければなりません。

   o  The OPES/SMTP specifications MUST define a bypass request option
      that can be included in mail messages.

o 作品/SMTP仕様はメール・メッセージに含むことができる迂回要求オプションを定義しなければなりません。

   o  The OPES/SMTP specifications MUST define a bypass request option
      as an extension for SMTP dialogs.

o 作品/SMTP仕様は迂回要求オプションをSMTP対話のための拡大と定義しなければなりません。

Stecher                      Informational                      [Page 8]

RFC 4902                   OPES/SMTP Security                   May 2007

[8ページ]RFC4902作品/SMTPセキュリティ2007年5月の情報のステッチャー

5.  IAB Considerations for OPES/SMTP

5. 作品/SMTPのためのIAB問題

   This section lists the IAB considerations for OPES [2] and summarizes
   how OPES/SMTP addresses them.

このセクションは、作品[2]のためにIAB問題を記載して、作品/SMTPがどうそれらを扱うかをまとめます。

5.1.  IAB Consideration (2.1) One-Party Consent

5.1. (2.1) IABの考慮の1パーティの同意

   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は、すべての作品サービスが応用層終わりホスト(すなわち、データ消費者アプリケーションか情報提供業者アプリケーションのどちらか)のひとりによって明らかに認可されることを勧めます。 作品/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.

作品[7]のアプリケーション不可知論者アーキテクチャが、「データ消費者か情報提供業者アプリケーションで作品プロセッサを承諾しなければなりません。」が必要です(作品プロセッサは作品/SMTPのためのメールゲートウェイです)。 これは不従順な作品実体で作品プロセッサの同意なしの導入を防ぐことができません。

5.2.  IAB Consideration (2.2) IP-Layer Communications

5.2. IAB考慮(2.2)IP-層のコミュニケーション

   The IAB recommends that OPES processors must be explicitly addressed
   at the IP layer by the end user (data consumer application).

IABは、エンドユーザ(データ消費者アプリケーション)が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でさらにはっきりさせられました。

5.3.  IAB Consideration (3.1) Notification

5.3. IAB考慮(3.1)通知

   "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]。

   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.

作品/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で議論するように、作品/SMTPはNDRsが送られないケースを修理できないか、オリジナルのメッセージの送付者に届く前に、妨げることができません。

Stecher                      Informational                      [Page 9]

RFC 4902                   OPES/SMTP Security                   May 2007

[9ページ]RFC4902作品/SMTPセキュリティ2007年5月の情報のステッチャー

5.4.  IAB Consideration (3.2) Notification

5.4. IAB考慮(3.2)通知

   "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].

「総合的な作品フレームワークは作品仲介者の振舞いを検出するのにエンドユーザを助けるべきです、彼らが不完全であるか感染している仲介者を特定するのを潜在的に許容して」[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を通して移されるペイロードに属しますが。 それらのメールシステムで作品アーキテクチャを築き上げるのは、避けられるべきであるか、または追跡情報をエンドユーザには異なった方法で利用可能にするのを必要とします。

5.5.  IAB Consideration (3.3) Non-Blocking

5.5. IAB考慮(3.3)非ブロッキング

   "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].

「コンテンツプロバイダーから利用可能な内容の「非作品」バージョンが存在しているなら、作品アーキテクチャによって、ユーザはコンテンツプロバイダーからこの「非作品」バージョンを検索してはいけないことができない」[2]。

   For OPES/SMTP, this has been discussed in Section 3.2 and is
   addressed by the two bypass requirements of Section 4.

作品/SMTPに関しては、これは、セクション3.2で議論して、セクション4の2つの迂回要件によって扱われます。

5.6.  IAB Consideration Application Layer Addresses (4.x)

5.6. IAB考慮応用層アドレス(4.x)

   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はEメールアドレスを使用します、問題がある程度当てはまるだけであるもののために。

   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は使用がメールReroutingとAddress Rewritingのためにケースに入れるケースドキュメント[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へのイントラドキュメント参照の正当性、外部のEメールアドレスへの内部の作品サービスマッピングはすべてのアドレスの適切なマッピングがメールヘッダーに影響したのを確実にしなければなりません。

5.7.  IAB Consideration (5.1) Privacy

5.7. IAB考慮(5.1)プライバシー

   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.

この考慮は、エンドユーザが作品仲介者によって使用されたプライバシーに関する方針を決定するように総合的な作品フレームワークがメカニズムに備えなければならないことを勧めます。

   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

[3]のセクション10で作品のためのアプリケーション不可知論者部分について議論しました。 セクション4における要件に従ったSMTPが提起するかもしれない作品/に追加されるメール特有のトレース情報

Stecher                      Informational                     [Page 10]

RFC 4902                   OPES/SMTP Security                   May 2007

[10ページ]RFC4902作品/SMTPセキュリティ2007年5月の情報のステッチャー

   additional privacy issues that MUST be added to the privacy policy
   description of the OPES system.

作品システムのプライバシーに関する方針記述に加えなければならない追加プライバシーの問題。

5.8.  IAB Consideration Encryption

5.8. IAB考慮暗号化

   "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].

「作品は終端間暗号化と互換性があるなら、事実上、これは、作品箱が少なくとも終わりの1つまでに知られて、信じられて、IP層で明らかに扱われて、認可される(復号化キーの設備で)ものに制限されるのを確実にする」という[2]。

   This has been discussed in Section 3.3.

セクション3.3でこれについて議論しました。

6.  Security Considerations

6. セキュリティ問題

   The document itself discusses security considerations of OPES/SMTP.
   General security threats of OPES are described in Security Threats
   for OPES [8]

ドキュメント自体は作品/SMTPのセキュリティ問題について議論します。 作品の総合証券の脅威は作品のためにSecurity Threatsで説明されます。[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(「暗号の保護メカニズムとの互換性」)は、作品システムが結局暗号化キーに対処するかもしれないと言及します。 これはimplementerが記述しなければならない安全保障問題(暗号化キーの有用性や格納などの)を提起します。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [2]   Floyd, S. and L. Daigle, "IAB Architectural and Policy
         Considerations for Open Pluggable Edge Services", RFC 3238,
         January 2002.

[2] フロイドとS.とL.Daigle、「開いているPluggable縁のサービスのためのIAB建築するのと方針問題」、RFC3238、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問題の開いているPluggable縁のサービス(作品)処理」、RFC3914、2004年10月。

7.2.  Informative References

7.2. 有益な参照

   [4]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
         2001.

[4]Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。

   [5]   Rousskov, A. and M. Stecher, "HTTP Adaptation with Open
         Pluggable Edge Services (OPES)", RFC 4236, November 2005.

[5]RousskovとA.とM.ステッチャー、「開いているPluggable縁のサービス(作品)とのHTTP適合」、RFC4236、2005年11月。

Stecher                      Informational                     [Page 11]

RFC 4902                   OPES/SMTP Security                   May 2007

[11ページ]RFC4902作品/SMTPセキュリティ2007年5月の情報のステッチャー

   [6]   Stecher, M. and A. Barbir, "Open Pluggable Edge Services (OPES)
         SMTP Use Cases", RFC 4496, May 2006.

[6]のステッチャー、M.、およびA.Barbir(「開いているPluggable縁のサービス(作品)SMTPはケースを使用する」RFC4496)は2006がそうするかもしれません。

   [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.、ペンノ、R.、チェン、R.、ホフマン、M.、およびH.Orman、「開いているPluggable縁のサービスのための構造(作品)」、RFC3835(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.、ホフマン、M.、およびH.Orman、「開いているPluggableのための軍事的脅威とリスクはサービス(作品)を斜めに進みます」、RFC3837、2004年8月。

   [9]   Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME
         Security with OpenPGP", RFC 3156, August 2001.

2001年8月の[9] エルキンズとM.とデルTortoとD.とレヴィエン、R.とT.Roessler、「OpenPGPがあるMIMEセキュリティ」RFC3156。

   [10]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
         July 2004.

[10]Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、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-署名構文と処理」(RFC3275)は2002を行進させます。

   [12]  Barbir, A., "Open Pluggable Edge Services (OPES) Entities and
         End Points Communication", RFC 3897, September 2004.

[12]Barbir、A.、「Pluggable縁のサービス(作品)実体とエンドポイントコミュニケーションを開いてください」、RFC3897、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の上のThird Annualの国際Workshop、p.73(2001年8月)のProceedings。

Stecher                      Informational                     [Page 12]

RFC 4902                   OPES/SMTP Security                   May 2007

[12ページ]RFC4902作品/SMTPセキュリティ2007年5月の情報のステッチャー

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").

入力とフィードバックをこのドキュメントに供給したみんなをありがとうございます。 Hilarie Ormanのおかげで彼女の入力と提案と、特にセクション3.3(「暗号の保護メカニズムとの互換性」)の内容に非常に特別です。

Author's Address

作者のアドレス

   Martin Stecher
   Secure Computing Corporation
   Vattmannstr. 3
   33100 Paderborn
   Germany

マーチン・ステッチャーSecureのコンピューティング社のVattmannstr。 3 33100パーテルボルンドイツ

   EMail: martin.stecher@webwasher.com
   URI:   http://www.securecomputing.com/

メール: martin.stecher@webwasher.com ユリ: http://www.securecomputing.com/

Stecher                      Informational                     [Page 13]

RFC 4902                   OPES/SMTP Security                   May 2007

[13ページ]RFC4902作品/SMTPセキュリティ2007年5月の情報のステッチャー

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Stecher                      Informational                     [Page 14]

ステッチャーInformationalです。[14ページ]