Internet Architecture Board (IAB) D. Thaler, Ed.
Request for Comments: 6943 Microsoft
Category: Informational May 2013
ISSN: 2070-1721
Internet Architecture Board (IAB) D. Thaler, Ed.
Request for Comments: 6943 Microsoft
Category: Informational May 2013
ISSN: 2070-1721
Issues in Identifier Comparison for Security Purposes
出于安全目的的标识符比较中的问题
Abstract
摘要
Identifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the security principal may access the resource, what level of authentication or encryption is required, etc. If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result. This document provides a discussion of these issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols.
诸如主机名、URI、IP地址和电子邮件地址等标识符通常在安全上下文中用于标识安全主体和资源。在这种情况下，通常使用一些策略来比较通过某个协议呈现的标识符，以做出安全决策，例如安全主体是否可以访问资源、需要什么级别的认证或加密等。如果参与安全决策的各方使用不同的算法来比较标识符，然后，可能会出现从拒绝服务到提升权限的各种失败情况。本文档讨论了设计者在定义标识符和协议时应考虑的问题，以及在构建使用多个协议的体系结构时应考虑的问题。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。它代表了互联网体系结构委员会（IAB）的共识。IAB批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6943.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6943.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Classes of Identifiers .....................................5
1.2. Canonicalization ...........................................5
2. Identifier Use in Security Policies and Decisions ...............6
2.1. False Positives and Negatives ..............................7
2.2. Hypothetical Example .......................................8
3. Comparison Issues with Common Identifiers .......................9
3.1. Hostnames ..................................................9
3.1.1. IPv4 Literals ......................................11
3.1.2. IPv6 Literals ......................................12
3.1.3. Internationalization ...............................13
3.1.4. Resolution for Comparison ..........................14
3.2. Port Numbers and Service Names ............................14
3.3. URIs ......................................................15
3.3.1. Scheme Component ...................................16
3.3.2. Authority Component ................................16
3.3.3. Path Component .....................................17
3.3.4. Query Component ....................................17
3.3.5. Fragment Component .................................17
3.3.6. Resolution for Comparison ..........................18
3.4. Email Address-Like Identifiers ............................18
4. General Issues .................................................19
4.1. Conflation ................................................19
4.2. Internationalization ......................................20
4.3. Scope .....................................................21
4.4. Temporality ...............................................21
5. Security Considerations ........................................22
6. Acknowledgements ...............................................22
7. IAB Members at the Time of Approval ............................23
8. Informative References .........................................23
1. Introduction ....................................................3
1.1. Classes of Identifiers .....................................5
1.2. Canonicalization ...........................................5
2. Identifier Use in Security Policies and Decisions ...............6
2.1. False Positives and Negatives ..............................7
2.2. Hypothetical Example .......................................8
3. Comparison Issues with Common Identifiers .......................9
3.1. Hostnames ..................................................9
3.1.1. IPv4 Literals ......................................11
3.1.2. IPv6 Literals ......................................12
3.1.3. Internationalization ...............................13
3.1.4. Resolution for Comparison ..........................14
3.2. Port Numbers and Service Names ............................14
3.3. URIs ......................................................15
3.3.1. Scheme Component ...................................16
3.3.2. Authority Component ................................16
3.3.3. Path Component .....................................17
3.3.4. Query Component ....................................17
3.3.5. Fragment Component .................................17
3.3.6. Resolution for Comparison ..........................18
3.4. Email Address-Like Identifiers ............................18
4. General Issues .................................................19
4.1. Conflation ................................................19
4.2. Internationalization ......................................20
4.3. Scope .....................................................21
4.4. Temporality ...............................................21
5. Security Considerations ........................................22
6. Acknowledgements ...............................................22
7. IAB Members at the Time of Approval ............................23
8. Informative References .........................................23
In computing and the Internet, various types of "identifiers" are used to identify humans, devices, content, etc. This document provides a discussion of some security issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols. Before discussing these security issues, we first give some background on some typical processes involving identifiers. Terms such as "identifier", "identity", and "principal" are used as defined in [RFC4949].
在计算和互联网中，各种类型的“标识符”被用来标识人、设备、内容等。该文档提供了一些设计者在定义标识符和协议时应考虑的安全问题，以及在构建使用多个协议的体系结构时应考虑的一些安全问题。在讨论这些安全问题之前，我们首先介绍一些涉及标识符的典型过程的背景知识。如[RFC4949]中所定义，使用“标识符”、“标识”和“主体”等术语。
As depicted in Figure 1, there are multiple processes relevant to our discussion.
如图1所示，有多个过程与我们的讨论相关。
1. An identifier is first generated. If the identifier is intended to be unique, the generation process must include some mechanism, such as allocation by a central authority or verification among the members of a distributed authority, to help ensure uniqueness. However, the notion of "unique" involves determining whether a putative identifier matches any other identifier that has already been allocated. As we will see, for many types of identifiers, this is not simply an exact binary match.
1. 首先生成一个标识符。如果标识符是唯一的，那么生成过程必须包括一些机制，例如中央机构的分配或分布式机构成员之间的验证，以帮助确保唯一性。然而，“唯一”的概念涉及确定假定标识符是否与已分配的任何其他标识符匹配。正如我们将看到的，对于许多类型的标识符，这不仅仅是一个精确的二进制匹配。
After generating the identifier, it is often stored in two locations: with the requester or "holder" of the identifier, and with some repository of identifiers (e.g., DNS). For example, if the identifier was allocated by a central authority, the repository might be that authority. If the identifier identifies a device or content on a device, the repository might be that device.
生成标识符后，它通常存储在两个位置：与标识符的请求者或“持有者”一起，与标识符的某些存储库（例如，DNS）一起。例如，如果标识符是由中央机构分配的，则存储库可能就是该机构。如果标识符标识设备或设备上的内容，则存储库可能就是该设备。
2. The identifier is distributed, either by the holder of the identifier or by a repository of identifiers, to others who could use the identifier. This distribution might be electronic, but sometimes it is via other channels such as voice, business card, billboard, or other form of advertisement. The identifier itself might be distributed directly, or it might be used to generate a portion of another type of identifier that is then distributed. For example, a URI or email address might include a server name, and hence distributing the URI or email address also inherently distributes the server name.
2. 标识符由标识符持有者或标识符存储库分发给可以使用该标识符的其他人。这种分发可能是电子的，但有时是通过其他渠道，如语音、名片、广告牌或其他形式的广告。标识符本身可以直接分发，也可以用来生成另一种类型的标识符的一部分，然后再分发。例如，URI或电子邮件地址可能包含服务器名称，因此分发URI或电子邮件地址也会固有地分发服务器名称。
3. The identifier is used by some party. Generally, the user supplies the identifier, which is (directly or indirectly) sent to the repository of identifiers. The repository of identifiers must then attempt to match the user-supplied identifier with an identifier in its repository.
3. 该标识符由某一方使用。通常，用户提供标识符，该标识符（直接或间接）发送到标识符存储库。然后，标识符存储库必须尝试将用户提供的标识符与其存储库中的标识符相匹配。
For example, using an email address to send email to the holder of an identifier may result in the email arriving at the holder's email server, which has access to the mail stores.
例如，使用电子邮件地址向标识符的持有者发送电子邮件可能导致电子邮件到达持有者的电子邮件服务器，该服务器可以访问邮件存储。
+------------+
| Holder of | 1. Generation
| identifier +<---------+
+----+-------+ |
| | Match
| v/
| +-------+-------+
+----------+ Repository of |
| | identifiers |
| +-------+-------+
2. Distribution | ^\
| | Match
v |
+---------+-------+ |
| User of | |
| identifier +----------+
+-----------------+ 3. Use
+------------+
| Holder of | 1. Generation
| identifier +<---------+
+----+-------+ |
| | Match
| v/
| +-------+-------+
+----------+ Repository of |
| | identifiers |
| +-------+-------+
2. Distribution | ^\
| | Match
v |
+---------+-------+ |
| User of | |
| identifier +----------+
+-----------------+ 3. Use
Figure 1: Typical Identifier Processes
图1：典型标识符过程
Another variation is where a user is given the identifier of a resource (e.g., a web site) to access securely, sometimes known as a "reference identifier" [RFC6125], and the server hosting the resource then presents its identity at the time of use. In this case, the user application attempts to match the presented identity against the reference identifier.
另一种变体是，向用户提供安全访问的资源（例如网站）标识符，有时称为“参考标识符”[RFC6125]，托管资源的服务器随后在使用时显示其标识。在这种情况下，用户应用程序尝试将显示的标识与引用标识符相匹配。
One key aspect is that the identifier values passed in generation, distribution, and use may all be in different forms. For example, an identifier might be exchanged in printed form at generation time, distributed to a user via voice, and then used electronically. As such, the match process can be complicated.
一个关键方面是，在生成、分发和使用中传递的标识符值可能都是不同的形式。例如，标识符可以在生成时以打印形式交换，通过语音分发给用户，然后以电子方式使用。因此，匹配过程可能会很复杂。
Furthermore, in many cases, the relationship between holder, repositories, and users may be more involved. For example, when a hierarchy of web caches exists, each cache is itself a repository of a sort, and the match process is usually intended to be the same as on the origin server.
此外，在许多情况下，持有者、存储库和用户之间的关系可能更复杂。例如，当存在web缓存的层次结构时，每个缓存本身就是一个排序的存储库，匹配过程通常与源服务器上的匹配过程相同。
Another aspect to keep in mind is that there can be multiple identifiers that refer to the same object (i.e., resource, human, device, etc.). For example, a human might have a passport number and a drivers license number, and an RFC might be available at multiple locations (rfc-editor.org and ietf.org). In this document, we focus
要记住的另一个方面是，可以有多个标识符引用同一对象（即，资源、人员、设备等）。例如，一个人可能有护照号码和驾驶执照号码，RFC可能在多个位置（RFC-editor.org和ietf.org）可用。在本文件中，我们将重点介绍
on comparing two identifiers to see whether they are the same identifier, rather than comparing two different identifiers to see whether they refer to the same entity (although a few issues with the latter are touched on in several places, such as Sections 3.1.4 and 3.3.6).
比较两个标识符以确定它们是否是相同的标识符，而不是比较两个不同的标识符以确定它们是否引用相同的实体（尽管后者的一些问题在一些地方有所涉及，如第3.1.4节和第3.3.6节）。
In this document, we will refer to the following classes of identifiers:
在本文件中，我们将参考以下类别的标识符：
o Absolute: identifiers that can be compared byte-by-byte for equality. Two identifiers that have different bytes are defined to be different. For example, binary IP addresses are in this class.
o 绝对值：可以逐字节比较以获得相等值的标识符。具有不同字节的两个标识符被定义为不同的。例如，二进制IP地址在这个类中。
o Definite: identifiers that have a single well-defined comparison algorithm. For example, URI scheme names are required to be US-ASCII [USASCII] and are defined to match in a case-insensitive way; the comparison is thus definite, since there is a well-specified algorithm (Section 9.2.1 of [RFC4790]) on how to do a case-insensitive match among ASCII strings.
o 明确的：具有单个明确定义的比较算法的标识符。例如，URI方案名称必须是US-ASCII[USASCII]，并且定义为以不区分大小写的方式匹配；因此，比较是确定的，因为有一个明确的算法（RFC4790的第9.2.1节）来说明如何在ASCII字符串之间进行不区分大小写的匹配。
o Indefinite: identifiers that have no single well-defined comparison algorithm. For example, human names are in this class. Everyone might want the comparison to be tailored for their locale, for some definition of "locale". In some cases, there may be limited subsets of parties that might be able to agree (e.g., ASCII users might all agree on a common comparison algorithm, whereas users of other Roman-derived scripts, such as Turkish, may not), but identifiers often tend to leak out of such limited environments.
o 不确定：没有单一明确定义的比较算法的标识符。例如，人名在这个类中。每个人都可能希望根据自己的语言环境，根据“语言环境”的某些定义进行比较。在某些情况下，可能会有有限的各方子集能够达成一致（例如，ASCII用户可能都同意一个通用的比较算法，而其他罗马衍生脚本（如土耳其）的用户可能不同意），但标识符往往会从这种有限的环境中泄漏出来。
Perhaps the most common algorithm for comparison involves first converting each identifier to a canonical form (a process known as "canonicalization" or "normalization") and then testing the resulting canonical representations for bitwise equality. In so doing, it is thus critical that all entities involved agree on the same canonical form and use the same canonicalization algorithm so that the overall comparison process is also the same.
最常见的比较算法可能包括首先将每个标识符转换为规范形式（一个称为“规范化”或“规范化”的过程），然后测试生成的规范表示的位相等性。因此，在这样做的过程中，关键是所有涉及的实体都同意相同的规范形式，并使用相同的规范化算法，以便整体比较过程也是相同的。
Note that in some contexts, such as in internationalization, the terms "canonicalization" and "normalization" have a precise meaning. In this document, however, we use these terms synonymously in their more generic form, to mean conversion to some standard form.
请注意，在某些上下文中，例如在国际化中，“规范化”和“规范化”具有精确的含义。然而，在本文档中，我们以更通用的形式同义使用这些术语，以表示转换为某种标准形式。
While the most common method of comparison includes canonicalization, comparison can also be done by defining an equivalence algorithm, where no single form is canonical. However, in most cases, a canonical form is useful for other purposes, such as output, and so in such cases defining a canonical form suffices to define a comparison method.
虽然最常见的比较方法包括规范化，但也可以通过定义一个等价算法来进行比较，其中没有单一形式是规范化的。然而，在大多数情况下，规范形式对于其他用途（如输出）是有用的，因此在这种情况下，定义规范形式就足以定义比较方法。
Identifiers such as hostnames, URIs, and email addresses are used in security contexts to identify security principals (i.e., entities that can be authenticated) and resources as well as other security parameters such as types and values of claims. Those identifiers are then used to make security decisions based on an identifier presented via some protocol. For example:
在安全上下文中使用诸如主机名、URI和电子邮件地址之类的标识符来标识安全主体（即可以进行身份验证的实体）和资源以及诸如声明的类型和值之类的其他安全参数。然后，这些标识符用于根据通过某个协议呈现的标识符做出安全决策。例如：
o Authentication: a protocol might match a security principal's identifier to look up expected keying material and then match keying material.
o 身份验证：协议可能匹配安全主体的标识符以查找预期的密钥材料，然后匹配密钥材料。
o Authorization: a protocol might match a resource name against some policy. For example, it might look up an access control list (ACL) and then look up the security principal's identifier (or a surrogate for it) in that ACL.
o 授权：协议可能会根据某些策略匹配资源名称。例如，它可能会查找访问控制列表（ACL），然后在该ACL中查找安全主体的标识符（或其代理）。
o Accounting: a system might create an accounting record for a security principal's identifier or resource name, and then might later need to match a presented identifier to (for example) add new filtering rules based on the records in order to stop an attack.
o 记帐：系统可能会为安全主体的标识符或资源名称创建记帐记录，然后稍后可能需要匹配显示的标识符（例如）根据记录添加新的筛选规则以阻止攻击。
If the parties involved in a security decision use different matching algorithms for the same identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result, as we will see.
如果参与安全决策的各方对相同的标识符使用不同的匹配算法，那么可能会导致从拒绝服务到提升权限的失败场景，我们将看到这一点。
This is especially complicated in cases involving multiple parties and multiple protocols. For example, there are many scenarios where some form of "security token service" is used to grant to a requester permission to access a resource, where the resource is held by a third party that relies on the security token service (see Figure 2). The protocol used to request permission (e.g., Kerberos or OAuth) may be different from the protocol used to access the resource (e.g., HTTP). Opportunities for security problems arise when two protocols define different comparison algorithms for the same type of identifier, or when a protocol is ambiguously specified and two endpoints (e.g., a security token service and a resource holder) implement different algorithms within the same protocol.
这在涉及多方和多协议的情况下尤其复杂。例如，有许多场景使用某种形式的“安全令牌服务”向请求者授予访问资源的权限，其中资源由依赖安全令牌服务的第三方持有（见图2）。用于请求权限的协议（例如Kerberos或OAuth）可能不同于用于访问资源的协议（例如HTTP）。当两个协议为同一类型的标识符定义不同的比较算法时，或者当一个协议被含糊地指定并且两个端点（例如，安全令牌服务和资源持有者）在同一协议中实现不同的算法时，就会出现安全问题。
+----------+
| security |
| token |
| service |
+----------+
^
| 1. supply credentials and
| get token for resource
| +--------+
+----------+ 2. supply token and access resource |resource|
|requester |=------------------------------------->| holder |
+----------+ +--------+
+----------+
| security |
| token |
| service |
+----------+
^
| 1. supply credentials and
| get token for resource
| +--------+
+----------+ 2. supply token and access resource |resource|
|requester |=------------------------------------->| holder |
+----------+ +--------+
Figure 2: Simple Security Exchange
图2：简单安全交换
In many cases, the situation is more complex. With X.509 Public Key Infrastructure (PKIX) certificates [RFC6125], for example, the name in a certificate gets compared against names in ACLs or other things. In the case of web site security, the name in the certificate gets compared to a portion of the URI that a user may have typed into a browser. The fact that many different people are doing the typing, on many different types of systems, complicates the problem.
在许多情况下，情况更加复杂。例如，使用X.509公钥基础设施（PKIX）证书[RFC6125]，可以将证书中的名称与ACL或其他内容中的名称进行比较。在web站点安全的情况下，证书中的名称将与用户可能在浏览器中键入的URI的一部分进行比较。事实上，许多不同的人在许多不同类型的系统上进行打字，这使问题变得复杂。
Add to this the certificate enrollment step, and the certificate issuance step, and two more parties have an opportunity to adjust the encoding, or worse, the software that supports them might make changes that the parties are unaware are happening.
再加上证书注册步骤和证书颁发步骤，另外两方就有机会调整编码，或者更糟的是，支持它们的软件可能会做出双方都不知道正在发生的更改。
It is first worth discussing in more detail the effects of errors in the comparison algorithm. A "false positive" results when two identifiers compare as if they were equal but in reality refer to two different objects (e.g., security principals or resources). When privilege is granted on a match, a false positive thus results in an elevation of privilege -- for example, allowing execution of an operation that should not have been permitted otherwise. When privilege is denied on a match (e.g., matching an entry in a block/deny list or a revocation list), a permissible operation is denied. At best, this can cause worse performance (e.g., a cache miss or forcing redundant authentication) and at worst can result in a denial of service.
首先值得更详细地讨论比较算法中错误的影响。当两个标识符进行比较时，如果它们相等，但实际上指的是两个不同的对象（例如，安全主体或资源），则会出现“假阳性”结果。当对匹配项授予特权时，误报会导致特权提升——例如，允许执行本不允许执行的操作。当在匹配中拒绝特权时（例如，匹配阻止/拒绝列表或撤销列表中的条目），允许的操作将被拒绝。在最好的情况下，这可能会导致性能下降（例如，缓存未命中或强制进行冗余身份验证），在最坏的情况下可能会导致拒绝服务。
A "false negative" results when two identifiers that in reality refer to the same thing compare as if they were different, and the effects are the reverse of those for false positives. That is, when privilege is granted on a match, the result is at best worse performance and at worst a denial of service; when privilege is denied on a match, elevation of privilege results.
“假阴性”是指两个标识符在实际中引用同一事物时进行比较，就好像它们是不同的一样，其效果与假阳性相反。也就是说，当对匹配授予特权时，结果最好是性能更差，最坏是拒绝服务；当对匹配项拒绝特权时，将导致特权提升。
Figure 3 summarizes these effects.
图3总结了这些影响。
| "Grant on match" | "Deny on match"
---------------+------------------------+-----------------------
False positive | Elevation of privilege | Denial of service
---------------+------------------------+-----------------------
False negative | Denial of service | Elevation of privilege
---------------+------------------------+-----------------------
| "Grant on match" | "Deny on match"
---------------+------------------------+-----------------------
False positive | Elevation of privilege | Denial of service
---------------+------------------------+-----------------------
False negative | Denial of service | Elevation of privilege
---------------+------------------------+-----------------------
Figure 3: Worst Effects of False Positives/Negatives
图3：误报/漏报的最坏影响
When designing a comparison algorithm, one can typically modify it to increase the likelihood of false positives and decrease the likelihood of false negatives, or vice versa. Which outcome is better depends on the context.
在设计比较算法时，通常可以对其进行修改，以增加误报的可能性并降低误报的可能性，反之亦然。哪种结果更好取决于上下文。
Elevation of privilege is almost always seen as far worse than denial of service. Hence, for URIs, for example, Section 6.1 of [RFC3986] states that "comparison methods are designed to minimize false negatives while strictly avoiding false positives".
特权的提升几乎总是被认为比拒绝服务更糟糕。因此，例如，对于URI，[RFC3986]的第6.1节规定“比较方法旨在最小化误报，同时严格避免误报”。
Thus, URIs were defined with a "grant privilege on match" paradigm in mind, where it is critical to prevent elevation of privilege while minimizing denial of service. Using URIs in a "deny privilege on match" system can thus be problematic.
因此，URI的定义考虑了“匹配时授予特权”的范例，在这种范例中，在最大限度地减少拒绝服务的同时防止特权提升是至关重要的。因此，在“拒绝匹配特权”系统中使用URI可能会有问题。
In this example, both security principals and resources are
identified using URIs. Foo Corp has paid example.com for access to
the Stuff service. Foo Corp allows its employees to create accounts
on the Stuff service. Alice gets the account
"http://example.com/Stuff/FooCorp/alice" and Bob gets
"http://example.com/Stuff/FooCorp/bob". It turns out, however, that
Foo Corp's URI canonicalizer includes URI fragment components in
comparisons whereas example.com's does not, and Foo Corp does not
disallow the # character in the account name. So Chuck, who is a
malicious employee of Foo Corp, asks to create an account at
example.com with the name alice#stuff. Foo Corp's URI logic checks
its records for accounts it has created with stuff and sees that
there is no account with the name alice#stuff. Hence, in its
In this example, both security principals and resources are
identified using URIs. Foo Corp has paid example.com for access to
the Stuff service. Foo Corp allows its employees to create accounts
on the Stuff service. Alice gets the account
"http://example.com/Stuff/FooCorp/alice" and Bob gets
"http://example.com/Stuff/FooCorp/bob". It turns out, however, that
Foo Corp's URI canonicalizer includes URI fragment components in
comparisons whereas example.com's does not, and Foo Corp does not
disallow the # character in the account name. So Chuck, who is a
malicious employee of Foo Corp, asks to create an account at
example.com with the name alice#stuff. Foo Corp's URI logic checks
its records for accounts it has created with stuff and sees that
there is no account with the name alice#stuff. Hence, in its
records, it associates the account alice#stuff with Chuck and will only issue tokens good for use with "http://example.com/Stuff/FooCorp/alice#stuff" to Chuck.
记录后，它会将帐户alice#stuff与Chuck关联，并且只会发行用于“的代币”http://example.com/Stuff/FooCorp/alice#stuff“给恰克。
Chuck, the attacker, goes to a security token service at Foo Corp and asks for a security token good for "http://example.com/Stuff/FooCorp/alice#stuff". Foo Corp issues the token, since Chuck is the legitimate owner (in Foo Corp's view) of the alice#stuff account. Chuck then submits the security token in a request to "http://example.com/Stuff/FooCorp/alice".
攻击者Chuck前往Foo Corp的安全令牌服务，要求提供一个安全令牌，用于“http://example.com/Stuff/FooCorp/alice#stuff". Foo Corp发行代币，因为Chuck是alice#stuff账户的合法所有者（在Foo Corp看来）。Chuck然后在请求中将安全令牌提交给“http://example.com/Stuff/FooCorp/alice".
But example.com uses a URI canonicalizer that, for the purposes of checking equality, ignores fragments. So when example.com looks in the security token to see if the requester has permission from Foo Corp to access the given account, it successfully matches the URI in the security token, "http://example.com/Stuff/FooCorp/alice#stuff", with the requested resource name "http://example.com/Stuff/FooCorp/alice".
但是example.com使用一个URI规范化程序，为了检查相等性，它会忽略片段。因此，当example.com查找安全令牌以查看请求者是否具有Foo Corp访问给定帐户的权限时，它会成功匹配安全令牌中的URI，”http://example.com/Stuff/FooCorp/alice#stuff，具有请求的资源名称http://example.com/Stuff/FooCorp/alice".
Leveraging the inconsistencies in the canonicalizers used by Foo Corp and example.com, Chuck is able to successfully launch an elevation-of-privilege attack and access Alice's resource.
Chuck利用Foo Corp和example.com使用的规范化程序中的不一致性，成功发起提升权限攻击并访问Alice的资源。
Furthermore, consider an attacker using a similar corporation, such as "foocorp" (or any variation containing a non-ASCII character that some humans might expect to represent the same corporation). If the resource holder treats them as different but the security token service treats them as the same, then elevation of privilege can occur in this scenario as well.
此外，考虑攻击者使用类似的公司，如“FooCLP”（或任何变种包含非ASCII字符，一些人可能期望代表同一公司）。如果资源持有者将它们视为不同的，但安全令牌服务将它们视为相同的，那么在这种情况下也会发生权限提升。
In this section, we walk through a number of common types of identifiers and discuss various issues related to comparison that may affect security whenever they are used to identify security principals or resources. These examples illustrate common patterns that may arise with other types of identifiers.
在本节中，我们将介绍一些常见类型的标识符，并讨论与比较相关的各种问题，这些问题在使用它们识别安全主体或资源时可能会影响安全性。这些示例说明了其他类型的标识符可能出现的常见模式。
Hostnames (composed of dot-separated labels) are commonly used either directly as identifiers, or as components in identifiers such as in URIs and email addresses. Another example is in Sections 7.2 and 7.3 of [RFC5280] (and updated in Section 3 of [RFC6818]), which specify use in PKIX certificates.
主机名（由点分隔的标签组成）通常直接用作标识符，或用作标识符（如URI和电子邮件地址）中的组件。另一个例子是[RFC5280]第7.2节和第7.3节（并在[RFC6818]第3节中更新），其中规定了PKIX证书的使用。
In this section, we discuss a number of issues in comparing strings that appear to be some form of hostname.
在本节中，我们将讨论比较似乎是某种形式的主机名的字符串时的一些问题。
It is first worth pointing out that the term "hostname" itself is often ambiguous, and hence it is important that any use clarify which definition is intended. Some examples of definitions include:
首先值得指出的是，术语“主机名”本身往往是模棱两可的，因此，任何使用都必须澄清其定义。定义的一些例子包括：
a. A Fully Qualified Domain Name (FQDN),
a. 完全限定域名（FQDN），
b. An FQDN that is associated with address records in the DNS,
b. 与DNS中的地址记录关联的FQDN，
c. The leftmost label in an FQDN, or
c. FQDN中最左边的标签，或
d. The leftmost label in an FQDN that is associated with address records.
d. FQDN中与地址记录关联的最左侧标签。
The use of different definitions in different places results in questions such as whether "example" and "example.com" are considered equal or not, and hence it is important when writing new specifications to be clear about which definition is meant.
在不同的地方使用不同的定义会导致诸如“example”和“example.com”是否被视为相等的问题，因此在编写新规范时，明确定义的含义非常重要。
Section 3 of [RFC6055] discusses the differences between a "hostname" and a "DNS name", where the former is a subset of the latter by using a restricted set of characters (letters, digits, and hyphens). If one canonicalizer uses the "DNS name" definition whereas another uses a "hostname" definition, a name might be valid in the former but invalid in the latter. As long as invalid identifiers are denied privilege, this difference will not result in elevation of privilege.
[RFC6055]第3节讨论了“主机名”和“DNS名称”之间的区别，其中前者是后者的子集，使用一组受限字符（字母、数字和连字符）。如果一个规范化程序使用“DNS名称”定义，而另一个使用“主机名”定义，则名称在前者中可能有效，但在后者中可能无效。只要无效标识符被拒绝，这种差异就不会导致特权的提升。
Section 3.1 of [RFC1034] discusses the difference between a "complete" domain name, which ends with a dot (such as "example.com."), and a multi-label relative name such as "example.com" that assumes the root (".") is in the suffix search list. In most contexts, these are considered equal, but there may be issues if different entities in a security architecture have different interpretations of a relative domain name.
[RFC1034]第3.1节讨论了以点结尾的“完整”域名（如“example.com”）与多标签相对名称（如“example.com”）之间的区别，后者假定根（“.”）位于后缀搜索列表中。在大多数情况下，它们被认为是相等的，但如果安全体系结构中的不同实体对相对域名有不同的解释，则可能会出现问题。
[IAB1123] briefly discusses issues with the ambiguity around whether a label will be "alphabetic" -- including, among other issues, how "alphabetic" should be interpreted in an internationalized environment -- and whether a hostname can be interpreted as an IP address. We explore this last issue in more detail below.
[IAB1123]简要讨论了围绕标签是否为“字母”的模糊性问题，其中包括在国际化环境中如何解释“字母”以及主机名是否可以解释为IP地址。我们将在下面更详细地探讨最后一个问题。
Section 2.1 of [RFC1123] states:
[RFC1123]第2.1节规定：
Whenever a user inputs the identity of an Internet host, it SHOULD be possible to enter either (1) a host domain name or (2) an IP address in dotted-decimal ("#.#.#.#") form. The host SHOULD check the string syntactically for a dotted-decimal number before looking it up in the Domain Name System.
每当用户输入Internet主机的标识时，应该可以输入（1）主机域名或（2）带点十进制（“#.#.#.#”）形式的IP地址。在域名系统中查找字符串之前，主机应该先从语法上检查字符串是否有点十进制数。
and
和
This last requirement is not intended to specify the complete syntactic form for entering a dotted-decimal host number; that is considered to be a user-interface issue.
最后一个要求不是为了指定输入虚线十进制主机号的完整语法形式；这被认为是一个用户界面问题。
In specifying the inet_addr() API, the Portable Operating System Interface (POSIX) standard [IEEE-1003.1] defines "IPv4 dotted decimal notation" as allowing not only strings of the form "10.0.1.2" but also allowing octal and hexadecimal, and addresses with less than four parts. For example, "10.0.258", "0xA000102", and "012.0x102" all represent the same IPv4 address in standard "IPv4 dotted decimal" notation. We will refer to this as the "loose" syntax of an IPv4 address literal.
在指定inet_addr（）API时，可移植操作系统接口（POSIX）标准[IEEE-1003.1]将“IPv4点状十进制表示法”定义为不仅允许形式为“10.0.1.2”的字符串，还允许八进制和十六进制，以及少于四个部分的地址。例如，“10.0.258”、“0xA000102”和“012.0x102”都以标准的“IPv4点十进制”表示法表示相同的IPv4地址。我们将其称为IPv4地址文本的“松散”语法。
In Section 6.1 of [RFC3493], getaddrinfo() is defined to support the same (loose) syntax as inet_addr():
在[RFC3493]的第6.1节中，getaddrinfo（）被定义为支持与inet_addr（）相同的（松散的）语法：
If the specified address family is AF_INET or AF_UNSPEC, address strings using Internet standard dot notation as specified in inet_addr() are valid.
如果指定的地址族是AF_INET或AF_unsec，则使用INET_addr（）中指定的Internet标准点表示法的地址字符串有效。
In contrast, Section 6.3 of the same RFC states, specifying inet_pton():
相反，相同RFC的第6.3节规定了inet_pton（）：
If the af argument of inet_pton() is AF_INET, the src string shall be in the standard IPv4 dotted-decimal form:
如果inet_pton（）的af参数是af_inet，则src字符串应为标准十进制形式：
ddd.ddd.ddd.ddd
ddd.ddd.ddd.ddd
where "ddd" is a one to three digit decimal number between 0 and 255. The inet_pton() function does not accept other formats (such as the octal numbers, hexadecimal numbers, and fewer than four numbers that inet_addr() accepts).
其中，“ddd”是介于0和255之间的一到三位十进制数。inet_pton（）函数不接受其他格式（如八进制数、十六进制数以及inet_addr（）接受的少于四个数）。
As shown above, inet_pton() uses what we will refer to as the "strict" form of an IPv4 address literal. Some platforms also use the strict form with getaddrinfo() when the AI_NUMERICHOST flag is passed to it.
如上所示，inet_pton（）使用我们称之为IPv4地址文本的“严格”形式。当AI_NumeriHost标志传递给某些平台时，它还使用getaddrinfo（）的严格形式。
Both the strict and loose forms are standard forms, and hence a protocol specification is still ambiguous if it simply defines a string to be in the "standard IPv4 dotted decimal form". And, as a result of these differences, names such as "10.11.12" are ambiguous as to whether they are an IP address or a hostname, and even "10.11.12.13" can be ambiguous because of the "SHOULD" in the above text from RFC 1123, making it optional whether to treat it as an address or a DNS name.
严格形式和松散形式都是标准形式，因此，如果协议规范只是将字符串定义为“标准十进制形式”，那么它仍然是不明确的。而且，由于这些差异，诸如“10.11.12”之类的名称在它们是IP地址还是主机名方面模棱两可，甚至“10.11.12.13”也可能模棱两可，因为RFC 1123的上述文本中有“应该”，这使得将其视为地址还是DNS名称是可选的。
Protocols and data formats that can use addresses in string form for security purposes need to resolve these ambiguities. For example, for the host component of URIs, Section 3.2.2 of [RFC3986] resolves the first ambiguity by only allowing the strict form and resolves the second ambiguity by specifying that it is considered an IPv4 address literal. New protocols and data formats should similarly consider using the strict form rather than the loose form in order to better match user expectations.
为了安全起见，可以使用字符串形式的地址的协议和数据格式需要解决这些歧义。例如，对于URI的主机组件，[RFC3986]的第3.2.2节通过仅允许严格形式来解决第一个歧义，并通过指定将其视为IPv4地址文本来解决第二个歧义。新的协议和数据格式应该类似地考虑使用严格的形式，而不是松散的形式，以便更好地匹配用户的期望。
A string might be valid under the "loose" definition but invalid under the "strict" definition. As long as invalid identifiers are denied privilege, this difference will not result in elevation of privilege. Some protocols, however, use strings that can be either an IP address literal or a hostname. Such strings are at best Definite identifiers, and often turn out to be Indefinite identifiers. (See Section 4.1 for more discussion.)
字符串可能在“松散”定义下有效，但在“严格”定义下无效。只要无效标识符被拒绝，这种差异就不会导致特权的提升。但是，有些协议使用的字符串可以是IP地址文字或主机名。这样的字符串充其量是确定的标识符，并且通常是不确定的标识符。（更多讨论请参见第4.1节。）
IPv6 addresses similarly have a wide variety of alternate but semantically identical string representations, as defined in Section 2.2 of [RFC4291] and Section 2 of [RFC6874]. As discussed in Section 3.2.5 of [RFC5952], this fact causes problems in security contexts if comparison (such as in PKIX certificates) is done between strings rather than between the binary representations of addresses.
IPv6地址同样具有多种可选但语义相同的字符串表示形式，如[RFC4291]第2.2节和[RFC6874]第2节所定义。如[RFC5952]第3.2.5节所述，如果在字符串之间而不是在地址的二进制表示之间进行比较（例如在PKIX证书中），则这一事实会在安全上下文中导致问题。
[RFC5952] specified a recommended canonical string format as an attempt to solve this problem, but it may not be ubiquitously supported at present. And, when strings can contain non-ASCII characters, the same issues (and more, since hexadecimal and colons are allowed) arise as with IPv4 literals.
[RFC5952]指定了推荐的规范字符串格式以尝试解决此问题，但目前可能不普遍支持该格式。而且，当字符串可以包含非ASCII字符时，也会出现与IPv4文本相同的问题（由于允许十六进制和冒号，因此还会出现更多问题）。
Whereas (binary) IPv6 addresses are Absolute identifiers, IPv6 address literals are Definite identifiers, since string-to-address conversion for IPv6 address literals is unambiguous.
虽然（二进制）IPv6地址是绝对标识符，但IPv6地址文本是确定标识符，因为IPv6地址文本的字符串到地址转换是明确的。
The IETF policy on character sets and languages [RFC2277] requires support for UTF-8 in protocols, and as a result many protocols now do support non-ASCII characters. When a hostname is sent in a UTF-8 field, there are a number of ways it may be encoded. For example, hostname labels might be encoded directly in UTF-8, or they might first be Punycode-encoded [RFC3492] or even percent-encoded from UTF-8.
IETF关于字符集和语言的策略[RFC2277]要求在协议中支持UTF-8，因此许多协议现在确实支持非ASCII字符。在UTF-8字段中发送主机名时，有多种编码方式。例如，主机名标签可能直接在UTF-8中编码，或者它们可能首先是Punycode编码[RFC3492]，甚至是UTF-8中的百分比编码。
For example, in URIs, Section 3.2.2 of [RFC3986] specifically allows for the use of percent-encoded UTF-8 characters in the hostname as well as the use of Internationalized Domain Names in Applications (IDNA) encoding [RFC3490] using the Punycode algorithm.
例如，在URI中，[RFC3986]第3.2.2节特别允许在主机名中使用百分比编码UTF-8字符，以及使用Punycode算法在应用程序中使用国际化域名（IDNA）编码[RFC3490]。
Percent-encoding is unambiguous for hostnames, since the percent character cannot appear in the strict definition of a "hostname", though it can appear in a DNS name.
对于主机名，百分比编码是明确的，因为百分比字符不能出现在“主机名”的严格定义中，尽管它可以出现在DNS名称中。
Punycode-encoded labels (or "A-labels"), on the other hand, can be ambiguous if hosts are actually allowed to be named with a name starting with "xn--", and false positives can result. While this may be extremely unlikely for normal scenarios, it nevertheless provides a possible vector for an attacker.
另一方面，如果允许主机的名称以“xn--”开头，则Punycode编码的标签（或“A标签”）可能不明确，并且可能导致误报。虽然这在正常情况下极不可能发生，但它为攻击者提供了一个可能的向量。
A hostname comparator thus needs to decide whether a Punycode-encoded label should or should not be considered a valid hostname label, and if so, then whether it should match a label encoded in some other form such as a percent-encoded Unicode label (U-label).
因此，主机名比较器需要确定Punycode编码的标签是否应被视为有效的主机名标签，如果是，则它是否应与以某种其他形式编码的标签匹配，例如百分比编码的Unicode标签（U-label）。
For example, Section 3 of "Transport Layer Security (TLS) Extensions: Extension Definitions" [RFC6066] states:
例如，“传输层安全（TLS）扩展：扩展定义”[RFC6066]的第3节说明：
"HostName" contains the fully qualified DNS hostname of the server, as understood by the client. The hostname is represented as a byte string using ASCII encoding without a trailing dot. This allows the support of internationalized domain names through the use of A-labels defined in [RFC5890]. DNS hostnames are case-insensitive. The algorithm to compare hostnames is described in [RFC5890], Section 2.3.2.4.
“主机名”包含客户端理解的服务器的完全限定DNS主机名。主机名使用ASCII编码表示为字节字符串，不带尾随点。这允许通过使用[RFC5890]中定义的A标签来支持国际化域名。DNS主机名不区分大小写。[RFC5890]第2.3.2.4节介绍了比较主机名的算法。
For some additional discussion of security issues that arise with internationalization, see Section 4.2 and [TR36].
有关国际化引起的安全问题的其他讨论，请参见第4.2节和[TR36]。
Some systems (specifically Java URLs [JAVAURL]) use the rule that if two hostnames resolve to the same IP address(es) then the hostnames are considered equal. That is, the canonicalization algorithm involves name resolution with an IP address being the canonical form.
一些系统（特别是JAVAURL[JAVAURL]）使用这样的规则：如果两个主机名解析为相同的IP地址，则认为主机名相等。也就是说，规范化算法涉及以IP地址为规范形式的名称解析。
For example, if resolution was done via DNS, and DNS contained:
例如，如果通过DNS进行解析，并且DNS包含：
example.com. IN A 10.0.0.6 example.net. CNAME example.com. example.org. IN A 10.0.0.6
example.com。在10.0.0.6示例.net中。CNAME example.com。example.org。在10.0.0.6中
then the algorithm might treat all three names as equal, even though the third name might refer to a different entity.
然后，算法可能会将所有三个名称视为相等，即使第三个名称可能引用不同的实体。
With the introduction of dynamic IP addresses; private IP addresses; multiple IP addresses per name; multiple address families (e.g., IPv4 vs. IPv6); devices that roam to new locations; commonly deployed DNS tricks that result in the answer depending on factors such as the requester's location and the load on the server whose address is returned; etc., this method of comparison cannot be relied upon. There is no guarantee that two names for the same host will resolve the name to the same IP addresses; nor that the addresses resolved refer to the same entity, such as when the names resolve to private IP addresses; nor even that the system has connectivity (and the willingness to wait for the delay) to resolve names at the time the answer is needed. The lifetime of the identifier, and of any cached state from a previous resolution, also affects security (see Section 4.4).
随着动态IP地址的引入；专用IP地址；每个名称有多个IP地址；多地址系列（例如IPv4与IPv6）；漫游到新地点的设备；通常部署的DNS技巧，根据请求者的位置和返回地址的服务器上的负载等因素得出答案；等等，这种比较方法是不可靠的。无法保证同一主机的两个名称会将该名称解析为相同的IP地址；解析的地址也不是指同一实体，例如当名称解析为私有IP地址时；甚至系统也不具备在需要答案时解析名称的连通性（以及等待延迟的意愿）。标识符的生存期以及以前解析的任何缓存状态的生存期也会影响安全性（参见第4.4节）。
In addition, a comparison mechanism that relies on the ability to resolve identifiers such as hostnames to other identifiers such as IP addresses leaks information about security decisions to outsiders if these queries are publicly observable. (See [PRIVACY-CONS] for a deeper discussion of information disclosure.)
此外，一种比较机制依赖于将诸如主机名之类的标识符解析为诸如IP地址之类的其他标识符的能力，如果这些查询是公开可见的，则会将有关安全决策的信息泄漏给外部人员。（有关信息披露的更深入讨论，请参见[PRIVACY-CONS]）
Finally, it is worth noting that resolving two identifiers to determine if they refer to the same entity can be thought of as a use of such identifiers, as opposed to actually comparing the identifiers themselves, which is the focus of this document.
最后，值得注意的是，解析两个标识符以确定它们是否引用同一实体可以被视为使用此类标识符，而不是实际比较标识符本身，这是本文档的重点。
Port numbers and service names are discussed in depth in [RFC6335]. Historically, there were port numbers, service names used in SRV records, and mnemonic identifiers for assigned port numbers (known as port "keywords" at [IANA-PORT]). The latter two are now unified, and
[RFC6335]中深入讨论了端口号和服务名称。历史上，SRV记录中使用了端口号、服务名称和指定端口号的助记符（在[IANA-port]中称为端口“关键字”）。后两者现在已经统一，并且
various protocols use one or more of these types in strings. For example, the common syntax used by many URI schemes allows port numbers but not service names. Some implementations of the getaddrinfo() API support strings that can be either port numbers or port keywords (but not service names).
各种协议在字符串中使用这些类型中的一种或多种。例如，许多URI方案使用的通用语法允许端口号，但不允许服务名称。getaddrinfo（）API的某些实现支持可以是端口号或端口关键字（但不是服务名称）的字符串。
For protocols that use service names that must be resolved, the issues are the same as those for resolution of addresses in Section 3.1.4. In addition, Section 5.1 of [RFC6335] clarifies that service names/port keywords must contain at least one letter. This prevents confusion with port numbers in strings where both are allowed.
对于使用必须解决的服务名称的协议，问题与第3.1.4节中解决地址的问题相同。此外，[RFC6335]第5.1节澄清了服务名称/端口关键字必须至少包含一个字母。这可以防止在允许端口号和端口号的字符串中混淆端口号。
This section looks at issues related to using URIs for security purposes. For example, Section 7.4 of [RFC5280] specifies comparison of URIs in certificates. Examples of URIs in security-token-based access control systems include WS-*, SAML 2.0 [OASIS-SAMLv2-CORE], and OAuth Web Resource Authorization Profiles (WRAP) [OAuth-WRAP]. In such systems, a variety of participants in the security infrastructure are identified by URIs. For example, requesters of security tokens are sometimes identified with URIs. The issuers of security tokens and the relying parties who are intended to consume security tokens are frequently identified by URIs. Claims in security tokens often have their types defined using URIs, and the values of the claims can also be URIs.
本节讨论与出于安全目的使用URI相关的问题。例如，[RFC5280]的第7.4节规定了证书中URI的比较。基于安全令牌的访问控制系统中的URI示例包括WS-*、SAML 2.0[OASIS-SAMLv2-CORE]和OAuth Web资源授权配置文件（WRAP）[OAuth WRAP]。在这样的系统中，uri标识了安全基础设施中的各种参与者。例如，安全令牌的请求者有时用URI标识。安全令牌的发行人和打算使用安全令牌的依赖方通常由URI标识。安全令牌中的声明通常使用URI定义其类型，声明的值也可以是URI。
URIs are defined with multiple components, each of which has its own rules. We cover each in turn below. However, it is also important to note that there exist multiple comparison algorithms. Section 6.2 of [RFC3986] states:
URI由多个组件定义，每个组件都有自己的规则。我们在下面依次介绍每一个。然而，值得注意的是，存在多种比较算法。[RFC3986]第6.2节规定：
A variety of methods are used in practice to test URI equivalence. These methods fall into a range, distinguished by the amount of processing required and the degree to which the probability of false negatives is reduced. As noted above, false negatives cannot be eliminated. In practice, their probability can be reduced, but this reduction requires more processing and is not cost-effective for all applications.
实践中使用了多种方法来测试URI等价性。这些方法属于一个范围，其区别在于所需的处理量和假阴性概率降低的程度。如上所述，不能消除假阴性。在实践中，它们的概率可以降低，但这种降低需要更多的处理，并且并非对所有应用程序都具有成本效益。
If this range of comparison practices is considered as a ladder, the following discussion will climb the ladder, starting with practices that are cheap but have a relatively higher chance of producing false negatives, and proceeding to those that have higher computational cost and lower risk of false negatives.
如果将这一系列比较实践视为一个阶梯，那么下面的讨论将沿着阶梯上升，首先是成本较低但产生假阴性概率相对较高的实践，然后是计算成本较高且假阴性风险较低的实践。
The ladder approach has both pros and cons. On the pro side, it allows some uses to optimize for security, and other uses to optimize for cost, thus allowing URIs to be applicable to a wide range of uses. A disadvantage is that when different approaches are taken by different components in the same system using the same identifiers, the inconsistencies can result in security issues.
阶梯式方法既有优点也有缺点。在专业方面，它允许一些用途为安全性进行优化，其他用途为成本进行优化，从而允许URI适用于广泛的用途。一个缺点是，当同一系统中的不同组件使用相同的标识符采取不同的方法时，不一致可能导致安全问题。
[RFC3986] defines URI schemes as being case-insensitive US-ASCII and in Section 6.2.2.1 specifies that scheme names should be normalized to lowercase characters.
[RFC3986]将URI方案定义为不区分大小写的US-ASCII，并在第6.2.2.1节中规定方案名称应规范化为小写字符。
New schemes can be defined over time. In general, however, two URIs with an unrecognized scheme cannot be safely compared. This is because the canonicalization and comparison rules for the other components may vary by scheme. For example, a new URI scheme might have a default port of X, and without that knowledge, a comparison algorithm cannot know whether "example.com" and "example.com:X" should be considered to match in the authority component. Hence, for security purposes, it is safest for unrecognized schemes to be treated as invalid identifiers. However, if the URIs are only used with a "grant access on match" paradigm, then unrecognized schemes can be supported by doing a generic case-sensitive comparison, at the expense of some false negatives.
随着时间的推移，可以定义新的方案。但是，一般来说，无法安全地比较两个具有无法识别的方案的URI。这是因为其他组件的规范化和比较规则可能因方案而异。例如，一个新的URI方案可能有一个默认端口X，如果不知道，比较算法就无法知道“example.com”和“example.com:X”是否应该在authority组件中被视为匹配。因此，出于安全目的，将未识别的方案视为无效标识符是最安全的。但是，如果URI仅与“匹配时授予访问权限”范例一起使用，则可以通过进行一般的区分大小写的比较来支持未识别的方案，但会导致一些误判。
The authority component is scheme-specific, but many schemes follow a common syntax that allows for userinfo, host, and port.
authority组件是特定于方案的，但许多方案遵循一种通用语法，允许用户信息、主机和端口。
Section 3.1 discusses issues with hostnames in general. In addition, Section 3.2.2 of [RFC3986] allows future changes using the IPvFuture production. As with IPv4 and IPv6 literals, IPvFuture formats may have issues with multiple semantically identical string representations and may also be semantically identical to an IPv4 or IPv6 address. As such, false negatives may be common if IPvFuture is used.
第3.1节讨论了主机名的一般问题。此外，[RFC3986]第3.2.2节允许将来使用IPV产品进行更改。与IPv4和IPv6文本一样，IPvFuture格式可能存在多个语义相同的字符串表示的问题，并且可能与IPv4或IPv6地址的语义相同。因此，如果使用IPvFuture，假阴性可能很常见。
See discussion in Section 3.2.
见第3.2节中的讨论。
[RFC3986] defines the userinfo production that allows arbitrary data about the user of the URI to be placed before '@' signs in URIs. For example, "ftp://alice:bob@example.com/bar" has the value "alice:bob" as its userinfo. When comparing URIs in a security context, one must decide whether to treat the userinfo as being significant or not. Some URI comparison services, for example, treat "ftp://alice:ick@example.com" and "ftp://example.com" as being equal.
[RFC3986]定义userinfo产品，该产品允许在URI中的“@”符号之前放置有关URI用户的任意数据。例如，”ftp://alice:bob@example.com/bar”的userinfo值为“alice:bob”。在安全上下文中比较URI时，必须决定是否将userinfo视为重要信息。一些URI比较服务，例如，处理“ftp://alice:ick@example.com“和”ftp://example.com“平等。
When the userinfo is treated as being significant, it has additional considerations (e.g., whether or not it is case sensitive), which we cover in Section 3.4.
当用户信息被视为重要信息时，它有额外的考虑因素（例如，它是否区分大小写），我们将在第3.4节中介绍。
[RFC3986] supports the use of path segment values such as "./" or "../" for relative URIs. As discussed in Section 6.2.2.3 of [RFC3986], they are intended only for use within a reference relative to some other base URI, but Section 5.2.4 of [RFC3986] nevertheless defines an algorithm to remove them as part of URI normalization.
[RFC3986]支持对相对URI使用路径段值，如“/”或“./”。如[RFC3986]第6.2.2.3节所述，它们仅用于与其他一些基本URI相关的引用中，但[RFC3986]第5.2.4节定义了一种算法，作为URI规范化的一部分删除它们。
Unless a scheme states otherwise, the path component is defined to be case sensitive. However, if the resource is stored and accessed using a filesystem using case-insensitive paths, there will be many paths that refer to the same resource. As such, false negatives can be common in this case.
除非方案另有说明，否则路径组件定义为区分大小写。但是，如果使用文件系统使用不区分大小写的路径存储和访问资源，那么将有许多路径引用同一资源。因此，在这种情况下，假阴性可能很常见。
There is the question as to whether "http://example.com/foo", "http://example.com/foo?", and "http://example.com/foo?bar" are each considered equal or different.
有一个问题是“是否”http://example.com/foo", "http://example.com/foo?“、和”http://example.com/foo?bar“每个都被认为是平等的或不同的。
Similarly, it is unspecified whether the order of values matters. For example, should "http://example.com/blah?ick=bick&foo=bar" be considered equal to "http://example.com/blah?foo=bar&ick=bick"? And if a domain name is permitted to appear in a query component (e.g., in a reference to another URI), the same issues in Section 3.1 apply.
同样，价值顺序是否重要也未明确。例如，“应该”http://example.com/blah?ick=bick&foo=bar“被认为等于”http://example.com/blah?foo=bar&ick=bick"? 如果允许域名出现在查询组件中（例如，在对另一个URI的引用中），则第3.1节中的相同问题也适用。
Some URI formats include fragment identifiers. These are typically handles to locations within a resource and are used for local reference. A classic example is the use of fragments in HTTP URIs where a URI of the form "http://example.com/blah.html#ick" means retrieve the resource "http://example.com/blah.html" and, once it has arrived locally, find the HTML anchor named "ick" and display that.
一些URI格式包括片段标识符。这些通常是资源中位置的句柄，用于本地引用。一个典型的例子是在HTTP URI中使用片段，其中URI的形式为“http://example.com/blah.html#ick“表示检索资源”http://example.com/blah.html并且，一旦它到达本地，找到名为“ick”的HTML锚并显示它。
So, for example, when a user clicks on the link "http://example.com/blah.html#baz", a browser will check its cache by doing a URI comparison for "http://example.com/blah.html" and, if the resource is present in the cache, a match is declared.
例如，当用户单击链接时“http://example.com/blah.html#baz，浏览器将通过对进行URI比较来检查其缓存http://example.com/blah.html并且，如果资源存在于缓存中，则声明匹配。
Hence, comparisons for security purposes typically ignore the fragment component and treat all fragments as equal to the full resource. However, if one were actually trying to compare the piece of a resource that was identified by the fragment identifier, ignoring it would result in potential false positives.
因此，出于安全目的的比较通常会忽略片段组件，并将所有片段视为等于完整资源。但是，如果一个人实际上试图比较由片段标识符标识的资源片段，忽略它将导致潜在的误报。
It may be tempting to define a URI comparison algorithm based on whether URIs resolve to the same content, along the lines of resolving hostnames as described in Section 3.1.4. However, such an algorithm would result in similar problems, including content that dynamically changes over time or that is based on factors such as the requester's location, potential lack of external connectivity at the time or place that comparison is done, introduction of potentially undesirable delay, etc.
按照第3.1.4节中描述的解析主机名的思路，根据URI是否解析为相同的内容来定义URI比较算法可能很有诱惑力。然而，这种算法将导致类似的问题，包括内容随时间动态变化或基于诸如请求者的位置、在进行比较的时间或地点可能缺乏外部连接、引入可能不希望的延迟等因素的内容。
In addition, as noted in Section 3.1.4, resolution leaks information about security decisions to outsiders if the queries are publicly observable.
此外，如第3.1.4节所述，如果查询是公开可见的，则处置会将有关安全决策的信息泄露给外部人员。
Section 3.4.1 of [RFC5322] defines the syntax of an email address-like identifier, and Section 3.2 of [RFC6532] updates it to support internationalization. Section 7.5 of [RFC5280] further discusses the use of internationalized email addresses in certificates.
[RFC5322]第3.4.1节定义了类似标识符的电子邮件地址的语法，[RFC6532]第3.2节对其进行了更新，以支持国际化。[RFC5280]第7.5节进一步讨论了证书中国际化电子邮件地址的使用。
Regarding the security impact of internationalized email headers, [RFC6532] points to Section 14 of [RFC6530], which contains a discussion of many issues resulting from internationalization.
关于国际化电子邮件头的安全影响，[RFC6532]指向[RFC6530]的第14节，其中包含对国际化导致的许多问题的讨论。
Email address-like identifiers have a local part and a domain part. The issues with the domain part are essentially the same as with hostnames, as covered earlier in Section 3.1.
像标识符一样的电子邮件地址有一个本地部分和一个域部分。域部分的问题与主机名的问题基本相同，如前面第3.1节所述。
The local part is left for each domain to define. People quite commonly use email addresses as usernames with web sites such as banks or shopping sites, but the site doesn't know whether foo@example.com is the same person as FOO@example.com. Thus, email address-like identifiers are typically Indefinite identifiers.
本地部分留给每个域定义。人们通常在银行或购物网站等网站上使用电子邮件地址作为用户名，但该网站不知道foo@example.com是同一个人吗FOO@example.com. 因此，类似电子邮件地址的标识符通常是不确定的标识符。
To avoid false positives, some security mechanisms (such as those described in [RFC5280]) compare the local part using an exact match. Hence, like URIs, email address-like identifiers are designed for use in grant-on-match security schemes, not in deny-on-match schemes.
为了避免误报，一些安全机制（如[RFC5280]中所述）使用精确匹配来比较本地部分。因此，与URI一样，类似电子邮件地址的标识符设计用于授予匹配安全方案，而不是拒绝匹配方案。
Furthermore, when such identifiers are actually used as email addresses, Section 2.4 of [RFC5321] states that the local part of a mailbox must be treated as case sensitive, but if a mailbox is stored and accessed using a filesystem using case-insensitive paths, there may be many paths that refer to the same mailbox. As such, false negatives can be common in this case.
此外，当此类标识符实际用作电子邮件地址时，[RFC5321]第2.4节规定邮箱的本地部分必须视为区分大小写，但如果使用不区分大小写路径的文件系统存储和访问邮箱，则可能有许多路径引用同一邮箱。因此，在这种情况下，假阴性可能很常见。
There are a number of examples (some in the preceding sections) of strings that conflate two types of identifiers, using some heuristic to try to determine which type of identifier is given. Similarly, two ways of encoding the same type of identifier might be conflated within the same string.
有许多将两种类型的标识符合并在一起的字符串示例（前几节中有一些示例），使用一些启发式方法尝试确定给定的标识符类型。类似地，同一类型标识符的两种编码方式可能会在同一字符串中合并。
Some examples include:
一些例子包括：
1. A string that might be an IPv4 address literal or an IPv6 address literal
1. 可能是IPv4地址文字或IPv6地址文字的字符串
2. A string that might be an IP address literal or a hostname
2. 可能是IP地址文字或主机名的字符串
3. A string that might be a port number or a service name
3. 可能是端口号或服务名称的字符串
4. A DNS label that might be literal or be Punycode-encoded
4. 一个DNS标签，可以是文字的，也可以是Punycode编码的
Strings that allow such conflation can only be considered Definite if there exists a well-defined rule to determine which identifier type is meant. One way to do so is to ensure that the valid syntax for the two is disjoint (e.g., distinguishing IPv4 vs. IPv6 address literals by the use of colons in the latter). A second way to do so is to define a precedence rule that results in some identifiers being inaccessible via a conflated string (e.g., a host literally named "xn--de-jg4avhby1noc0d" may be inaccessible due to the "xn--" prefix denoting the use of Punycode encoding). In some cases, such inaccessible space may be reserved so that the actual set of identifiers in use is unambiguous. For example, Section 2.5.5.2 of [RFC4291] defines a range of the IPv6 address space for representing IPv4 addresses.
只有当存在一个定义良好的规则来确定所指的标识符类型时，才可以认为允许这种合并的字符串是确定的。一种方法是确保两者的有效语法是不相交的（例如，通过在后者中使用冒号来区分IPv4和IPv6地址文字）。第二种方法是定义一个优先规则，该规则会导致某些标识符通过合并字符串无法访问（例如，由于“xn--de-jg4avhby1noc0d”前缀表示使用Punycode编码，因此字面上命名为“xn--de-jg4avhby1noc0d”的主机可能无法访问）。在某些情况下，可以保留这样的不可访问空间，以便使用中的标识符的实际集合是明确的。例如，[RFC4291]的第2.5.5.2节定义了表示IPv4地址的IPv6地址空间范围。
In addition to the issues with hostnames discussed in Section 3.1.3, there are a number of internationalization issues that apply to many types of Definite and Indefinite identifiers.
除了第3.1.3节中讨论的主机名问题外，还有许多国际化问题适用于许多类型的确定标识符和不确定标识符。
First, there is no DNS mechanism for identifying whether non-identical strings would be seen by a human as being equivalent. There are problematic examples even with US-ASCII (Basic Latin) strings, including regional spelling variations such as "color" and "colour", and with many non-English cases, including partially numeric strings in Arabic script contexts, Chinese strings in Simplified and Traditional forms, and so on. Attempts to produce such alternate forms algorithmically could produce false positives and hence have an adverse effect on security.
首先，没有DNS机制来识别人类是否会将不相同的字符串视为等效字符串。即使是US-ASCII（基本拉丁语）字符串，也有问题的例子，包括“color”和“color”等区域拼写变体，以及许多非英语案例，包括阿拉伯语脚本上下文中的部分数字字符串、简体和繁体形式的中文字符串，等等。试图通过算法生成这种替代形式可能会产生误报，从而对安全性产生不利影响。
Second, some strings are visually confusable with others, and hence if a security decision is made by a user based on visual inspection, many opportunities for false positives exist. As such, using visual inspection for security is unreliable. In addition to the security issues, visual confusability also adversely affects the usability of identifiers distributed via visual media. Similar issues can arise with audible confusability when using audio (e.g., for radio distribution, accessibility to the blind, etc.) in place of a visual medium. Furthermore, when strings conflate two types of identifiers as discussed in Section 4.1, allowing non-ASCII characters can cause one type of identifier to appear to a human as another type of identifier. For example, characters that may look like digits and dots may appear to be an IPv4 literal to a human (especially to one who might expect digits to appear in his or her native script). Hence, conflation often increases the chance of confusability.
其次，某些字符串在视觉上容易与其他字符串混淆，因此，如果用户基于视觉检查做出安全决策，则存在许多误报的机会。因此，使用目视检查进行安全检查是不可靠的。除了安全问题外，视觉混淆还对通过视觉媒体分发的标识符的可用性产生不利影响。当使用音频（例如，用于无线电传播、盲人可接近性等）代替视觉媒体时，类似的问题可能会出现声音混淆。此外，如第4.1节所述，当字符串将两种类型的标识符合并在一起时，允许使用非ASCII字符可能会导致一种类型的标识符在人的眼中显示为另一种类型的标识符。例如，看起来像数字和点的字符对人来说可能是IPv4文本（特别是对那些希望数字出现在其本机脚本中的人）。因此，混为一谈往往会增加混淆的机会。
Determining whether a string is a valid identifier should typically be done after, or as part of, canonicalization. Otherwise, an attacker might use the canonicalization algorithm to inject (e.g., via percent encoding, Normalization Form KC (NFKC), or non-shortest-form UTF-8) delimiters such as '@' in an email address-like identifier, or a '.' in a hostname.
确定字符串是否为有效标识符通常应在规范化之后或作为规范化的一部分进行。否则，攻击者可能会使用规范化算法（例如，通过百分比编码、标准化形式KC（NFKC）或非最短形式UTF-8）插入分隔符，如电子邮件地址（如标识符）中的“@”，或主机名中的“.”。
Any case-insensitive comparisons need to define how comparison is done, since such comparisons may vary by the locale of the endpoint. As such, using case-insensitive comparisons in general often results in identifiers being either Indefinite or, if the legal character set is restricted (e.g., to US-ASCII), Definite.
任何不区分大小写的比较都需要定义如何进行比较，因为这种比较可能因端点的区域设置而异。因此，使用不区分大小写的比较通常会导致标识符不确定，或者如果合法字符集受到限制（例如US-ASCII），则标识符是确定的。
See also [WEBER] for a more visual discussion of many of these issues.
另请参见[WEBER]，了解更多关于这些问题的可视化讨论。
Finally, the set of permitted characters and the canonical form of the characters (and hence the canonicalization algorithm) sometimes vary by protocol today, even when the intent is to use the same identifier, such as when one protocol passes identifiers to the other. See [RFC6885] for further discussion.
最后，允许的字符集和字符的规范形式（以及规范化算法）有时会因今天的协议而异，即使目的是使用相同的标识符，例如当一个协议将标识符传递给另一个协议时也是如此。有关进一步讨论，请参见[RFC6885]。
Another issue arises when an identifier (e.g., "localhost", "10.11.12.13", etc.) is not globally unique. Section 1.1 of [RFC3986] states:
当标识符（例如，“localhost”、“10.11.12.13”等）不是全局唯一的时，会出现另一个问题。[RFC3986]第1.1节规定：
URIs have a global scope and are interpreted consistently regardless of context, though the result of that interpretation may be in relation to the end-user's context. For example, "http://localhost/" has the same interpretation for every user of that reference, even though the network interface corresponding to "localhost" may be different for each end-user: interpretation is independent of access.
URI有一个全局范围，无论上下文如何，都会进行一致的解释，尽管这种解释的结果可能与最终用户的上下文有关。例如，”http://localhost/“对该引用的每个用户具有相同的解释，即使每个最终用户对应于“localhost”的网络接口可能不同：解释与访问无关。
Whenever an identifier that is not globally unique is passed to another entity outside of the scope of uniqueness, it will refer to a different resource and can result in a false positive. This problem is often addressed by using the identifier together with some other unique identifier of the context. For example, "alice" may uniquely identify a user within a system but must be used with "example.com" (as in "alice@example.com") to uniquely identify the context outside of that system.
当一个非全局唯一的标识符被传递到唯一性范围之外的另一个实体时，它将引用不同的资源，并可能导致误报。这个问题通常通过将标识符与上下文的其他唯一标识符一起使用来解决。例如，“alice”可以唯一标识系统中的用户，但必须与“example.com”一起使用（如中所示）alice@example.com）以唯一标识该系统外部的上下文。
It is also worth noting that IPv6 addresses that are not globally scoped can be written with, or otherwise associated with, a "zone ID" to identify the context (see [RFC4007] for more information). However, zone IDs are only unique within a host, so they typically narrow, rather than expand, the scope of uniqueness of the resulting identifier.
还值得注意的是，不具有全局作用域的IPv6地址可以使用“区域ID”写入或以其他方式与之关联，以标识上下文（有关更多信息，请参阅[RFC4007]）。但是，区域ID仅在主机内是唯一的，因此它们通常会缩小而不是扩大结果标识符的唯一性范围。
Often, identifiers are not unique across all time but have some lifetime associated with them after which they may be reassigned to another entity. For example, bob@example.com might be assigned to an employee of the Example company, but if he leaves and another Bob is later hired, the same identifier might be reused. As another example, IP address 203.0.113.1 might be assigned to one subscriber and then later reassigned to another subscriber. Security issues can arise if updates are not made in all entities that store the identifier (e.g., in an access control list as discussed in Section 2, or in a resolution cache as discussed in Section 3.1.4).
通常，标识符并非在所有时间都是唯一的，而是有一些与之相关联的生存期，之后可能会重新分配给另一个实体。例如bob@example.com可能会分配给示例公司的某个员工，但如果该员工离职后又雇佣了另一名Bob，则可能会重用相同的标识符。作为另一个示例，IP地址203.0.113.1可能分配给一个订户，然后再重新分配给另一个订户。如果未在存储标识符的所有实体（例如，第2节讨论的访问控制列表中，或第3.1.4节讨论的解析缓存中）中进行更新，则可能会出现安全问题。
This issue is similar to the issue of scope discussed in Section 4.3, except that the scope of uniqueness is temporal rather than topological.
该问题与第4.3节讨论的范围问题类似，只是唯一性的范围是时间性的，而不是拓扑性的。
This entire document is about security considerations.
整个文档都是关于安全方面的考虑。
To minimize issues related to elevation of privilege, any system that requires the ability to use both deny and allow operations within the same identifier space should avoid the use of Indefinite identifiers in security comparisons.
为了最大限度地减少与权限提升相关的问题，任何需要在同一标识符空间中同时使用deny和allow操作的系统都应该避免在安全性比较中使用不确定标识符。
To minimize future security risks, any new identifiers being designed should specify an Absolute or Definite comparison algorithm, and if extensibility is allowed (e.g., as new schemes in URIs allow), then the comparison algorithm should remain invariant so that unrecognized extensions can be compared. That is, security risks can be reduced by specifying the comparison algorithm, making sure to resolve any ambiguities pointed out in this document (e.g., "standard dotted decimal").
为了最大限度地降低未来的安全风险，正在设计的任何新标识符都应该指定一个绝对或明确的比较算法，如果允许扩展性（例如，URI中的新方案允许），那么比较算法应该保持不变，以便可以比较未识别的扩展。也就是说，可以通过指定比较算法来降低安全风险，确保解决本文档中指出的任何歧义（例如，“标准点十进制”）。
Some issues (such as unrecognized extensions) can be mitigated by treating such identifiers as invalid. Validity checking of identifiers is further discussed in [RFC3696].
一些问题（例如无法识别的扩展）可以通过将此类标识符视为无效来缓解。[RFC3696]中进一步讨论了标识符的有效性检查。
Perhaps the hardest issues arise when multiple protocols are used together, such as in Figure 2, where the two protocols are defined or implemented using different comparison algorithms. When constructing an architecture that uses multiple such protocols, designers should pay attention to any differences in comparison algorithms among the protocols in order to fully understand the security risks. How to deal with such security risks in current systems is an area for future work.
当同时使用多个协议时，可能会出现最困难的问题，如图2所示，其中使用不同的比较算法定义或实现了两个协议。在构建使用多个协议的体系结构时，设计者应注意协议之间比较算法的任何差异，以便充分了解安全风险。如何在现有系统中处理此类安全风险是未来工作的一个领域。
Yaron Goland contributed to the discussion on URIs. Patrik Faltstrom contributed to the background on identifiers. John Klensin contributed text in a number of different sections. Additional helpful feedback and suggestions came from Bernard Aboba, Fred Baker, Leslie Daigle, Mark Davis, Jeff Hodges, Bjoern Hoehrmann, Russ Housley, Christian Huitema, Magnus Nystrom, Tom Petch, and Chris Weber.
Yaron Goland对URI的讨论做出了贡献。Patrik Faltstrom对标识符的背景知识做出了贡献。约翰·克莱辛在许多不同的章节中贡献了这篇文章。其他有用的反馈和建议来自伯纳德·阿博巴、弗雷德·贝克、莱斯利·戴格尔、马克·戴维斯、杰夫·霍奇斯、比约恩·霍尔曼、罗斯·霍斯利、克里斯蒂安·惠特马、马格纳斯·奈斯特罗姆、汤姆·佩奇和克里斯·韦伯。
Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Spencer Dawkins Joel Halpern Russ Housley David Kessens Danny McPherson Jon Peterson Dave Thaler Hannes Tschofenig
伯纳德·阿博巴·贾里·阿尔科·马克·布兰切特·罗斯·卡隆·艾莉莎·库珀·斯宾塞·道金斯·乔尔·哈尔本·罗斯·霍斯利·大卫·凯森斯·丹尼·麦克弗森·乔恩·彼得森·戴夫·泰勒·汉内斯·茨霍芬尼
[IAB1123] Internet Architecture Board, "IAB Statement: 'The interpretation of rules in the ICANN gTLD Applicant Guidebook'", February 2012, <http://www.iab.org/documents/ correspondence-reports-documents/2012-2/iab-statement-the-interpretation-of-rules-in-the-icann-gtld-applicant-guidebook>.
[IAB1123]互联网架构委员会，“IAB声明：ICANN gTLD申请人指南中的规则解释”，2012年2月<http://www.iab.org/documents/ 通信报告文件/2012-2/iab声明icann gtld申请人指南>中规则的解释。
[IANA-PORT] IANA, "Service Name and Transport Protocol Port Number Registry", March 2013, <http://www.iana.org/assignments/service-names-port-numbers/>.
[IANA-PORT]IANA，“服务名称和传输协议端口号注册表”，2013年3月<http://www.iana.org/assignments/service-names-port-numbers/>.
[IEEE-1003.1] IEEE and The Open Group, "The Open Group Base Specifications, Issue 6, IEEE Std 1003.1, 2004 Edition", IEEE Std 1003.1, 2004.
[IEEE-1003.1]IEEE和开放组，“开放组基本规范，第6期，IEEE Std 1003.12004版”，IEEE Std 1003.12004。
[JAVAURL] Oracle, "Class URL", Java(TM) Platform Standard Ed. 7, 2013, <http://docs.oracle.com/javase/7/docs/api/java/net/ URL.html>.
[JAVAURL]Oracle，“类URL”，Java（TM）平台标准版，2013年第7版<http://docs.oracle.com/javase/7/docs/api/java/net/ URL.html>。
[OASIS-SAMLv2-CORE] Cantor, S., Ed., Kemp, J., Ed., Philpott, R., Ed., and E. Maler, Ed., "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, March 2005, <http://docs.oasis-open.org/security/saml/v2.0/ saml-core-2.0-os.pdf>.
[OASIS-SAMLv2-CORE]Cantor，S.，Ed.，Kemp，J.，Ed.，Philpott，R.，Ed.，和E.Maler，Ed.，“OASIS安全断言标记语言（SAML）V2.0的断言和协议”，OASIS标准SAML-CORE-2.0-os，2005年3月<http://docs.oasis-open.org/security/saml/v2.0/ saml-core-2.0-os.pdf>。
[OAuth-WRAP] Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth Web Resource Authorization Profiles", Work in Progress, January 2010.
[OAuth WRAP]Hardt，D.，Ed.，Tom，A.，Eaton，B.，和Y.Goland，“OAuth Web资源授权配置文件”，正在进行的工作，2010年1月。
[PRIVACY-CONS] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", Work in Progress, April 2013.
[PRIVACY-CONS]Cooper，A.，Tschofenig，H.，Aboba，B.，Peterson，J.，Morris，J.，Hansen，M.，和R.Smith，“互联网协议的隐私考虑”，正在进行的工作，2013年4月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC2277] Alvestrand, H.T., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277]Alvestrand，H.T.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]Costello，A.，“Punycode：应用程序中国际化域名的Unicode引导字符串编码（IDNA）”，RFC 3492，2003年3月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493]Gilligan，R.，Thomson，S.，Bound，J.，McCann，J.，和W.Stevens，“IPv6的基本套接字接口扩展”，RFC 3493，2003年2月。
[RFC3696] Klensin, J., "Application Techniques for Checking and Transformation of Names", RFC 3696, February 2004.
[RFC3696]Klensin，J.，“名称检查和转换的应用技术”，RFC 36962004年2月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.
[RFC4007]Deering，S.，Haberman，B.，Jinmei，T.，Nordmark，E.，和B.Zill，“IPv6作用域地址体系结构”，RFC 4007，2005年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, March 2007.
[RFC4790]Newman，C.，Duerst，M.，和A.Gulbrandsen，“互联网应用协议整理注册表”，RFC 47902007年3月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949]Shirey，R.，“互联网安全术语表，第2版”，RFC 49492007年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 59522010年8月。
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011.
[RFC6055]Thaler，D.，Klensin，J.，和S.Cheshire，“IAB对国际化域名编码的思考”，RFC 60552011年2月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066]Eastlake，D.，“传输层安全（TLS）扩展：扩展定义”，RFC6066，2011年1月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年3月。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 63352011年8月。
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.
[RFC6530]Klensin，J.和Y.Ko，“国际化电子邮件的概述和框架”，RFC6530，2012年2月。
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.
[RFC6532]Yang，A.，Steele，S.，和N.Freed，“国际化电子邮件标题”，RFC 6532，2012年2月。
[RFC6818] Yee, P., "Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 6818, January 2013.
[RFC6818]Yee，P.，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的更新”，RFC 6818，2013年1月。
[RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers", RFC 6874, February 2013.
[RFC6874]Carpenter，B.，Cheshire，S.和R.Hinden，“以地址文本和统一资源标识符表示IPv6区域标识符”，RFC 6874，2013年2月。
[RFC6885] Blanchet, M. and A. Sullivan, "Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS)", RFC 6885, March 2013.
[RFC6885]Blanchet，M.和A.Sullivan，“编制和比较国际化字符串（PRECIS）的Stringprep修订和问题声明”，RFC 68852013年3月。
[TR36] Unicode Consortium, "Unicode Security Considerations", Unicode Technical Report #36, Revision 11, July 2012, <http://www.unicode.org/reports/tr36/>.
[TR36]Unicode联盟，“Unicode安全注意事项”，Unicode技术报告#36，第11版，2012年7月<http://www.unicode.org/reports/tr36/>.
[USASCII] American National Standards Institute, "Coded Character Sets -- 7-bit American Standard Code for Information Interchange (7-bit ASCII)", ANSI X3.4, 1986.
[USASCII]美国国家标准协会，“编码字符集——信息交换用7位美国标准代码（7位ASCII）”，ANSI X3.41986。
[WEBER] Weber, C., "Attacking Software Globalization", March 2010, <http://www.lookout.net/files/ Chris_Weber_Character%20Transformations%20v1.7_IUC33.pdf>.
[WEBER]WEBER，C.，“攻击软件全球化”，2010年3月<http://www.lookout.net/files/ Chris_Weber_字符%20v1.7\u IUC33.pdf>。
Author's Address
作者地址
Dave Thaler (editor) Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Dave Thaler（编辑）微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com