Network Working Group D. Eastlake 3rd
Request for Comments: 3930 Motorola Laboratories
Category: Informational October 2004
The Protocol versus Document Points of View in Computer Protocols
コンピュータのプロトコルでの表示のプロトコル文書対ポイント
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 Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document contrasts two points of view: the "document" point of view, where digital objects of interest are like pieces of paper written and viewed by people, and the "protocol" point of view where objects of interest are composite dynamic network messages. Although each point of view has a place, adherence to a document point of view can be damaging to protocol design. By understanding both points of view, conflicts between them may be clarified and reduced.
ビューの「文書」のポイント、関心のデジタルオブジェクトは関心のオブジェクトは複合動的なネットワークメッセージいる人々によって書かれたとみ紙の破片、およびビューの「プロトコル」のポイントのようなものです：この文書では、ビューの2点を対比しています。図の各点は場所を有しているが、ビューの文書のポイントへの付着は、プロトコル設計に損傷を与えることができます。ビューの両方のポイントを理解することによって、それらの間の対立が明確にして低減することができます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Points of View . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. The Basic Points of View . . . . . . . . . . . . . . . . 3
2.2. Questions of Meaning . . . . . . . . . . . . . . . . . . 3
2.2.1. Core Meaning . . . . . . . . . . . . . . . . . . 3
2.2.2. Adjunct Meaning. . . . . . . . . . . . . . . . . 4
2.3. Processing Models. . . . . . . . . . . . . . . . . . . . 5
2.3.1. Amount of Processing . . . . . . . . . . . . . . 5
2.3.2. Granularity of Processing. . . . . . . . . . . . 5
2.3.3. Extensibility of Processing. . . . . . . . . . . 6
2.4. Security and Canonicalization. . . . . . . . . . . . . . 6
2.4.1. Canonicalization . . . . . . . . . . . . . . . . 6
2.4.2. Digital Authentication . . . . . . . . . . . . . 8
2.4.3. Canonicalization and Digital Authentication. . . 8
2.4.4. Encryption . . . . . . . . . . . . . . . . . . . 9
2.5. Unique Internal Labels . . . . . . . . . . . . . . . . . 10
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Resolution of the Points of View . . . . . . . . . . . . . . . 11
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
Informative References . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 15
This document contrasts: the "document" point of view, where digital objects of interest are thought of as pieces of paper written and viewed by people, and the "protocol" point of view, where objects of interest are composite dynamic network messages. Those accustomed to one point of view frequently have great difficulty appreciating the other: Even after they understand it, they almost always start by considering things from their accustomed point of view, assume that most of the universe of interest is best viewed from their perspective, and commonly slip back into thinking about things entirely from that point of view. Although each point of view has a place, adherence to a document point of view can be damaging to protocol design. By understanding both points of view, conflicts between them may be clarified and reduced.
この文書では、対照的関心のデジタルオブジェクトは関心のオブジェクトは複合動的なネットワークメッセージいる人々によって書かれたとみ紙、およびビューの「プロトコル」の点の作品として考えられているビューの「ドキュメント」のポイントを、。ビューの一点に慣れ人々はしばしば大きな困難他に感謝を持っている：、彼らはそれを理解した後でも、彼らはほとんど常に、ビューの彼らの慣れポイントから物事を考えることから始め関心の宇宙のほとんどが彼らの視点から最高視聴されていることを前提としそして、一般的にその観点から完全に物事を考えるに逆戻り。図の各点は場所を有しているが、ビューの文書のポイントへの付着は、プロトコル設計に損傷を与えることができます。ビューの両方のポイントを理解することによって、それらの間の対立が明確にして低減することができます。
Much of the IETF's traditional work has concerned low level binary protocol constructs. These are almost always viewed from the protocol point of view. But as higher level application constructs and syntaxes are involved in the IETF and other standards processes, difficulties can arise due to participants who have the document point of view. These two different points of view defined and explored in section 2 below.
IETFの伝統的な作業の多くは、低レベルのバイナリプロトコルの構造を懸念しています。これらは、ほとんど常にビューのプロトコル・ポイントから見ています。より高いレベルのアプリケーションの構築物および構文は、IETFやその他の標準プロセスに関与しているとしてではなく、困難が伴うビューの文書のポイントを持っている参加者に発生することができます。以下のセクション2で定義され、探求ビューのこれらの異なる2点。
Section 3 gives some examples. Section 4 tries to synthesize the views and give general design advice in areas that can reasonably be viewed either way.
第3節では、いくつかの例を示します。第4節では、ビューを合成し、合理的にいずれかの方法を見たことができる分野で一般的な設計の助言を与えることをしようとします。
The following subsections contrast the document and protocol points of view. Each viewpoint is EXAGGERATED for effect.
以下のサブセクションでは、ビューの文書およびプロトコル点を対比します。それぞれの視点は、効果のために誇張されています。
The document point of view is indicated in paragraphs headed "DOCUM", and the protocol point of view is indicated in paragraphs headed "PROTO".
ビューの文書ポイントは「DOCUM」頭の段落に示され、ビューのプロトコルポイントは「PROTO」を頭の段落に示されています。
DOCUM: What is important are complete (digital) documents, analogous to pieces of paper, viewed by people. A major concern is to be able to present such documents as directly as possible to a court or other third party. Because what is presented to the person is all that is important, anything that can effect this, such as a "style sheet" [CSS], MUST be considered part of the document. Sometimes it is forgotten that the "document" originates in a computer, may travel over, be processed in, and be stored in computer systems, and is viewed on a computer, and that such operations may involve transcoding, enveloping, or data reconstruction.
DOCUM：重要なことは、人々が見た紙片に類似の完全な（デジタル）文書、です。主な関心事は、裁判所やその他の第三者に直接として可能な限りそのような文書を提示することができることです。何人に提示されると、すべてのことが重要ですので、そのような「スタイルシート」[CSS]、としてこれを、もたらすことができるものは、文書の一部とみなされなければなりません。時には「文書」は、コンピュータに由来することを忘れている、で処理され、コンピュータシステムに格納され、コンピュータで表示されており、このような操作は、トランスコーディング、エンベロープ、またはデータの再構築を伴うことがあること、以上移動することができます。
PROTO: What is important are bits on the wire generated and consumed by well-defined computer protocol processes. No person ever sees the full messages as such; it is only viewed as a whole by geeks when debugging, and even then they only see some translated visible form. If one actually ever has to demonstrate something about such a message in a court or to a third party, there isn't any way to avoid having computer experts interpret it. Sometimes it is forgotten that pieces of such messages may end up being included in or influencing data displayed to a person.
PROTO：重要なことは、明確に定義されたコンピュータのプロトコルプロセスによって生成され、消費ワイヤ上のビットです。何人も、これまでのような完全なメッセージを見ません。デバッグ時だけのオタクによって、全体として見て、その場合でも、彼らは唯一のいくつかの翻訳された目に見える形を参照してください。 1は、実際にこれまで法廷で第三者にそのようなメッセージについて何かを証明する必要がある場合、コンピュータの専門家はそれを解釈されないようにする方法はありません。時にはこのようなメッセージの部分は人に表示されたデータに影響を与えるか含まれて終わることが忘れられています。
The document and protocol points of view have radically different concepts of the "meaning" of data. The document oriented tend to consider "meaning" to a human reader extremely important, but this is something the protocol oriented rarely think about at all.
ビューの文書とプロトコルのポイントは、データの「意味」の根本的に異なる概念を持っています。指向文書は、非常に重要な人間の読者に「意味」を検討する傾向があるが、これはほとんど重視しないプロトコルはすべてで考えるものです。
This difference in point of view extends beyond the core meaning to the meaning of addenda to data. Both core and addenda meaning are discussed below.
視点の違いは、データへの添加物の意味に意味コアを越えて延びています。どちらのコアと添加物の意味は、以下に説明されています。
DOCUM: The "meaning" of a document is a deep and interesting human question related to volition. It is probably necessary for the document to include or reference human language policy and/or warranty/disclaimer information. At an absolute minimum, some sort of semantic labelling is required. The assumed situation is always a person interpreting the whole "document" without other context. Thus it is reasonable to consult attorneys during message design, to require that human-readable statements be "within the four corners" of the document, etc.
DOCUM：ドキュメントの「意味は、」意志に関係の深い、面白い人質問です。文書は、人間の言語の方針および/または保証/免責情報を含むまたは参照することはおそらく必要です。絶対最低でも、セマンティックラベルのいくつかの並べ替えが必要です。仮定の状況は、常に他のコンテキストなしで全体の「ドキュメント」を解釈する人です。したがって、人間が読める文は、文書などの「四隅の範囲内」であることを要求するために、メッセージの設計の際に弁護士に相談するのが妥当です
PROTO: The "meaning" of a protocol message should be clear and unambiguous from the protocol specification. It is frequently defined in terms of the state machines of the sender and recipient processes and may have only the most remote connection with human volition. Such processes have additional context, and the message is usually only meaningful with that additional context. Adding any human-readable text that is not functionally required is silly. Consulting attorneys during design is a bad idea that complicates the protocol and could tie a design effort in knots.
PROTO：プロトコルメッセージの「意味」はプロトコル仕様から明確かつ明瞭でなければなりません。それは頻繁に送信者と受信者のプロセスのステート・マシンで定義されており、人間の意志を持つ唯一のほとんどのリモート接続を有することができます。そのようなプロセスは、追加のコンテキストを有し、メッセージは、通常、その追加のコンテキストでのみ意味があります。機能的に必要とされていないすべての人間が読めるテキストを追加することは愚かです。設計時に弁護士に相談することは、プロトコルを複雑にし、結び目に設計努力を結ぶ可能性が悪い考えです。
Adjunct items can be added or are logical addenda to a message.
補助アイテムを追加またはメッセージに論理的添加物であることができます。
DOCUM: From a document point of view, at the top level is a person looking at a document. So adjunct items such as digital signatures, person's names, dates, etc., must be carefully labeled as to meaning. Thus a digital signature needs to include, in more or less human-readable form, what that signature means (is the signer a witness, author, guarantor, authorizer, or what?). Similarly, a person's name needs to be accompanied by that person's role, such as editor, author, subject, or contributor. As another example, a date needs to be accompanied by the significance of the date, such as date of creation, modification, distribution, or some other event. Given the unrestrained scope of what can be documented, there is a risk of trying to enumerate and standardize all possible "semantic tags" for each kind of adjunct data during in the design process. This can be a difficult, complex, and essentially infinite task (i.e., a rat hole).
DOCUM：ビューの文書の観点から、トップレベルでの文書を見ている人です。だから、などのデジタル署名、人の名前、日付、などの補助項目は、丁寧に意味にと表示される必要があります。したがって、デジタル署名が多かれ少なかれ人間が読める形式で、含める必要があり、何その署名手段（署名者目撃者、作成者、保証人、承認者、または何ですか？）。同様に、人の名前は、編集者、執筆者、件名、または貢献者として、その人の役割を伴うことが必要です。別の例として、日付は、作成、変更、配布、または他のいくつかのイベントの日付として日付の重要性を伴うことが必要です。文書化することができるものの気ままな範囲を考えると、列挙し、設計プロセスの中に付属データの種類ごとにすべての可能な「セマンティックタグ」を標準化しようとしている恐れがあります。これは、困難な複雑な、本質的に無限のタスク（すなわち、ラットホール）であってもよいです。
PROTO: From a protocol point of view, the semantics of the message and every adjunct in it are defined in the protocol specification. Thus, if there is a slot for a digital signature, person's name, a date, or whatever, the party who is to enter that data, the party or parties who are to read it, and its meaning are all pre-defined. Even if there are several possible meanings, the specific meaning that applies can be specified by a separate enumerated type field. There is no reason for such a field to be directly human readable. Only the "meanings" directly relevant to the particular protocol need be considered. Another way to look at this is that the "meaning" of each adjunct, instead of being pushed into and coupled with the adjunct itself, as the document point of view encourages, is commonly promoted to the level of the protocol specification, resulting in simpler adjuncts.
PROTO：ビューのプロトコルの観点から、メッセージ及びその中のすべての補助剤のセマンティクスは、プロトコル仕様で定義されています。デジタル署名用のスロットがある場合はこのようにして、そのデータを入力することで、人の名前、日付、または何でも、パーティー、それを読むためにある当事者、およびその意味は、すべての事前定義されています。いくつかの可能な意味がある場合でも、適用される特定の意味は、別の列挙型のフィールドで指定することができます。そのようなフィールドが読める直接人間であるために理由はありません。特定のプロトコルに直接関係のみ「の意味は」考慮する必要が。これを見て別の方法ではなく、ビューの文書点が奨励として、押し込ま及び補助自体と結合された各補助の「意味」は、一般的に簡単で、その結果、プロトコル仕様のレベルに昇格されることです補助剤。
The document oriented and protocol oriented have very different views on what is likely to happen to an object.
ドキュメント指向と指向のプロトコルは、オブジェクトに起こりそうであるかについては非常に異なる見解を持っています。
DOCUM: The model is of a quasi-static object like a piece of paper. About all one does to pieces of paper is transfer them as a whole, from one storage area to another, or add signatures, date stamps, or similar adjuncts. (Possibly one might want an extract from a document or to combine multiple documents into a summary, but this isn't the common case.)
DOCUM：モデルは、一枚の紙のような準静的オブジェクトです。すべての一つは、紙の部分に行い1つの記憶領域から別のものに、全体としてそれらを転送したり、署名を追加し、日付スタンプ、または類似の補助剤です。 （おそらく1は、ドキュメントから抽出したい場合がありますまたは集計に複数のドキュメントを結合するが、これは一般的なケースではありません。）
PROTO: The standard model of a protocol message is as an ephemeral composite, multi-level object created by a source process and consumed by a destination process. Such a message is constructed from information contained in previously received messages, locally stored information, local calculations, etc. Quite complex processing is normal.
PROTO：プロトコルメッセージの標準モデルは、宛先プロセスによって、ソース・プロセスによって作成され、消費短命複合多レベルのオブジェクトとしてです。そのようなメッセージは、かなり複雑な処理が正常である以前に受信したメッセージに含まれる情報、ローカルに格納された情報、ローカル計算、等から構成されています。
DOCUM: The document view is generally of uniform processing or evaluation of the object being specified. There may be an allowance for attachments or addenda, but, if so, they would probably be simple, one level, self documenting attachments or addenda. (Separate processing of an attachment or addenda is possible but not usual.)
DOCUM：ドキュメントビューが指定され、一般に均一な処理あるいはオブジェクトの評価です。もしそうなら、彼らはおそらく、単純な、1つのレベル、自己文書化添付ファイルや添加物となり、そこに添付ファイルや添加物のための手当でもよいが。 （付着又は添加物の別々の処理は可能であるが、通常はありません。）
PROTO: Processing is complex and almost always affects different pieces of the message differently. Some pieces may be intended for use only by the destination process and may be extensively processed there. Others may be present so that the destination process can, at some point, do minimal processing and forward them in other messages to yet more processes. The object's structure can be quite rich and have multilevel or recursive aspects. Because messages are processed in a local context, elements of the message may include items like a signature that covers multiple data elements, some of which are in the message, some received in previous messages, and some locally calculated.
PROTO：処理が複雑で、ほとんど常に違ったメッセージの異なる部分に影響を与えます。いくつかの作品は、宛先プロセスで使用することを意図することができると広範囲に存在して処理することができます。先のプロセスは、いくつかの点で、最小限の処理を行うと、他のメッセージにはまだ多くのプロセスでそれらを転送できるように、他には存在していてもよいです。オブジェクトの構造は非常に豊富でかつマルチレベルまたは再帰的な側面を持つことができます。メッセージは、ローカルコンテキストで処理されるため、メッセージの要素は、メッセージ内にあるそのうちのいくつかは複数のデータ要素を、カバー署名のような項目を含んでいてもよい、一部は前のメッセージで受信し、そしていくつかはローカルで計算します。
DOCUM: The document oriented don't usually think of extensibility as a major problem. They assume that their design, perhaps with some simple version scheme, will meet all requirements. Or, coming from an SGML/DTD world of closed systems, they may assume that knowledge of new versions or extensions can be easily and synchronously distributed to all participating sites.
DOCUM：指向のドキュメントは通常、大きな問題と拡張性を考えていません。彼らは、彼らのデザインは、おそらくいくつかの簡単なバージョンスキームで、すべての要件を満たすことを前提としています。または、クローズドシステムのSGML / DTDの世界から来て、彼らは簡単かつ同期のすべての参加サイトに配布することができ、新しいバージョンまたは拡張の知識を仮定してもよいです。
PROTO: Those who are protocol oriented assume that protocols will always need to be extended and that it will not be possible to update all implementations as such extensions are deployed and/or retired. This is a difficult problem but those from the protocol point of view try to provide the tools needed. For example, they specify carefully defined versioning and extension/feature labelling, including the ability to negotiate versions and features where possible and at least a specification of how parties running different levels should interact, providing length/delimiting information for all data so that it can be skipped if not understood, and providing destination labelling so that a process can tell that it should ignore data except for passing it through to a later player.
PROTO：指向のプロトコルのある方は、プロトコルは常に拡張する必要があることと、そのような機能拡張が展開および/または退職しているとして、すべての実装を更新することはできないことを前提としています。これは難しい問題ですが、ビューのプロトコル・ポイントからのものは、必要なツールを提供してみてください。例えば、彼らはそれができるように、すべてのデータのための情報を区切る/長さを提供し、可能なバージョンと機能を交渉する能力とさまざまなレベルを実行している当事者が相互に作用する方法の少なくとも仕様を含め、慎重に定義されたバージョン管理と拡張/機能のラベルを、指定します理解されていない場合はスキップされ、処理は、それは後でプレイヤーにそれを通過以外のデータを無視すべきであることを伝えることができるように、宛先ラベルを提供すること。
Security is a subtle area. Sometime problems can be solved in a way that is effective across many applications. Those solutions are typically incorporated into standard security syntaxes such as those for ASN.1 [RFC3852] and XML [RFC3275, XMLENC]. But there are almost always application specific questions, particularly the question of exactly what information needs to be authenticated or encrypted.
セキュリティは、微妙な領域です。いつかの問題は、多くのアプリケーション間で効果的な方法で解決することができます。これらのソリューションは、典型的には、ASN.1 [RFC3852]及びXML [RFC3275、XMLENC]のもののような標準的なセキュリティの構文に組み込まれます。しかし、アプリケーションの具体的な質問、情報が認証または暗号化する必要が正確に何の特に問題はほとんど常にあります。
Questions of exactly what needs to be secured and how to do so robustly are deeply entwined with canonicalization. They are also somewhat different for authentication and encryption, as discussed below.
確保されるようにし、どのように確実に深く正規化と絡めているんする必要が正確に何の質問。以下に説明するように彼らは、認証と暗号化のためにも多少異なります。
Canonicalization is the transformation of the "significant" information in a message into a "standard" form, discarding "insignificant" information, for example, encoding into a standard character set or changing line endings into a standard encoding and discarding the information about the original character set or line ending encodings. Obviously, what is "significant" and what is "insignificant" varies with the application or protocol and can be tricky to determine. However, it is common that for each particular syntax, such as ASCII [ASCII], ASN.1 [ASN.1], or XML [XML], a
正規化は、例えば、「有意でない」情報を破棄、「標準的な」形態へのメッセージで「有意な」情報の変換である標準文字セットに符号化または標準エンコーディングに改行コードを変更し、元の情報を破棄する文字セットやエンコーディングを行末。もちろん、どのような「重要」であるとどのような「軽微」であることは、アプリケーションやプロトコルに応じて変化し、決定するのが難しいことができます。しかし、このようなASCII [ASCII]、ASN.1 [ASN.1]、またはXML [XML]、Aのように、各特定の構文が一般的です
standard canonicalization (or canonicalizations) is specified or developed through practice. This leads to the design of applications that assume one of such standard canonicalizations, thus reducing the need for per-application canonicalization. (See also [RFC3076, RFC3741].)
標準正規化は、（またはcanonicalizations）を指定したか、実践を通して開発されています。これによりアプリケーションごとの正規化の必要性を減らす、などの標準的なcanonicalizationsの1を前提としたアプリケーションの設計につながります。 （[RFC3076、RFC3741]も参照）。
DOCUM: From the document point of view, canonicalization is suspect if not outright evil. After all, if you have a piece of paper with writing on it, any modification to "standardize" its format can be an unauthorized change in the original message as created by the "author", who is always visualized as a person. Digital signatures are like authenticating signatures or seals or time stamps on the bottom of the "piece of paper". They do not justify and should not depend on changes in the message appearing above them. Similarly, encryption is just putting the "piece of paper" in a vault that only certain people can open and does not justify any standardization or canonicalization of the message.
DOCUMは：ビューの文書の観点から、正規化が疑われる場合はないあからさまな悪です。結局のところ、あなたは、それを書いて、常に人として可視化される「著者」、によって作成されたように、その形式は、元のメッセージに不正な変更することができ、「標準化」への変更を一枚の紙を持っている場合。デジタル署名は、「一枚の紙」の下部に署名またはシールやタイムスタンプを認証するようなものです。彼らは正当化していないし、それらの上に表示されるメッセージの変化に依存してはいけません。同様に、暗号化は、単に特定の人だけが開くことができるとのメッセージのいずれかの標準化や標準化を正当化しない金庫に「一枚の紙を」入れています。
PROTO: From the protocol point of view, canonicalization is simply a necessity. It is just a question of exactly what canonicalization or canonicalizations to apply to a pattern of bits that are calculated, processed, stored, communicated, and finally parsed and acted on. Most of these bits have never been seen and never will be seen by a person. In fact, many of the parts of the message will be artifacts of encoding, protocol structure, and computer representation rather than anything intended for a person to see. Perhaps in theory, the "original", idiosyncratic form of any digitally signed part could be conveyed unchanged through the computer process, storage, and communications channels that implement the protocol and could be usefully signed in that form. But in practical systems of any complexity, this is unreasonably difficult, at least for most parts of messages. And if it were possible, it would be virtually useless, because to authenticate messages you would still have to determine their equivalence with the preserved original form. Thus, signed data must be canonicalized as part of signing and verification to compensate for insignificant changes made in processing, storage, and communication. Even if, miraculously, an initial system design avoids all cases of signed message reconstruction based on processed data or re-encoding based on character set or line ending or capitalization or numeric representation or time zones or whatever, later protocol revisions and extensions are certain to require such reconstruction and/or re-encoding eventually. If such "insignificant" changes are not ameliorated by canonicalization, signatures won't work, as discussed in more detail in 2.4.3 below.
PROTO：ビューのプロトコルの観点から、正規化は、単に必要です。これは、計算処理され、保存され、伝え、そして最終的に解析され、作用を受けているビットのパターンに適用する正確に何を正規化またはcanonicalizationsの問題だけです。これらのビットのほとんどは見たことがない人で何も見えませんでした。実際には、メッセージの部品の多くは、参照するには、人のために意図エンコーディング、プロトコル構成、およびコンピュータ表現の成果物ではなく、何もすることになります。おそらく理論的には、任意のデジタル署名された部分の「オリジナル」、特異な形態は、プロトコルを実装し、その有用形で署名されることができ、コンピュータ処理、ストレージ、および通信チャネルを通じて不変搬送することができます。しかし、どんな複雑な実際のシステムでは、これは、少なくともメッセージの大部分について、不当に困難です。それが可能であったならば、あなたはまだ保存元の形で彼らの同等性を決定しなければならないメッセージを認証するためと、それは、事実上役に立たないだろう。このように、署名されたデータは、処理、ストレージ、および通信で行われた些細な変化を補償するために署名と検証の一部として、正規化されなければなりません。 、奇跡的に、初期のシステム設計は、文字セットまたは線が終了又は大文字または数値表現または時間帯または任意に基づいて処理されたデータ又は再符号化に基づいて署名されたメッセージの再構成のすべてのケースを回避した場合でも、後のプロトコル改訂及び拡張はに一定でありますそのような再構成および/または最終的に再エンコードを必要とします。例えば、「重要でない」の変更は正規化によって改善されていない場合は、以下の2.4.3で詳細に説明したように、署名は、動作しません。
DOCUM: The document-oriented view on authentication tends to be a "digital signature" and "forms" point of view. (The "forms" point of view is a subset of the document point of view that believes that a principal activity is presenting forms to human beings so that they can fill out and sign portions of those forms [XForms]). Since the worry is always about human third parties and viewing the document in isolation, those who are document oriented always want "digital signature" (asymmetric key) authentication, with its characteristics of "non-repudiability", etc. As a result, they reject secret key based message authentication codes, which provide the verifier with the capability of forging an authentication code, as useless. (See any standard reference on the subject for the usual meaning of these terms.) From their point of view, you have a piece of paper or form which a person signs. Sometimes a signature covers only part of a form, but that's usually because a signature can only cover data that is already there. And normally at least one signature covers the "whole" document/form. Thus the document oriented want to be able to insert digital signatures into documents without changing the document type and even "inside" the data being signed, which requires a mechanism to skip the signature so that it does not try to sign itself.
DOCUM：認証のドキュメント指向のビューは、「デジタル署名」とビューの「形」点となる傾向があります。 （図の「形」点は、彼らが記入及びそれらの形態の部分[XFormsを】署名できるように、主要活性は、ヒトへのフォームを提示していると考えているビューの文書の点のサブセットです）。心配は人間の第三者について常にあると孤立してドキュメントを表示するので、ドキュメント指向している者は、常に彼らが、結果としてなど、「非repudiability」、その特性を持つ「デジタル署名」（非対称鍵）の認証を、したいです役に立たないように、認証コードを鍛造する能力を検証を提供する秘密鍵ベースのメッセージ認証コードを、拒否。 （これらの用語の通常の意味のための主題上の任意の標準的なリファレンスを参照してください。）彼らの視点からは、あなたが一枚の紙を持っているか、どの人物の兆候を形成します。時には署名は、フォームの一部のみをカバーしますが、署名は、すでにそこにあるデータをカバーすることができますので、それが通常です。そして、通常、少なくとも一つの署名は「全体」のドキュメント/フォームをカバーしています。したがって、指向文書は、文書タイプ、さらには「内側」を変更することなく、文書にデジタル署名を挿入することができるようにしたいデータは、それ自体に署名しようとしないように署名をスキップするメカニズムを必要とする、署名されています。
PROTO: From a protocol point of view, the right kind of authentication to use, whether "digital signature" or symmetric keyed authentication code (or biometric or whatever), is just another engineering decision affected by questions of efficiency, desired security model, etc. Furthermore, the concept of signing a "whole" message seems very peculiar (unless it is a copy being saved for archival purposes, in which case you might be signing a whole archive at once anyway). Typical messages are made up of various pieces with various destinations, sources, and security requirements. Furthermore, there are common fields that it is rarely useful to sign because they change as the message is communicated and processed. Examples include hop counts, routing history, and local forwarding tags.
PROTO：ビューのプロトコルの観点から、使用する認証の正しい種類、「デジタル署名」または対称鍵付き認証コード（または生体または任意）は、効率の問題によって影響を受けるだけで、別の工学決定であるか否かを、所望のセキュリティモデルなど（それはあなたが、とにかく一度に全体のアーカイブに署名する可能性がある場合にはアーカイブの目的のために保存されたコピーである場合を除く）。また、「全体」のメッセージに署名するという概念は非常に特異なようです。典型的なメッセージは様々な宛先、ソース、およびセキュリティ要件を持つさまざまな部分で構成されています。さらに、メッセージが伝達され、処理される彼らは変化するため、署名することがまれに有用である一般的なフィールドがあります。例としては、ホップ数、ルーティングの歴史、およびローカルフォワーディングタグが含まれます。
For authenticating protocol system messages of practical complexity, you are faced with the choice of doing
実用的な複雑さのプロトコルシステムメッセージを認証するために、あなたがやっての選択に直面しています
(1) "too little canonicalization" and having brittle authentication, useless due to verification failures caused by surface representation changes without significance,
（1）による有意ことなく表面表現変化による検証の失敗に「少なすぎる正規化」と脆い認証を有する、役に立ちません、
(2) the sometimes difficult and tricky work of selecting or designing an appropriate canonicalization or canonicalizations to be used as part of authentication generation and verification, producing robust and useful authentication, or
（2）認証の生成と検証の一部として使用される適切な正規化又はcanonicalizationsを選択または設計することが困難な場合やトリッキーな仕事を、堅牢で有用な認証を生成、または
(3) "too much canonicalization" and having insecure authentication, useless because it still verifies even when significant changes are made in the signed data.
（3）「あまりにも多くの正規化」となる不安定な認証、それはまだ大幅な変更が署名されたデータに行われた場合にも確認するため、役に立ちません。
The only useful option above is number 2.
唯一の有効なオプションは、上記数2です。
In terms of processing, transmission, and storage, encryption turns out to be much easier to get working than signatures. Why? Because the output of encryption is essentially random bits. It is clear from the beginning that those bits need to be transferred to the destination in some absolutely clean way that does not change even one bit. Because the encrypted bits are meaningless to a human being, there is no temptation among the document oriented to try to make them more "readable". So appropriate techniques of encoding at the source, such as Base64 [RFC2045], and decoding at the destination, are always incorporated to protect or "armor" the encrypted data.
処理、伝送、およびストレージの面では、暗号化が署名よりも作業を取得する方がはるかに簡単であることが判明しました。どうして？暗号化の出力は、本質的にランダムビットであるため。これは、それらのビットが1ビットでも変更されませんいくつかの完全にクリーンな方法で先に転送する必要が最初から明らかです。暗号化されたビットは、人間にとって無意味であるため、それらをより「読み」にしようとする志向の文書間には誘惑がありません。そう適切なようにBase64のようなソースで符号化技術、[RFC2045]、および先の復号化は、常に暗号化されたデータを保護するか、「鎧」に組み込まれています。
Although the application of canonicalization is more obvious with digital signatures, it may also apply to encryption, particularly encryption of parts of a message. Sometimes elements of the environment where the plain text data is found may affect its interpretation. For example, interpretation can be affected by the character encoding or bindings of dummy symbols. When the data is decrypted, it may be into an environment with a different character encoding or dummy symbol bindings. With a plain text message part, it is usually clear which of these environmental elements need to be incorporated in or conveyed with the message. But an encrypted message part is opaque. Thus some canonical representation that incorporates such environmental factors may be needed.
正規化のアプリケーションは、デジタル署名とより明らかであるが、それはまた、暗号化、メッセージの一部の特に暗号化に適用することができます。時には、平文データが発見された環境の要素は、その解釈に影響を与える可能性があります。例えば、解釈は、文字エンコーディングやダミーシンボルのバインディングによって影響を受けることができます。データが復号化されるとき、それは異なる文字符号化又はダミーシンボル結合を有する環境にあってもよいです。プレーンテキストメッセージの一部では、中に組み込まれるか、またはメッセージで搬送する必要がこれらの環境要素のどの通常明らかです。しかし、暗号化されたメッセージの一部は不透明です。従って、このような環境要因を組み込んで、いくつかの標準的な表現が必要な場合があります。
DOCUM: Encryption of the entire document is usually what is considered. Because signatures are always thought of as human assent, people with a document point of view tend to vehemently assert that encrypted data should never be signed unless the plain text of it is known.
DOCUM：文書全体の暗号化は、通常考えられているものです。署名は常に人間同意するものと考えられているので、ビューの文書のポイントを持つ人々は、猛それのプレーンテキストが知られていない限り、暗号化されたデータに署名してはならないと主張する傾向があります。
PROTO: Messages are complex composite multi-level structures, some pieces of which are forwarded multiple hops. Thus the design question is what fields should be encrypted by what techniques to what destination or destinations and with what canonicalization.
PROTO：メッセージは、複雑な複合マルチレベル構造、複数のホップに転送されるいくつかの部分です。このような設計の問題は、フィールドがどのような目的地または目的地とどのような正規化とにどのような技術によって暗号化されるべきものです。
It sometimes makes perfect sense to sign encrypted data you don't understand; for example, the signature could just be for integrity protection or for use as a time stamp, as specified in the protocol.
それは時々あなたが理解していない暗号化されたデータに署名するために完璧な理にかなっています。例えば、署名はちょうどプロトコルで指定され、完全性保護のためまたはタイムスタンプとして使用するためである可能性があります。
It is desirable to be able to reference parts of structured messages or objects by some sort of "label" or "id" or "tag". The idea is that this forms a fixed "anchor" that can be used "globally", at least within an application domain, to reference the tagged part.
「標識」または「ID」や「タグ」のいくつかの並べ替えによって構造化されたメッセージまたはオブジェクトの一部を参照することができることが望ましいです。アイデアは、これがタグ付けされた部分を参照するために、少なくともアプリケーション・ドメイン内で、「グローバル」を使用することができる一定の「アンカー」を形成することです。
DOCUM: From the document point of view, it seems logical just to provide for a text tag. Users or applications could easily come up with short readable tags. These would probably be meaningful to a person if humanly generated (e.g., "Susan") and at least fairly short and systematic if automatically generated (e.g., "A123"). The ID attribute type in XML [XML] appears to have been thought of this way, although it can be used in other ways.
DOCUM：ビューの文書の観点から、それは単なるテキストタグを提供するために論理的なようです。ユーザーまたはアプリケーションは、簡単に短い読めるタグを思い付くことができます。人間的に（例えば、「スーザン」）が発生し、少なくともかなり短くかつ体系場合は、自動的に（例えば、「A123」）生成された場合、これらはおそらく人には意味があるでしょう。 XMLのID属性型[XML]は、それが他の方法で使用することができるが、この方法を考えてきたように見えます。
PROTO: From a protocol point of view, unique internal labels look very different than they do from a document point of view. Since this point of view assumes that pieces of different protocol messages will later be combined in a variety of ways, previously unique labels can conflict. There are really only three possibilities if such tags are needed, as follows:
PROTOは：ビューのプロトコルの観点から、一意の内部ラベルは、彼らはビューの文書の観点から行うよりも非常に異なって見えます。この観点は、異なるプロトコルメッセージの部分が後、種々の方法で結合されることを前提としているので、先に固有のラベルが競合することができます。以下のようなタグが必要な場合のみ、3つの可能性が、実際にはあります。
(1) Have a system for dynamically rewriting such tags to maintain uniqueness. This is usually a disaster, as it (a) invalidates any stored copies of the tags that are not rewritten, and it is usually impossible to be sure there aren't more copies lurking somewhere you failed to update, and (b) invalidates digital signatures that cover a changed tag. (2) Use some form of hierarchical qualified tags. Thus the total tag can remain unique even if a part is moved, because its qualification changes. This avoids the digital signature problems described above. But it destroys the concept of a globally-unique anchor embedded in and moving with the data. And stored tags may still be invalidated by data moves. Nevertheless, within the scope of a particular carefully designed protocol, such as IOTP [RFC2801], this can work. (3) Construct a lengthy globally-unique tag string. This can be done successfully by using a good enough random number generator and big enough random tags (perhaps about 24 characters) sequentially, as in the way email messages IDs are created [RFC2822].
（1）動的に一意性を維持するために、このようなタグを書き換えるためのシステムを持っています。それは（a）に書き換えられていないタグのいずれかの保存されたコピーを無効にし、あなたが更新に失敗した、および（b）はデジタルを無効にどこかに潜んでいる複数のコピーが存在しないことを確認することは通常不可能であるように、これは、通常の災害です変更されたタグをカバーシグネチャ。 （2）階層的な資格のタグのいくつかのフォームを使用します。したがって総タグは、その資格が変化するので部が、移動してもユニークなままであり得ます。これは、上述したデジタル署名の問題を回避します。しかし、それはグローバルにユニークなアンカーに埋め込まれたデータを移動するという概念を破壊します。そして、保存されたタグがまだデータ移動によって無効にすることができます。それにもかかわらず、そのようなIOTP [RFC2801]などの特定の注意深く設計されたプロトコルの範囲内で、これは動作することができます。 （3）長いグローバルに一意のタグの文字列を構築します。これは、電子メールメッセージIDが作成されている方法[RFC2822]のように、良い十分な乱数発生器と十分に大きいランダムタグ（おそらく約24文字）連続して使用することにより、正常に行うことができます。
Thus, from a protocol point of view, such tags are difficult but if they are needed, choice 3 works best.
したがって、ビューのプロトコルの観点から、そのようなタグは難しいですが、彼らが必要な場合は、選択肢3は、最も適しています。
IETF protocols are replete with examples of the protocol viewpoint such as TCP [RFC793], IPSEC [RFC2411], SMTP [RFC2821], and IOTP [RFC2801, RFC2802].
IETFプロトコルは、TCP [RFC793]、IPSEC [RFC2411]、SMTP [RFC2821]、およびIOTP [RFC2801、RFC2802]などのプロトコルの視点の例に満ちています。
The eXtensible Markup Language [XML] is an example of something that can easily be viewed both ways and where the best results frequently require attention to both the document and the protocol points of view.
拡張マークアップ言語は、[XML]簡単に両方の方法を見たし、最高の結果が頻繁に文書やビューのプロトコル・ポイントの両方に注意を必要とすることができるものの一例です。
Computerized court documents, human-to-human email, and the X.509v3 Certificate [X509v3], particularly the X509v3 policy portion, are examples primarily designed from the document point of view.
コンピュータ化された裁判所の文書、人間からヒトへの電子メール、およびのX.509v3証明書[書X509v3]、特に書X509v3方針部分は、主にビューの文書の観点から設計された例です。
There is some merit to each point of view. Certainly the document point of view has some intuitive simplicity and appeal and is OK for applications where it meets needs.
ビューの各ポイントにはいくつかのメリットがあります。確かにビューの文書のポイントは、いくつかの直感的なシンプルさと魅力を持っており、それがニーズを満たすアプリケーションにOKです。
The protocol point of view can come close to encompassing the document point of view as a limiting case. In particular, it does so under the following circumstances:
ビューのプロトコル・ポイントは、限定場合のようにビューの文書点を包含するに近づくことができます。特に、それは次のような状況の下でそうします：
1. As the complexity of messages declines to a single payload (perhaps with a few attachments).
メッセージの複雑さ1.（おそらくいくつかの添付ファイル付きの）単一のペイロードに低下します。
2. As the mutability of the payload declines to some standard format that needs little or no canonicalization.
ペイロードの可変性として、2はほとんど、あるいはまったく正規化を必要とするいくつかの標準的なフォーマットに低下します。
3. As the number of parties and amount of processing declines as messages are transferred.
メッセージが転送される当事者と処理量の数が3が低下します。
4. As the portion of the message intended for more or less direct human consumption increases.
多かれ少なかれ直接的なヒトの消費の増加のために意図されたメッセージの一部として4。
Under the above circumstances, the protocol point of view would be narrowed to something quite close to the document point of view. Even when the document point of view is questionable, the addition of a few options to a protocol will usually mollify the perceived needs of those looking at things from that point of view. For example, adding optional non-canonicalization or an optional policy statement, or inclusion of semantic labels, or the like.
このような状況下では、ビューのプロトコル・ポイントは、ビューの文書のポイントに非常に近いものに絞られることになります。ビューの文書のポイントは疑問がある場合でも、プロトコルへのいくつかのオプションを追加するには、通常、その観点から物事を見て、それらの知覚ニーズを和らげるだろう。例えば、任意の非正規化またはオプションのポリシーステートメント、または意味ラベルを含めること、などを追加します。
On the other hand, the document point of view is hard to stretch to encompass the protocol case. From a strict piece of paper perspective, canonicalization is wrong; inclusion of human language policy text within every significant object and a semantic tag with every adjunct should be mandatory; and so on. Objects designed in this way are rarely suitable for protocol use, as they tend to be improperly structured to accommodate hierarchy and complexity, inefficient (due to unnecessary text and self-documenting inclusions), and insecure (due to brittle signatures).
一方、ビューの文書ポイントは、プロトコルのケースを包含するように延伸することは困難です。紙の視点の厳格な作品からは、正規化は間違っています。人間の言語政策のすべての重要なオブジェクト内のテキストおよびすべての付属物との意味タグを含めることは必須である必要があります。等々。このように設計されたオブジェクト、彼らが不適切階層や複雑さに対応するために構造化される傾向があるよう（不必要なテキストと自己文書介在物）、非効率的なプロトコルを使用するためにまれに適しており、安全でない（脆性署名します）。
Thus, to produce usable protocols, it is best to start with the protocol point of view and add document point of view items as necessary to achieve consensus.
したがって、使用可能なプロトコルを生成するために、それはビューのプロトコル点で開始し、コンセンサスを達成するために必要なビュー項目の文書ポイントを追加することをお勧めします。
I hope that this document will help explain to those of either point of view where those with the other view are coming from. It is my hope that this will decrease conflict, shed some light -- in particular on the difficulties of security design -- and lead to better protocol designs.
私は、この文書は、他のビューを持つものから来ているビューのいずれかの時点のものに説明するのに役立つことを願っています。特に、セキュリティ設計の難しさに - - と、より良いプロトコル設計につながるこれは、競合を減少させ、いくつかの光を当てるだろうというのが私の希望です。
This document considers the security implications of the Document and Protocol points of view, as defined in Sections 2.1 and 2.2, and warns of the security defects in the Document view. Most of these security considerations appear in Section 2.4 but they are also touched on elsewhere in Section 2 which should be read in its entirety.
このドキュメントは、セクション2.1および2.2で定義されるように、ビューの文書とプロトコルポイントのセキュリティへの影響を考慮して、ドキュメントビューのセキュリティ欠陥の警告します。これらのセキュリティ上の考慮事項のほとんどは、2.4節に表示されますが、それらはまた、全体的に読まれるべき第2の別の場所に触れています。
Informative References
参考文献
[ASCII] "USA Standard Code for Information Interchange", X3.4, American National Standards Institute: New York, 1968.
[ASCII]「情報交換用米国標準コード」、X3.4、米国規格協会：ニューヨーク、1968年。
[ASN.1] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998, "Information Technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation".
[ASN.1] ITU-T勧告X.680（1997）| ISO / IEC 8824から1：1998、 "情報技術 - 抽象構文記法1（ASN.1）：基本的な記法の仕様"。
ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998,
"Information Technology - ASN.1 Encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)". <http://www.itu.int/ITU-
T/studygroups/com17/languages/index.html>.
[CSS] "Cascading Style Sheets, level 2 revision 1 CSS 2.1 Specification", B. Bos, T. Gelik, I. Hickson, H. Lie, W3C Candidate Recommendation, 25 February 2004. <http://www.w3.org/TR/CSS21>
[CSS] "カスケーディングスタイルシート、レベル2リビジョン1つのCSS 2.1仕様"、B.ボス、T. Gelik、I.ヒクソン、H.リー、W3C勧告候補25 2004年2月<HTTP：//www.w3。 ORG / TR / CSS21>
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411]セイヤー、R.、Doraswamy、N.、およびR.グレン、 "IPセキュリティドキュメントロードマップ"、RFC 2411、1998年11月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3852] Housley氏、R.、 "暗号メッセージ構文（CMS）"、RFC 3852、2004年7月。
[RFC2801] Burdett, D., "Internet Open Trading Protocol - IOTP Version 1.0", RFC 2801, April 2000.
[RFC2801]バーデット、D.、 "インターネットオープン取引プロトコル - IOTPバージョン1.0"、RFC 2801、2000年4月。
[RFC2802] Davidson, K. and Y. Kawatsura, "Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)", RFC 2802, April 2000.
"v1.0のインターネットオープン取引プロトコル（IOTP）のデジタル署名" [RFC2802]ダビッドソン、K.とY. Kawatsura、RFC 2802、2000年4月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[RFC3076] Boyer, J., "Canonical XML Version 1.0", RFC 3076, March 2001.
[RFC3076]ボイヤー、J.、 "標準的なXMLバージョン1.0"、RFC 3076、2001年3月。
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275]イーストレーク3、D.、Reagle、J.、およびD.ソロ "（拡張マークアップ言語）、XML署名の構文および処理"、RFC 3275、2002年3月。
[RFC3741] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3741]バーガー、L.、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。
[X509v3] "ITU-T Recommendation X.509 version 3 (1997), Information Technology - Open Systems Interconnection - The Directory Authentication Framework", ISO/IEC 9594- 8:1997.
[書X509v3 "ITU-T勧告X.509のバージョン3（1997）、情報技術 - オープンシステムインターコネクション - ディレクトリ認証フレームワーク"、ISO / IEC 9594- 8：1997。
[XForms] "XForms 1.0", M. Dubinko, L. Klotz, R. Merrick, T. Raman, W3C Recommendation 14 October 2003. <http://www.w3.org/TR/xforms/>
[XFormsの "XFormsの1.0"、M. Dubinkoの著、L.クロッツ、R.メリック、T.ラマン、W3C勧告、2003年10月14日<http://www.w3.org/TR/xforms/>
[XML] "Extensible Markup Language (XML) 1.0 Recommendation (2nd Edition)". T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, October 2000. <http://www.w3.org/TR/2000/REC-xml-20001006>
[XML] "拡張マークアップ言語（XML）1.0勧告（第2版）"。 T.ブレイ、J.パオリ、C. M. Sperberg-マックイーン、E.画家、2000年10月<http://www.w3.org/TR/2000/REC-xml-20001006>
[XMLENC] "XML Encryption Syntax and Processing", J. Reagle, D. Eastlake, December 2002. <http://www.w3.org/TR/2001/RED-xmlenc-core-20021210/>
[XMLENC] "XML暗号化構文と処理"、J. Reagle、D.イーストレイク、2002年12月<http://www.w3.org/TR/2001/RED-xmlenc-core-20021210/>
Author's Address
著者のアドレス
Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレーク第3モトローラ研究所155ビーバー通りミルフォード、MA 01757 USA
Phone: +1 508-786-7554 (w) +1 508-634-2066 (h) Fax: +1 508-786-7501 (w) EMail: Donald.Eastlake@motorola.com
電話：+1 508-786-7554（W）+1 508-634-2066（H）FAX番号：+1 508-786-7501（W）メール：Donald.Eastlake@motorola.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、www.rfc-editor.orgで、そこに記載される場合を除き、作者は彼らのすべての権利を保有します。
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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 ISOC文書の権利に関するISOCの手順に関する情報は、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機能のための基金は現在、インターネット協会によって提供されます。