Network Working Group D. Eastlake 3rd
Request for Comments: 3930 Motorola Laboratories
Category: Informational October 2004
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.
本文档对比了两种观点：一种是“文档”观点，其中感兴趣的数字对象类似于人们书写和查看的纸片；另一种是“协议”观点，其中感兴趣的对象是复合动态网络消息。尽管每个观点都有其存在的地方，但坚持文档观点可能会损害协议设计。通过理解这两种观点，可以澄清和减少它们之间的冲突。
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
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
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节中进行了定义和探讨。
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.
文档：重要的是完整的（数字）文档，类似于纸片，供人们查看。一个主要问题是能够尽可能直接向法院或其他第三方提交此类文件。因为呈现给此人的内容才是最重要的，因此任何可能影响此内容的内容，例如“样式表”[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：重要的是由定义良好的计算机协议进程生成和消耗的线路上的位。没有人能看到完整的信息；只有极客在调试时才会将其视为一个整体，即使如此，他们也只能看到一些翻译后的可视形式。如果一个人真的需要在法庭上或向第三方证明这类信息，那么没有任何方法可以避免让计算机专家解释它。有时人们会忘记，这些消息的片段最终可能会包含在显示给某人的数据中，或影响显示给某人的数据。
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.
文档的“意义”是一个与意志有关的深刻而有趣的人类问题。文档可能需要包含或引用人类语言政策和/或保修/免责声明信息。至少需要某种语义标记。假设的情况总是一个人在没有其他上下文的情况下解释整个“文档”。因此，在消息设计期间咨询律师是合理的，要求人类可读的声明“在文档的四个角落内”，等等。
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).
文档：从文档的角度来看，顶层是一个人在看文档。因此，诸如数字签名、人名、日期等附加项目必须仔细标注其含义。因此，数字签名需要或多或少以人类可读的形式包括该签名的含义（签名人是证人、作者、担保人、授权人还是什么？）。类似地，一个人的名字需要伴随着该人的角色，如编辑、作者、主题或贡献者。另一个例子是，日期需要附有日期的重要性，例如创建、修改、分发或其他事件的日期。由于可以记录的内容范围不受限制，因此在设计过程中可能会尝试枚举和标准化每种附属数据的所有可能的“语义标记”。这可能是一项困难、复杂且本质上无限的任务（即老鼠洞）。
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.)
文档：模型是一个准静态对象，就像一张纸。人们对纸张所做的一切就是将它们作为一个整体从一个存储区域转移到另一个存储区域，或者添加签名、日期戳或类似的附件。（可能需要从一个文档中提取内容或将多个文档合并成一个摘要，但这不是常见情况。）
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.)
文档：文档视图通常是对指定对象的统一处理或评估。附件或补遗可能有一定的余量，但如果是这样，它们可能是简单的、一级的、自我记录的附件或补遗。（可以单独处理附件或补遗，但不常见。）
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]，一个
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].)
标准规范化（或规范化）是通过实践指定或发展的。这将导致应用程序的设计采用此类标准规范化之一，从而减少对每个应用程序规范化的需求。（另请参见[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.
文件：从文件的角度来看，规范化是可疑的，如果不是彻头彻尾的邪恶。毕竟，如果你有一张写有文字的纸，“标准化”其格式的任何修改都可能是对原始消息的未经授权的更改，而原始消息是由“作者”创建的，他总是被视为一个人。数字签名就像“一张纸”底部的认证签名、印章或时间戳。它们不合理，也不应依赖于它们上方出现的消息中的更改。类似地，加密只是将“一张纸”放在只有某些人才能打开的保险库中，并不证明对消息进行任何标准化或规范化是合理的。
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：从协议的角度来看，规范化只是一种必要。这只是一个问题，究竟什么样的规范化或规范化应用于计算、处理、存储、通信、最终解析和执行的位模式。这些碎片中的大部分从未被人看到，也永远不会被人看到。事实上，消息的许多部分将是编码、协议结构和计算机表示的工件，而不是供人看到的任何东西。也许在理论上，任何数字签名部分的“原始”特殊形式都可以通过实现协议的计算机进程、存储和通信通道原封不动地传递，并可以有效地以该形式签名。但在任何复杂的实际系统中，这都是不合理的困难，至少对于消息的大多数部分来说是如此。如果可能的话，它实际上是无用的，因为要验证消息，您仍然必须确定它们与保留的原始形式的等价性。因此，签名数据必须规范化，作为签名和验证的一部分，以补偿在处理、存储和通信中所做的微不足道的更改。即使初始系统设计奇迹般地避免了所有基于处理数据的签名消息重建或基于字符集或行尾或大写或数字表示或时区或其他任何形式的重新编码的情况，后来的协议修订和扩展肯定最终需要这种重建和/或重新编码。如果这种“无关紧要”的变化没有通过规范化得到改善，签名就不会起作用，下面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]）。由于担心的总是人类第三方和孤立地查看文档，因此面向文档的人总是希望“数字签名”（非对称密钥）身份验证，具有“不可否认性”等特点。因此，他们拒绝基于密钥的消息身份验证码，它为验证者提供伪造身份验证码的能力，这是无用的。（有关这些术语的通常含义，请参见关于该主题的任何标准参考资料。）从他们的角度来看，你有一张纸或一个人签名的表格。有时签名只覆盖表单的一部分，但这通常是因为签名只能覆盖已经存在的数据。通常，至少有一个签名覆盖“整个”文件/表格。因此，面向文档的技术人员希望能够在不改变文档类型的情况下将数字签名插入到文档中，甚至不改变正在签名的数据的“内部”，这就需要一种跳过签名的机制，以便它不会尝试自己签名。
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) 选择或设计适当的规范化或规范化以作为身份验证生成和验证的一部分，从而生成健壮和有用的身份验证，或
(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.
在处理、传输和存储方面，加密比签名更容易实现。为什么？因为加密的输出本质上是随机位。从一开始就很清楚，这些位需要以一种绝对干净的方式传输到目的地，这种方式甚至不会改变一位。因为加密的比特对人类来说是毫无意义的，所以面向文档的人不会试图让它们更“可读”。因此，在源位置编码的适当技术，如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.
文档：通常考虑对整个文档进行加密。由于签名总是被认为是人类的同意，持有文档观点的人倾向于强烈主张，除非已知加密数据的纯文本，否则不应对其进行签名。
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：从文档的角度来看，仅仅提供一个文本标记似乎是合乎逻辑的。用户或应用程序可以很容易地提出简短的可读标记。如果是人工生成的（如“Susan”），这些可能对一个人有意义，如果是自动生成的（如“A123”），这些可能至少相当简短和系统化。XML[XML]中的ID属性类型似乎是这样考虑的，尽管它可以用其他方式使用。
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：从协议的角度来看，独特的内部标签与从文档的角度看非常不同。由于该观点假设不同的协议消息片段稍后将以多种方式组合，因此以前唯一的标签可能会发生冲突。如果需要这样的标签，实际上只有三种可能，如下所示：
(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） 构造一个长的全局唯一标记字符串。这可以通过按顺序使用足够好的随机数生成器和足够大的随机标记（大约24个字符）成功完成，就像创建电子邮件ID的方式一样[RFC2822]。
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.
每种观点都有其优点。当然，文档观点具有一些直观的简单性和吸引力，适合于满足需要的应用程序。
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，“信息技术-抽象语法符号一（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>.
ITU-T建议X.690（1997）| ISO/IEC 8825-1:1998，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（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] "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>
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准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]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411]Thayer，R.，Doraswamy，N.，和R.Glenn，“IP安全文档路线图”，RFC 24111998年11月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3852]Housley，R.，“加密消息语法（CMS）”，RFC3852，2004年7月。
[RFC2801] Burdett, D., "Internet Open Trading Protocol - IOTP Version 1.0", RFC 2801, April 2000.
[RFC2801]Burdett，D.，“互联网开放交易协议-IOTP版本1.0”，RFC2801，2000年4月。
[RFC2802] Davidson, K. and Y. Kawatsura, "Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)", RFC 2802, April 2000.
[RFC2802]Davidson，K.和Y.Kawatsura，“v1.0互联网开放交易协议（IOTP）的数字签名”，RFC 2802，2000年4月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[RFC3076] Boyer, J., "Canonical XML Version 1.0", RFC 3076, March 2001.
[RFC3076]Boyer，J.，“规范XML版本1.0”，RFC3076，2001年3月。
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275]Eastlake 3rd，D.，Reagle，J.，和D.Solo，“（可扩展标记语言）XML签名语法和处理”，RFC 32752002年3月。
[RFC3741] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3741]Berger，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. Klotz, R. Merrick, T.
Raman, W3C Recommendation 14 October 2003.
<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] "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>
[XMLENC] "XML Encryption Syntax and Processing", J. Reagle, D.
Eastlake, December 2002.
<http://www.w3.org/TR/2001/RED-xmlenc-core-20021210/>
[XMLENC] "XML Encryption Syntax and Processing", J. Reagle, D.
Eastlake, December 2002.
<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
Donald E.Eastlake 3rd Motorola Laboratories美国马萨诸塞州米尔福德市海狸街155号，邮编01757
Phone: +1 508-786-7554 (w)
+1 508-634-2066 (h)
Fax: +1 508-786-7501 (w)
EMail: Donald.Eastlake@motorola.com
Phone: +1 508-786-7554 (w)
+1 508-634-2066 (h)
Fax: +1 508-786-7501 (w)
EMail: 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。