Internet Engineering Task Force (IETF) P. Saint-Andre Request for Comments: 8265 Jabber.org Obsoletes: 7613 A. Melnikov Category: Standards Track Isode Ltd ISSN: 2070-1721 October 2017
互联网工程任务组（IETF）P.Saint Andre征求意见：8265 Jabber.org淘汰：7613 A.Melnikov类别：标准轨道Isode有限公司ISSN:2070-1721 2017年10月
Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords
表示用户名和密码的国际化字符串的准备、实施和比较
Abstract
摘要
This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. This document obsoletes RFC 7613.
本文档描述了处理表示用户名和密码的Unicode字符串的更新方法。之前的方法称为SASLprep（RFC 4013），基于Stringprep（RFC 3454）。本文档中指定的方法为处理国际化用户名和密码提供了一种更可持续的方法。本文件淘汰了RFC 7613。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8265.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8265.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Usernames . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Case Mapping vs. Case Preservation . . . . . . . . . . . 6
3.3. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 7
3.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. Preparation . . . . . . . . . . . . . . . . . . . . . 8
3.3.3. Enforcement . . . . . . . . . . . . . . . . . . . . . 8
3.3.4. Comparison . . . . . . . . . . . . . . . . . . . . . 9
3.4. UsernameCasePreserved Profile . . . . . . . . . . . . . . 9
3.4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.2. Preparation . . . . . . . . . . . . . . . . . . . . . 9
3.4.3. Enforcement . . . . . . . . . . . . . . . . . . . . . 10
3.4.4. Comparison . . . . . . . . . . . . . . . . . . . . . 10
3.5. Application-Layer Constructs . . . . . . . . . . . . . . 11
3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. OpaqueString Profile . . . . . . . . . . . . . . . . . . 14
4.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 14
4.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 14
4.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 15
4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Use in Application Protocols . . . . . . . . . . . . . . . . 16
6. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Usernames . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7.1. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 20
7.2. UsernameCasePreserved Profile . . . . . . . . . . . . . . 20
7.3. OpaqueString Profile . . . . . . . . . . . . . . . . . . 21
7.4. Stringprep Profile . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8.1. Password/Passphrase Strength . . . . . . . . . . . . . . 22
8.2. Password/Passphrase Comparison . . . . . . . . . . . . . 22
8.3. Identifier Comparison . . . . . . . . . . . . . . . . . . 22
8.4. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 22
8.5. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Changes from RFC 7613 . . . . . . . . . . . . . . . 25
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Usernames . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Case Mapping vs. Case Preservation . . . . . . . . . . . 6
3.3. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 7
3.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. Preparation . . . . . . . . . . . . . . . . . . . . . 8
3.3.3. Enforcement . . . . . . . . . . . . . . . . . . . . . 8
3.3.4. Comparison . . . . . . . . . . . . . . . . . . . . . 9
3.4. UsernameCasePreserved Profile . . . . . . . . . . . . . . 9
3.4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.2. Preparation . . . . . . . . . . . . . . . . . . . . . 9
3.4.3. Enforcement . . . . . . . . . . . . . . . . . . . . . 10
3.4.4. Comparison . . . . . . . . . . . . . . . . . . . . . 10
3.5. Application-Layer Constructs . . . . . . . . . . . . . . 11
3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. OpaqueString Profile . . . . . . . . . . . . . . . . . . 14
4.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 14
4.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 14
4.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 15
4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Use in Application Protocols . . . . . . . . . . . . . . . . 16
6. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Usernames . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7.1. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 20
7.2. UsernameCasePreserved Profile . . . . . . . . . . . . . . 20
7.3. OpaqueString Profile . . . . . . . . . . . . . . . . . . 21
7.4. Stringprep Profile . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8.1. Password/Passphrase Strength . . . . . . . . . . . . . . 22
8.2. Password/Passphrase Comparison . . . . . . . . . . . . . 22
8.3. Identifier Comparison . . . . . . . . . . . . . . . . . . 22
8.4. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 22
8.5. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Changes from RFC 7613 . . . . . . . . . . . . . . . 25
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
Usernames and passwords are widely used for authentication and authorization on the Internet, either directly when provided in plaintext (as in the PLAIN Simple Authentication and Security Layer (SASL) mechanism [RFC4616] and the HTTP Basic scheme [RFC7617]) or indirectly when provided as the input to a cryptographic algorithm such as a hash function (as in the Salted Challenge Response Authentication Mechanism (SCRAM) SASL mechanism [RFC5802] and the HTTP Digest scheme [RFC7616]).
用户名和密码广泛用于互联网上的身份验证和授权，或者直接以明文形式提供（如普通简单身份验证和安全层（SASL）机制[RFC4616]和HTTP基本方案[RFC7617]）或者，当作为诸如散列函数之类的加密算法的输入提供时（如在Salted质询响应认证机制（SCRAM）SASL机制[RFC5802]和HTTP摘要方案[RFC7616]中）间接提供。
To increase the likelihood that the input and comparison of usernames and passwords will work in ways that make sense for typical users throughout the world, this document defines rules for handling internationalized strings that represent usernames and passwords. Such strings consist of code points from the Unicode coded character set [Unicode], with special attention to code points outside the ASCII range [RFC20]. The rules for handling such strings are specified through profiles of the string classes defined in the preparation, enforcement, and comparison of internationalized strings (PRECIS) framework specification [RFC8264].
为了提高用户名和密码的输入和比较对世界各地的典型用户有意义的可能性，本文档定义了处理代表用户名和密码的国际化字符串的规则。此类字符串由Unicode编码字符集[Unicode]中的代码点组成，特别注意ASCII范围[RFC20]之外的代码点。处理此类字符串的规则是通过在准备、实施和比较国际化字符串（PRECIS）框架规范[RFC8264]中定义的字符串类概要文件指定的。
Profiles of the PRECIS framework enable software to handle Unicode code points outside the ASCII range in an automated way, so that such code points are treated carefully and consistently in application protocols. In large measure, these profiles are designed to protect application developers from the potentially negative consequences of supporting the full range of Unicode code points. For instance, in almost all application protocols it would be dangerous to treat the Unicode code point "¹" (SUPERSCRIPT ONE, U+00B9) as equivalent to "1" (DIGIT ONE, U+0031), because that would result in false accepts during comparison, authentication, and authorization (e.g., an attacker could easily spoof an account "user1@example.com").
PRECIS框架的配置文件使软件能够以自动化的方式处理ASCII范围之外的Unicode代码点，以便在应用程序协议中谨慎一致地处理此类代码点。在很大程度上，这些配置文件旨在保护应用程序开发人员免受支持全部Unicode代码点的潜在负面影响。例如，在几乎所有的应用程序协议中，将Unicode代码点“1”（上标1，U+00B9）视为等同于“1”（数字1，U+0031）是危险的，因为这将导致在比较、身份验证和授权过程中出现错误的接受（例如，攻击者可以很容易地欺骗帐户）user1@example.com").
Whereas a naive use of Unicode would make such attacks trivially easy, the PRECIS profile defined here for usernames generally protects applications from inadvertently causing such problems. (Similar considerations apply to passwords, although here it is desirable to support a wider range of characters so as to maximize entropy for purposes of authentication.)
虽然简单地使用Unicode会使此类攻击变得非常容易，但此处为用户名定义的PRECIS配置文件通常会保护应用程序免受无意中造成此类问题的影响。（类似的注意事项也适用于密码，尽管此处需要支持更大范围的字符，以便最大限度地利用熵进行身份验证。）
The methods defined here might be applicable wherever usernames or passwords are used. However, the methods are not intended for use in preparing strings that are not usernames (e.g., Lightweight Directory Access Protocol (LDAP) distinguished names), nor in cases where identifiers or secrets are not strings (e.g., keys and certificates) or require specialized handling.
这里定义的方法可能适用于使用用户名或密码的任何地方。但是，这些方法不用于准备非用户名的字符串（例如，轻量级目录访问协议（LDAP）可分辨名称），也不用于标识符或机密不是字符串（例如，密钥和证书）或需要专门处理的情况。
Although the historical predecessor of this document was the SASLprep profile of Stringprep [RFC3454]), the approach defined here can be used by technologies other than SASL [RFC4422], such as HTTP authentication as specified in [RFC7617] and [RFC7616].
尽管本文档的历史前身是Stringprep[RFC3454]的SASLprep概要文件，但此处定义的方法可由SASL[RFC4422]以外的技术使用，如[RFC7617]和[RFC7616]中规定的HTTP身份验证。
This document does not modify the handling of internationalized strings in usernames and passwords as prescribed by existing application protocols that use SASLprep. If the community that uses such an application protocol wishes to modernize its handling of internationalized strings to use PRECIS instead of Stringprep, it needs to explicitly update the existing application protocol definition (one example is [RFC7622]). Non-coordinated updates to protocol implementations are discouraged because they can have a negative impact on interoperability and security.
本文档不会按照使用SASLprep的现有应用程序协议的规定修改用户名和密码中国际化字符串的处理。如果使用此类应用程序协议的社区希望现代化其对国际化字符串的处理，以使用PRECIS而不是Stringprep，则需要显式更新现有的应用程序协议定义（例如[RFC7622]）。不鼓励对协议实现进行不协调的更新，因为它们会对互操作性和安全性产生负面影响。
A "username" or "user identifier" is a string of characters designating an account on a computing device or system, often but not necessarily for use by a person. Although some devices and systems might allow a username to be part or all of a person's name and a person might want their account designator to be part or all of their name, because of the complexities involved, that outcome is not guaranteed for all human names on all computing devices or systems that follow the rules defined in this specification. Protocol designers and application developers who wish to allow a wider range of characters are encouraged to consider a separation between more restrictive account identifiers and more expressive display names or nicknames (see [RFC8266]).
“用户名”或“用户标识符”是指在计算设备或系统上指定帐户的字符串，通常但不一定供个人使用。尽管一些设备和系统可能允许用户名作为一个人姓名的一部分或全部，而一个人可能希望其帐户指示符作为其姓名的一部分或全部，但由于涉及的复杂性，对于遵循本规范中定义的规则的所有计算设备或系统上的所有人名，该结果并不保证。希望允许更广泛范围的字符的协议设计器和应用程序开发者鼓励考虑更严格的帐户标识符和更富表现力的显示名称或昵称之间的分离（参见[RCF8266]）。
A "password" is a string of characters that allows access to a computing device or system, often associated with a particular username. A password is not literally limited to a word, because a password could be a passphrase consisting of more than one word, perhaps separated by spaces, punctuation, or other non-alphanumeric characters.
“密码”是允许访问计算设备或系统的字符串，通常与特定用户名关联。密码并不仅仅限于一个单词，因为密码可以是由多个单词组成的密码短语，可能由空格、标点符号或其他非字母数字字符分隔。
Some SASL mechanisms (e.g., CRAM-MD5, DIGEST-MD5, and SCRAM) specify that the authentication identity used in the context of such mechanisms is a "simple username" (see Section 2 of [RFC4422] as well as [RFC4013]). Various application technologies also assume that the identity of a user or account takes the form of a username (e.g., authentication for the Hypertext Transfer Protocol as specified in [RFC7617] and [RFC7616]), whether or not they use SASL. Note well that the exact form of a username in any particular SASL mechanism or application technology is a matter for implementation and deployment; note also that a username does not necessarily map to any particular application identifier.
一些SASL机制（如CRAM-MD5、DIGEST-MD5和SCRAM）规定，在此类机制的上下文中使用的身份验证标识是“简单用户名”（参见[RFC4422]第2节以及[RFC4013]）。各种应用技术还假设用户或帐户的身份采用用户名的形式（例如，[RFC7617]和[RFC7616]中规定的超文本传输协议的身份验证），无论它们是否使用SASL。请注意，在任何特定的SASL机制或应用程序技术中，用户名的确切形式取决于实现和部署；还要注意，用户名不一定映射到任何特定的应用程序标识符。
Many important terms used in this document are defined in [RFC5890], [RFC6365], [RFC8264], and [Unicode]. The term "non-ASCII space" refers to any Unicode code point having a Unicode general category of "Zs", naturally with the exception of SPACE (U+0020).
本文档中使用的许多重要术语在[RFC5890]、[RFC6365]、[RFC8264]和[Unicode]中定义。术语“非ASCII空间”是指具有Unicode一般类别“Zs”的任何Unicode码点，当然除了空格（U+0020）之外。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This document specifies that a username is a string of Unicode code points [Unicode] that is structured as an ordered sequence of "userparts" and expressed in a standard Unicode Encoding Form (such as UTF-8 [RFC3629]). A userpart is allowed to contain only code points that are allowed by the PRECIS IdentifierClass defined in Section 4.2 of [RFC8264] and thus consists almost exclusively of letters and digits. A username can consist of a single userpart or a space-separated sequence of userparts.
本文档规定用户名是一个Unicode码点字符串[Unicode]，其结构为“用户部分”的有序序列，并以标准Unicode编码形式（如UTF-8[RFC3629]）表示。用户部件只允许包含[RFC8264]第4.2节中定义的PRECIS IdentifierClass允许的代码点，因此几乎完全由字母和数字组成。用户名可以由单个用户部分或以空格分隔的用户部分序列组成。
The syntax for a username is defined as follows, using the Augmented Backus-Naur Form (ABNF) [RFC5234].
用户名的语法定义如下，使用扩展的Backus Naur表单（ABNF）[RFC5234]。
username = userpart *(1*SP userpart)
userpart = 1*(idpoint)
;
; an "idpoint" is a Unicode code point that
; can be contained in a string conforming to
; the PRECIS IdentifierClass
;
username = userpart *(1*SP userpart)
userpart = 1*(idpoint)
;
; an "idpoint" is a Unicode code point that
; can be contained in a string conforming to
; the PRECIS IdentifierClass
;
All code points and blocks not explicitly allowed in the PRECIS IdentifierClass are disallowed; this includes private-use code points, surrogate code points, and the other code points and blocks that were defined as "Prohibited Output" in Section 2.3 of [RFC4013] (when corrected per [Err1812]). In addition, common constructions such as "user@example.com" (e.g., the Network Access Identifier from [RFC7542]) are allowed as usernames under this specification, as they were under [RFC4013].
不允许PRECIS IdentifierClass中未明确允许的所有代码点和代码块；这包括私用代码点、代理代码点以及[RFC4013]第2.3节中定义为“禁止输出”的其他代码点和代码块（根据[Err1812]更正时）。此外，常见的结构，如“user@example.com“（例如，[RFC7542]中的网络访问标识符）与[RFC4013]中的用户名一样，可以作为本规范中的用户名。
Implementation Note: The username construct defined in this document does not necessarily match what all deployed applications might refer to as a "username" or "userid" but instead provides a relatively safe subset of Unicode code points that can be used in
实施说明：本文档中定义的用户名构造不一定与所有部署的应用程序所称的“用户名”或“用户ID”匹配，而是提供了一个相对安全的Unicode代码点子集，可在
existing SASL mechanisms and in application protocols that use SASL, and even in most application protocols that do not currently use SASL.
现有的SASL机制和使用SASL的应用程序内协议，甚至在当前不使用SASL的大多数应用程序协议中。
A username MUST NOT be zero bytes in length. This rule is to be enforced after any normalization and mapping of code points.
用户名的长度不得为零字节。此规则将在代码点的任何规范化和映射之后强制执行。
This specification defines two profiles for usernames: the UsernameCaseMapped profile performs case mapping, and the UsernameCasePreserved performs case preservation (see further discussion under Section 3.2).
本规范为用户名定义了两个配置文件：UsernameCaseMapped配置文件执行大小写映射，UsernameCasePreserved执行大小写保存（参见第3.2节下的进一步讨论）。
In protocols that provide usernames as input to a cryptographic algorithm such as a hash function, the client will need to perform enforcement of the rules for the UsernameCaseMapped or UsernameCasePreserved profile before applying the algorithm.
在提供用户名作为加密算法（如哈希函数）输入的协议中，客户端需要在应用算法之前执行UsernameCaseMapped或UsernameCaseServered配置文件的规则。
In order to accommodate the widest range of username constructs in applications, this document defines two username profiles: UsernameCaseMapped and UsernameCasePreserved. These two profiles differ only in their use (or not) of the Case Mapping Rule and are otherwise identical.
为了适应应用程序中最广泛的用户名构造，本文档定义了两个用户名配置文件：UsernameCaseMapped和UsernameCasePreserved。这两个概要文件仅在使用（或不使用）案例映射规则方面有所不同，在其他方面是相同的。
Case mapping is a matter for the application protocol, protocol implementation, or end deployment. In general, this document suggests that it is preferable to apply the UsernameCaseMapped profile and therefore perform case mapping, because not doing so can lead to false accepts during authentication and authorization (as described in [RFC6943]) and can result in confusion among end users, given the prevalence of case mapping in many existing protocols and applications. However, there can be good reasons to apply the UsernameCasePreserved profile and thus not perform case mapping, such as backward compatibility with deployed infrastructure.
案例映射是应用程序协议、协议实现或最终部署的问题。一般来说，本文件建议最好应用UsernameCaseMapped概要文件，并因此执行案例映射，因为不这样做可能会导致身份验证和授权期间的错误接受（如[RFC6943]所述），并可能导致最终用户之间的混淆，考虑到案例映射在许多现有协议和应用程序中的普遍性。但是，应用UsernameCasePreserved概要文件并因此不执行案例映射可能有很好的理由，例如与已部署的基础结构的向后兼容性。
In particular:
特别地：
o SASL mechanisms that follow the recommendations in this document MUST specify whether and when case mapping is to be applied to authentication identifiers. Because case mapping results in information loss, in order to retain that information for as long as possible during processing, implementations SHOULD delay any case mapping to the last possible moment, such as when doing a lookup by username, performing username comparisons, or generating a cryptographic salt from a username (if the last possible moment happens on a server, then decisions about case mapping can be a matter of service deployment policy). In keeping with [RFC4422],
o 遵循本文档中建议的SASL机制必须指定是否以及何时将案例映射应用于身份验证标识符。因为案例映射会导致信息丢失，为了在处理过程中尽可能长时间地保留该信息，实现应该将任何案例映射延迟到最后一个可能的时刻，例如按用户名进行查找、执行用户名比较或从用户名生成加密salt时（如果最后一个可能的时刻发生在服务器上，那么关于案例映射的决定可能是服务部署策略的问题），
SASL mechanisms are not to apply this or any other profile to authorization identifiers, only to authentication identifiers.
SASL机制不将此配置文件或任何其他配置文件应用于授权标识符，而仅应用于身份验证标识符。
o Application protocols that use SASL (such as IMAP [RFC3501] and the Extensible Messaging and Presence Protocol (XMPP) [RFC6120]) and that directly reuse this profile MUST specify whether or not case mapping is to be applied to authorization identifiers. Such "SASL application protocols" SHOULD delay any case mapping of authorization identifiers to the last possible moment, which happens to necessarily be on the server side (this enables decisions about case mapping to be a matter of service deployment policy). In keeping with [RFC4422], SASL application protocols are not to apply this or any other profile to authentication identifiers, only to authorization identifiers.
o 使用SASL的应用程序协议（如IMAP[RFC3501]和可扩展消息和状态协议（XMPP）[RFC6120]）以及直接重用此配置文件的应用程序协议必须指定是否将案例映射应用于授权标识符。这样的“SASL应用程序协议”应该将授权标识符的任何案例映射延迟到最后一个可能的时刻，而这恰好发生在服务器端（这使得关于案例映射的决策成为服务部署策略的问题）。与[RFC4422]保持一致，SASL应用程序协议不将此配置文件或任何其他配置文件应用于身份验证标识符，仅应用于授权标识符。
o Application protocols that do not use SASL (such as HTTP authentication with the HTTP Basic and Digest schemes as specified in [RFC7617] and [RFC7616]) but that directly reuse this profile MUST specify whether and when case mapping is to be applied to authentication identifiers or authorization identifiers, or both. Such "non-SASL application protocols" SHOULD delay any case mapping to the last possible moment, such as when doing a lookup by username, performing username comparisons, or generating a cryptographic salt from a username (if the last possible moment happens on the server, then decisions about case mapping can be a matter of service deployment policy).
o 不使用SASL（如[RFC7617]和[RFC7616]中指定的HTTP基本和摘要方案的HTTP身份验证）但直接重用此配置文件的应用程序协议必须指定是否以及何时将案例映射应用于身份验证标识符或授权标识符，或两者。此类“非SASL应用程序协议”应将任何案例映射延迟到最后一个可能的时刻，例如按用户名进行查找、执行用户名比较或从用户名生成加密salt时（如果最后一个可能的时刻发生在服务器上，那么关于案例映射的决定可能是服务部署策略的问题）。
If the specification for a SASL mechanism, SASL application protocol, or non-SASL application protocol uses the UsernameCaseMapped profile, it MUST clearly describe whether case mapping is to be applied at the level of the protocol itself, implementations thereof, or service deployments (each of these approaches can be legitimate, depending on the application in question).
如果SASL机制、SASL应用程序协议或非SASL应用程序协议的规范使用UsernameCaseMapped概要文件，则必须明确说明是否在协议本身、其实现或服务部署级别应用案例映射（这些方法中的每一种都可能是合法的，具体取决于所讨论的应用）。
The following rules are defined for use within the UsernameCaseMapped profile of the PRECIS IdentifierClass.
以下规则定义用于PRECIS IdentifierClass的UsernameCaseMapped配置文件。
1. Width Mapping Rule: Map fullwidth and halfwidth code points to their decomposition mappings (see Unicode Standard Annex #11 [UAX11]).
1. 宽度映射规则：将全宽和半宽代码点映射到它们的分解映射（参见Unicode标准附录11[UAX11]）。
2. Additional Mapping Rule: There is no additional mapping rule.
2. 其他映射规则：没有其他映射规则。
3. Case Mapping Rule: Map uppercase and titlecase code points to their lowercase equivalents, preferably using the Unicode toLowerCase() operation as defined in the Unicode Standard [Unicode]; see further discussion in Section 3.2.
3. 大小写映射规则：将大写和titlecase代码点映射到它们的小写等价物，最好使用Unicode标准[Unicode]中定义的Unicode toLowerCase（）操作；见第3.2节的进一步讨论。
4. Normalization Rule: Apply Unicode Normalization Form C (NFC) to all strings.
4. 规范化规则：将Unicode规范化表单C（NFC）应用于所有字符串。
5. Directionality Rule: Apply the "Bidi Rule" defined in [RFC5893] to strings that contain right-to-left code points (i.e., each of the six conditions of the Bidi Rule must be satisfied); for strings that do not contain right-to-left code points, there is no special processing for directionality.
5. 方向性规则：将[RFC5893]中定义的“Bidi规则”应用于包含从右到左代码点的字符串（即，必须满足Bidi规则的六个条件中的每一个）；对于不包含从右到左代码点的字符串，没有针对方向性的特殊处理。
An entity that prepares an input string for subsequent enforcement according to this profile MUST proceed as follows (applying the steps in the order shown).
根据此配置文件准备输入字符串以供后续执行的实体必须按以下步骤进行（按所示顺序应用步骤）。
1. Apply the width mapping rule specified in Section 3.3.1. It is necessary to apply the rule at this point because otherwise the PRECIS "HasCompat" category specified in Section 9.17 of [RFC8264] would forbid fullwidth and halfwidth code points.
1. 应用第3.3.1节中规定的宽度映射规则。此时有必要应用该规则，否则[RFC8264]第9.17节中规定的PRECIS“HasCompat”类别将禁止全宽和半宽代码点。
2. Ensure that the string consists only of Unicode code points that are explicitly allowed by the PRECIS IdentifierClass defined in Section 4.2 of [RFC8264].
2. 确保字符串仅由[RFC8264]第4.2节中定义的PRECIS IdentifierClass明确允许的Unicode代码点组成。
An entity that performs enforcement according to this profile MUST prepare an input string as described in Section 3.3.2 and MUST also apply the following rules specified in Section 3.3.1 in the order shown:
根据本概要文件执行强制的实体必须按照第3.3.2节所述准备输入字符串，并且还必须按照所示顺序应用第3.3.1节中规定的以下规则：
1. Case Mapping Rule
1. 案例映射规则
2. Normalization Rule
2. 规范化规则
3. Directionality Rule
3. 方向性规则
After all of the foregoing rules have been enforced, the entity MUST ensure that the username is not zero bytes in length (this is done after enforcing the rules to prevent applications from mistakenly omitting a username entirely, because when internationalized strings are accepted, a non-empty sequence of characters can result in a zero-length username after canonicalization).
在执行了上述所有规则之后，实体必须确保用户名的长度不是零字节（这是在强制执行规则以防止应用程序错误地完全忽略用户名后完成的，因为当接受国际化字符串时，非空字符序列可能会在规范化后导致零长度用户名）。
The result of the foregoing operations is an output string that conforms to the UsernameCaseMapped profile. Until an implementation produces such an output string, it MUST NOT treat the string as conforming (in particular, it MUST NOT assume that an input string is conforming before the enforcement operation has been completed).
上述操作的结果是符合UsernameCaseMapped概要文件的输出字符串。在实现生成这样的输出字符串之前，它不得将该字符串视为符合要求的字符串（特别是，它不得假设在执行操作完成之前输入字符串是符合要求的）。
An entity that performs comparison of two strings according to this profile MUST prepare each string as specified in Section 3.3.2 and then MUST enforce the rules specified in Section 3.3.3. The two strings are to be considered equivalent if and only if they are an exact octet-for-octet match (sometimes called "bit-string identity").
根据本概要文件对两个字符串进行比较的实体必须按照第3.3.2节的规定准备每个字符串，然后必须执行第3.3.3节规定的规则。当且仅当两个字符串是八位字节匹配的精确八位字节（有时称为“位字符串标识”）时，这两个字符串才被认为是等效的。
Until an implementation determines whether two strings are to be considered equivalent, it MUST NOT treat them as equivalent (in particular, it MUST NOT assume that two input strings are equivalent before the comparison operation has been completed).
在实现确定两个字符串是否等效之前，它不能将它们视为等效的（特别是，在比较操作完成之前，它不能假定两个输入字符串是等效的）。
The following rules are defined for use within the UsernameCasePreserved profile of the PRECIS IdentifierClass.
以下规则定义用于PRECIS IdentifierClass的UsernameCasePreserved配置文件。
1. Width Mapping Rule: Map fullwidth and halfwidth code points to their decomposition mappings (see Unicode Standard Annex #11 [UAX11]).
1. 宽度映射规则：将全宽和半宽代码点映射到它们的分解映射（参见Unicode标准附录11[UAX11]）。
2. Additional Mapping Rule: There is no additional mapping rule.
2. 其他映射规则：没有其他映射规则。
3. Case Mapping Rule: There is no case mapping rule.
3. 案例映射规则：没有案例映射规则。
4. Normalization Rule: Apply Unicode Normalization Form C (NFC) to all strings.
4. 规范化规则：将Unicode规范化表单C（NFC）应用于所有字符串。
5. Directionality Rule: Apply the "Bidi Rule" defined in [RFC5893] to strings that contain right-to-left code points (i.e., each of the six conditions of the Bidi Rule must be satisfied); for strings that do not contain right-to-left code points, there is no special processing for directionality.
5. 方向性规则：将[RFC5893]中定义的“Bidi规则”应用于包含从右到左代码点的字符串（即，必须满足Bidi规则的六个条件中的每一个）；对于不包含从右到左代码点的字符串，没有针对方向性的特殊处理。
An entity that prepares a string for subsequent enforcement according to this profile MUST proceed as follows (applying the steps in the order shown).
根据此配置文件准备字符串以供后续执行的实体必须按以下步骤进行（按所示顺序应用步骤）。
1. Apply the width mapping rule specified in Section 3.4.1. It is necessary to apply the rule at this point because otherwise the PRECIS "HasCompat" category specified in Section 9.17 of [RFC8264] would forbid fullwidth and halfwidth code points.
1. 应用第3.4.1节中规定的宽度映射规则。此时有必要应用该规则，否则[RFC8264]第9.17节中规定的PRECIS“HasCompat”类别将禁止全宽和半宽代码点。
2. Ensure that the string consists only of Unicode code points that are explicitly allowed by the PRECIS IdentifierClass defined in Section 4.2 of [RFC8264].
2. 确保字符串仅由[RFC8264]第4.2节中定义的PRECIS IdentifierClass明确允许的Unicode代码点组成。
An entity that performs enforcement according to this profile MUST prepare a string as described in Section 3.4.2 and MUST also apply the following rules specified in Section 3.4.1 in the order shown:
根据本概要文件执行强制的实体必须按照第3.4.2节所述准备字符串，并且必须按照所示顺序应用第3.4.1节规定的以下规则：
1. Normalization Rule
1. 规范化规则
2. Directionality Rule
2. 方向性规则
After all of the foregoing rules have been enforced, the entity MUST ensure that the username is not zero bytes in length (this is done after enforcing the rules to prevent applications from mistakenly omitting a username entirely, because when internationalized strings are accepted, a non-empty sequence of characters can result in a zero-length username after canonicalization).
在执行了上述所有规则之后，实体必须确保用户名的长度不是零字节（这是在强制执行规则以防止应用程序错误地完全忽略用户名后完成的，因为当接受国际化字符串时，非空字符序列可能会在规范化后导致零长度用户名）。
The result of the foregoing operations is an output string that conforms to the UsernameCasePreserved profile. Until an implementation produces such an output string, it MUST NOT treat the string as conforming (in particular, it MUST NOT assume that an input string is conforming before the enforcement operation has been completed).
上述操作的结果是符合UsernameCasePreserved配置文件的输出字符串。在实现生成这样的输出字符串之前，它不得将该字符串视为符合要求的字符串（特别是，它不得假设在执行操作完成之前输入字符串是符合要求的）。
An entity that performs comparison of two strings according to this profile MUST prepare each string as specified in Section 3.4.2 and then MUST enforce the rules specified in Section 3.4.3. The two strings are to be considered equivalent if and only if they are an exact octet-for-octet match (sometimes called "bit-string identity").
根据本概要文件对两个字符串进行比较的实体必须按照第3.4.2节的规定准备每个字符串，然后必须执行第3.4.3节规定的规则。当且仅当两个字符串是八位字节匹配的精确八位字节（有时称为“位字符串标识”）时，这两个字符串才被认为是等效的。
Until an implementation determines whether two strings are to be considered equivalent, it MUST NOT treat them as equivalent (in particular, it MUST NOT assume that two input strings are equivalent before the comparison operation has been completed).
在实现确定两个字符串是否等效之前，它不能将它们视为等效的（特别是，在比较操作完成之前，它不能假定两个输入字符串是等效的）。
Both the UsernameCaseMapped and UsernameCasePreserved profiles enable an application protocol, implementation, or deployment to create application-layer constructs such as a username that is a space-separated set of userparts like "Firstname Middlename Lastname". Such a construct is not a profile of the PRECIS IdentifierClass, because SPACE (U+0020) is not allowed in the IdentifierClass; however, it can be created at the application layer because SPACE (U+0020) can be used as a separator between instances of the PRECIS IdentifierClass (e.g., userparts as defined in this specification).
UsernameCaseMapped和UsernameCasePreserved配置文件都支持应用程序协议、实现或部署来创建应用程序层结构，例如用户名，它是一组以空格分隔的用户名，如“Firstname Middlename Lastname”。这种构造不是PRECIS IdentifierClass的剖面，因为IdentifierClass中不允许有空格（U+0020）；但是，它可以在应用层创建，因为空间（U+0020）可以用作PRECIS IdentifierClass实例之间的分隔符（例如，本规范中定义的用户部件）。
The following examples illustrate a small number of userparts (not usernames) that are consistent with the format defined above (note that the characters "<" and ">" are used here to delineate the actual userparts and are not part of the userpart strings).
以下示例说明了与上面定义的格式一致的少量用户部件（不是用户名）（请注意，此处使用“<”和“>”字符来描述实际用户部件，而不是用户部件字符串的一部分）。
+--------------------------+---------------------------------+
| # | Userpart | Notes |
+--------------------------+---------------------------------+
| 1 | <juliet@example.com> | The "at" sign ("@") is allowed |
| | | in the PRECIS IdentifierClass |
+--------------------------+---------------------------------+
| 2 | <fussball> | |
+--------------------------+---------------------------------+
| 3 | <fußball> | The third character is LATIN |
| | | SMALL LETTER SHARP S (U+00DF) |
+--------------------------+---------------------------------+
| 4 | <π> | A userpart of GREEK SMALL |
| | | LETTER PI (U+03C0) |
+--------------------------+---------------------------------+
| 5 | <Σ> | A userpart of GREEK CAPITAL |
| | | LETTER SIGMA (U+03A3) |
+--------------------------+---------------------------------+
| 6 | <σ> | A userpart of GREEK SMALL |
| | | LETTER SIGMA (U+03C3) |
+--------------------------+---------------------------------+
| 7 | <ς> | A userpart of GREEK SMALL |
| | | LETTER FINAL SIGMA (U+03C2) |
+--------------------------+---------------------------------+
+--------------------------+---------------------------------+
| # | Userpart | Notes |
+--------------------------+---------------------------------+
| 1 | <juliet@example.com> | The "at" sign ("@") is allowed |
| | | in the PRECIS IdentifierClass |
+--------------------------+---------------------------------+
| 2 | <fussball> | |
+--------------------------+---------------------------------+
| 3 | <fußball> | The third character is LATIN |
| | | SMALL LETTER SHARP S (U+00DF) |
+--------------------------+---------------------------------+
| 4 | <π> | A userpart of GREEK SMALL |
| | | LETTER PI (U+03C0) |
+--------------------------+---------------------------------+
| 5 | <Σ> | A userpart of GREEK CAPITAL |
| | | LETTER SIGMA (U+03A3) |
+--------------------------+---------------------------------+
| 6 | <σ> | A userpart of GREEK SMALL |
| | | LETTER SIGMA (U+03C3) |
+--------------------------+---------------------------------+
| 7 | <ς> | A userpart of GREEK SMALL |
| | | LETTER FINAL SIGMA (U+03C2) |
+--------------------------+---------------------------------+
Table 1: A Sample of Legal Userparts
表1：合法用户部件示例
Regarding examples 2 and 3: although in German writing the character eszett "ß" (LATIN SMALL LETTER SHARP S, U+00DF) can mostly be used interchangeably with the two characters "ss", the userparts in these
关于例2和例3：尽管在德语书写中，字符eszett“ß”（拉丁小写字母SHARP S，U+00DF）大部分可以与两个字符“ss”互换使用，但其中的用户部分
examples are different and (if desired) a server would need to enforce a registration policy that disallows one of them if the other is registered.
示例是不同的（如果需要），服务器需要强制执行一个注册策略，如果其中一个已注册，则该策略将不允许其中一个。
Regarding examples 5, 6, and 7: optional case mapping of "Σ" (GREEK CAPITAL LETTER SIGMA, U+03A3) to the lowercase character "σ" (GREEK SMALL LETTER SIGMA, U+03C3) during comparison would result in matching the userparts in examples 5 and 6; however, because the PRECIS mapping rules do not account for the special status of the character "ς" (GREEK SMALL LETTER FINAL SIGMA, U+03C2), the userparts in examples 5 and 7 or examples 6 and 7 would not be matched during comparison.
关于示例5、6和7：在比较期间，将“∑”（希腊文大写字母SIGMA，U+03A3）的可选大小写映射到小写字符“σ”（希腊文小写字母SIGMA，U+03C3）将导致匹配示例5和6中的用户部件；然而，由于PRECIS映射规则没有考虑字符“ς”（希腊小写字母FINAL SIGMA，U+03C2）的特殊状态，因此在比较过程中，示例5和7或示例6和7中的用户部分将不匹配。
The following examples illustrate strings that are not valid userparts (not usernames) because they violate the format defined above.
以下示例说明了无效的用户名（而非用户名）字符串，因为它们违反了上面定义的格式。
+--------------------------+---------------------------------+
| # | Non-Userpart String | Notes |
+--------------------------+---------------------------------+
| 8 | <foo bar> | SPACE (U+0020) is disallowed in |
| | | the userpart |
+--------------------------+---------------------------------+
| 9 | <> | Zero-length userpart |
+--------------------------+---------------------------------+
| 10| <henryⅣ> | The sixth character is ROMAN |
| | | NUMERAL FOUR (U+2163) |
+--------------------------+---------------------------------+
| 11| <∞> | A userpart of INFINITY (U+221E) |
+--------------------------+---------------------------------+
+--------------------------+---------------------------------+
| # | Non-Userpart String | Notes |
+--------------------------+---------------------------------+
| 8 | <foo bar> | SPACE (U+0020) is disallowed in |
| | | the userpart |
+--------------------------+---------------------------------+
| 9 | <> | Zero-length userpart |
+--------------------------+---------------------------------+
| 10| <henryⅣ> | The sixth character is ROMAN |
| | | NUMERAL FOUR (U+2163) |
+--------------------------+---------------------------------+
| 11| <∞> | A userpart of INFINITY (U+221E) |
+--------------------------+---------------------------------+
Table 2: A Sample of Strings That Violate the Userpart Rules
表2：违反Userpart规则的字符串示例
Regarding example 8: although this is not a valid userpart, it is a valid username because it is a space-separated sequence of userparts.
关于示例8：尽管这不是一个有效的userpart，但它是一个有效的用户名，因为它是一个以空格分隔的userpart序列。
Regarding example 10: the character "Ⅳ" (ROMAN NUMERAL FOUR, U+2163) has a compatibility equivalent of the characters "I" (LATIN CAPITAL LETTER I, U+0049) and "V" (LATIN CAPITAL LETTER V, U+0056), but code points with compatibility equivalents are not allowed in the PRECIS IdentifierClass.
关于示例10：字符“Ⅳ”（罗马数字4，U+2163）具有与字符“I”（拉丁文大写字母I，U+0049）和“V”（拉丁文大写字母V，U+0056）相当的兼容性，但PRECIS IdentifierClass中不允许具有兼容性等同物的代码点。
Regarding example 11: symbol characters such as "∞" (INFINITY, U+221E) are not allowed in the PRECIS IdentifierClass.
关于示例11：符号字符，例如“∞" （无穷大，U+221E）不允许出现在PRECIS IdentifierClass中。
This document specifies that a password is a string of Unicode code points [Unicode] that is conformant to the OpaqueString profile (specified below) of the PRECIS FreeformClass defined in Section 4.3 of [RFC8264] and expressed in a standard Unicode Encoding Form (such as UTF-8 [RFC3629]).
本文件规定密码是符合[RFC8264]第4.3节中定义的PRECIS FreeformClass的OpaqueString配置文件（如下所述）的Unicode码点字符串[Unicode]，并以标准Unicode编码形式（如UTF-8[RFC3629]）表示。
The syntax for a password is defined as follows, using the Augmented Backus-Naur Form (ABNF) [RFC5234].
密码的语法定义如下，使用扩展的Backus Naur表单（ABNF）[RFC5234]。
password = 1*(freepoint)
;
; a "freepoint" is a Unicode code point that
; can be contained in a string conforming to
; the PRECIS FreeformClass
;
password = 1*(freepoint)
;
; a "freepoint" is a Unicode code point that
; can be contained in a string conforming to
; the PRECIS FreeformClass
;
All code points and blocks not explicitly allowed in the PRECIS FreeformClass are disallowed; this includes private-use code points, surrogate code points, and the other code points and blocks defined as "Prohibited Output" in Section 2.3 of [RFC4013] (when corrected per [Err1812]).
不允许PRECIS FreeformClass中未明确允许的所有代码点和代码块；这包括私用代码点、代理代码点以及[RFC4013]第2.3节中定义为“禁止输出”的其他代码点和代码块（根据[Err1812]更正时）。
A password MUST NOT be zero bytes in length. This rule is to be enforced after any normalization and mapping of code points.
密码长度不得为零字节。此规则将在代码点的任何规范化和映射之后强制执行。
Note: Some existing systems allow an empty string in places where a password would be expected (e.g., command-line tools that might be called from an automated script, or servers that might need to be restarted without human intervention). From the perspective of this document (and RFC 4013 before it), these empty strings are not passwords but are workarounds for the practical difficulty of using passwords in certain scenarios.
注意：一些现有系统允许在需要密码的地方使用空字符串（例如，可能从自动脚本调用的命令行工具，或者可能需要在无需人工干预的情况下重新启动的服务器）。从本文档（以及之前的RFC 4013）的角度来看，这些空字符串不是密码，而是在某些场景中使用密码的实际困难的解决方法。
Note: The prohibition of zero-length passwords is not a recommendation regarding password strength (because a password of only one byte is highly insecure) but is meant to prevent applications from mistakenly omitting a password entirely; such an outcome is possible when internationalized strings are accepted, because a non-empty sequence of characters can result in a zero-length password after canonicalization.
注意：禁止零长度密码不是关于密码强度的建议（因为只有一个字节的密码是高度不安全的），而是为了防止应用程序错误地完全忽略密码；当接受国际化字符串时，这样的结果是可能的，因为非空字符序列在规范化后可能导致零长度密码。
In protocols that provide passwords as input to a cryptographic algorithm such as a hash function, the client will need to perform enforcement of the rules for the OpaqueString profile before applying
在提供密码作为加密算法（如哈希函数）输入的协议中，客户端需要在应用前执行OpaqueString配置文件规则的强制执行
the algorithm, because the password is not available to the server in plaintext form.
由于密码不能以明文形式提供给服务器，因此无法使用该算法。
The definition of the OpaqueString profile is provided in the following sections, including detailed information about preparation, enforcement, and comparison (for details on the distinction between these actions, refer to [RFC8264]).
以下章节提供了不透明字符串配置文件的定义，包括有关准备、实施和比较的详细信息（有关这些操作之间区别的详细信息，请参阅[RFC8264]）。
An entity that prepares a string according to this profile MUST ensure that the string consists only of Unicode code points that are explicitly allowed by the FreeformClass string class defined in [RFC8264].
根据此配置文件准备字符串的实体必须确保字符串仅包含[RFC8264]中定义的FreeformClass字符串类明确允许的Unicode代码点。
An entity that performs enforcement according to this profile MUST prepare a string as described in Section 4.2.1 and MUST also apply the rules specified below for the OpaqueString profile (these rules MUST be applied in the order shown):
根据本概要文件执行强制的实体必须按照第4.2.1节所述准备字符串，并且还必须为OpaqueString概要文件应用以下规定的规则（这些规则必须按照所示顺序应用）：
1. Width Mapping Rule: Fullwidth and halfwidth code points MUST NOT be mapped to their decomposition mappings (see Unicode Standard Annex #11 [UAX11]).
1. 宽度映射规则：全宽度和半宽度代码点不得映射到其分解映射（请参见Unicode标准附录#11[UAX11]）。
2. Additional Mapping Rule: Any instances of non-ASCII space MUST be mapped to SPACE (U+0020); a non-ASCII space is any Unicode code point having a Unicode general category of "Zs", with the exception of SPACE (U+0020). As was the case in RFC 4013, the inclusion of only SPACE (U+0020) prevents confusion with various non-ASCII space code points, many of which are difficult to reproduce across different input methods.
2. 附加映射规则：非ASCII空间的任何实例都必须映射到空间（U+0020）；非ASCII空间是具有Unicode一般类别“Zs”的任何Unicode代码点，但空格（U+0020）除外。与RFC 4013中的情况一样，仅包含空格（U+0020）可防止与各种非ASCII空格代码点混淆，其中许多代码点很难跨不同的输入方法复制。
3. Case Mapping Rule: There is no case mapping rule (because mapping uppercase and titlecase code points to their lowercase equivalents would lead to false accepts and thus to reduced security).
3. 大小写映射规则：没有大小写映射规则（因为将大写和titlecase代码映射到它们的小写等价物将导致错误接受，从而降低安全性）。
4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be applied to all strings.
4. 规范化规则：Unicode规范化表单C（NFC）必须应用于所有字符串。
5. Directionality Rule: There is no directionality rule. The "Bidi Rule" (defined in [RFC5893]) and similar rules are unnecessary and inapplicable to passwords, because they can reduce the repertoire of characters that are allowed in a string and
5. 方向性规则：没有方向性规则。“Bidi规则”（在[RFC5893]中定义）和类似规则是不必要的，不适用于密码，因为它们可以减少字符串和密码中允许的字符集
therefore reduce the amount of entropy that is possible in a password. Such rules are intended to minimize the possibility that the same string will be displayed differently on a layout system set for right-to-left display and a layout system set for left-to-right display; however, passwords are typically not displayed at all and are rarely meant to be interoperable across different layout systems in the way that non-secret strings like domain names and usernames are. Furthermore, it is perfectly acceptable for opaque strings other than passwords to be presented differently in different layout systems, as long as the presentation is consistent in any given layout system.
因此，减少密码中可能存在的熵。此类规则旨在最小化相同字符串在设置为从右到左显示的布局系统和设置为从左到右显示的布局系统上以不同方式显示的可能性；但是，密码通常根本不显示，也很少像域名和用户名等非机密字符串那样在不同的布局系统之间进行互操作。此外，密码以外的不透明字符串在不同的布局系统中以不同的方式呈现是完全可以接受的，只要呈现在任何给定的布局系统中是一致的。
The result of the foregoing operations is an output string that conforms to the OpaqueString profile. Until an implementation produces such an output string, it MUST NOT treat the string as conforming (in particular, it MUST NOT assume that an input string is conforming before the enforcement operation has been completed).
上述操作的结果是符合OpaqueString配置文件的输出字符串。在实现生成这样的输出字符串之前，它不得将该字符串视为符合要求的字符串（特别是，它不得假设在执行操作完成之前输入字符串是符合要求的）。
An entity that performs comparison of two strings according to this profile MUST prepare each string as specified in Section 4.2.1 and then MUST enforce the rules specified in Section 4.2.2. The two strings are to be considered equivalent if and only if they are an exact octet-for-octet match (sometimes called "bit-string identity").
根据本概要文件对两个字符串进行比较的实体必须按照第4.2.1节的规定准备每个字符串，然后必须执行第4.2.2节规定的规则。当且仅当两个字符串是八位字节匹配的精确八位字节（有时称为“位字符串标识”）时，这两个字符串才被认为是等效的。
Until an implementation determines whether two strings are to be considered equivalent, it MUST NOT treat them as equivalent (in particular, it MUST NOT assume that two input strings are equivalent before the comparison operation has been completed).
在实现确定两个字符串是否等效之前，它不能将它们视为等效的（特别是，在比较操作完成之前，它不能假定两个输入字符串是等效的）。
See Section 8.2 regarding comparison of passwords and passphrases.
有关密码和密码短语的比较，请参见第8.2节。
The following examples illustrate a small number of passwords that are consistent with the format defined above (note that the characters "<" and ">" are used here to delineate the actual passwords and are not part of the password strings).
以下示例说明了与上述格式一致的少量密码（请注意，此处使用“<”和“>”字符来描述实际密码，而不是密码字符串的一部分）。
+------------------------------------+------------------------------+
| # | Password | Notes |
+------------------------------------+------------------------------+
| 12| <correct horse battery staple> | SPACE (U+0020) is allowed |
+------------------------------------+------------------------------+
| 13| <Correct Horse Battery Staple> | Differs by case from |
| | | example 12 |
+------------------------------------+------------------------------+
| 14| <πßå> | Non-ASCII letters are OK |
| | | (e.g., GREEK SMALL LETTER |
| | | PI (U+03C0)) |
+------------------------------------+------------------------------+
| 15| <Jack of ♦s> | Symbols are OK (e.g., BLACK |
| | | DIAMOND SUIT (U+2666)) |
+------------------------------------+------------------------------+
| 16| <foo bar> | OGHAM SPACE MARK (U+1680) is |
| | | mapped to SPACE (U+0020); |
| | | thus, the full string is |
| | | mapped to <foo bar> |
+------------------------------------+------------------------------+
+------------------------------------+------------------------------+
| # | Password | Notes |
+------------------------------------+------------------------------+
| 12| <correct horse battery staple> | SPACE (U+0020) is allowed |
+------------------------------------+------------------------------+
| 13| <Correct Horse Battery Staple> | Differs by case from |
| | | example 12 |
+------------------------------------+------------------------------+
| 14| <πßå> | Non-ASCII letters are OK |
| | | (e.g., GREEK SMALL LETTER |
| | | PI (U+03C0)) |
+------------------------------------+------------------------------+
| 15| <Jack of ♦s> | Symbols are OK (e.g., BLACK |
| | | DIAMOND SUIT (U+2666)) |
+------------------------------------+------------------------------+
| 16| <foo bar> | OGHAM SPACE MARK (U+1680) is |
| | | mapped to SPACE (U+0020); |
| | | thus, the full string is |
| | | mapped to <foo bar> |
+------------------------------------+------------------------------+
Table 3: A Sample of Legal Passwords
表3：合法密码示例
The following examples illustrate strings that are not valid passwords because they violate the format defined above.
以下示例说明了由于违反上面定义的格式而不是有效密码的字符串。
+------------------------------------+------------------------------+
| # | Password | Notes |
+------------------------------------+------------------------------+
| 17| <> | Zero-length passwords are |
| | | disallowed |
+------------------------------------+------------------------------+
| 18| <my cat is a 	by> | Control characters like TAB |
| | | (U+0009) are disallowed |
+------------------------------------+------------------------------+
+------------------------------------+------------------------------+
| # | Password | Notes |
+------------------------------------+------------------------------+
| 17| <> | Zero-length passwords are |
| | | disallowed |
+------------------------------------+------------------------------+
| 18| <my cat is a 	by> | Control characters like TAB |
| | | (U+0009) are disallowed |
+------------------------------------+------------------------------+
Table 4: A Sample of Strings That Violate the Password Rules
表4：违反密码规则的字符串示例
Note: Following the "XML Notation" used in [RFC3987], the character TAB (U+0009) in example 18 is represented as 	 because otherwise it could not be shown in running text.
注意：按照[RFC3987]中使用的“XML表示法”，示例18中的字符选项卡（U+0009）表示为	，因为否则它无法在运行文本中显示。
This specification defines only the PRECIS-based rules for the handling of strings conforming to the UsernameCaseMapped and UsernameCasePreserved profiles of the PRECIS IdentifierClass, and strings conforming to the OpaqueString profile of the PRECIS
本规范仅定义了基于PRECIS的规则，用于处理符合PRECIS IdentifierClass的UsernameCaseMapped和UsernameCasePreserved配置文件的字符串，以及符合PRECIS的OpaqueString配置文件的字符串
FreeformClass. It is the responsibility of an application protocol to specify the protocol slots in which such strings can appear, the entities that are expected to enforce the rules governing such strings, and at what points during protocol processing or interface handling the rules need to be enforced. See Section 6 of [RFC8264] for guidelines on using PRECIS profiles in applications.
FreeformClass。应用程序协议的责任是指定这些字符串可以出现的协议插槽、期望强制执行这些字符串的规则的实体，以及在协议处理或接口处理期间需要强制执行规则的点。有关在应用程序中使用PRECIS配置文件的指南，请参见[RFC8264]第6节。
Above and beyond the PRECIS-based rules specified here, application protocols can also define application-specific rules governing such strings (rules regarding minimum or maximum length, further restrictions on allowable code points or character ranges, safeguards to mitigate the effects of visually similar characters, etc.), application-layer constructs (see Section 3.5), and related matters.
除了此处指定的基于PRECIS的规则之外，应用协议还可以定义管理此类字符串的特定于应用程序的规则（关于最小或最大长度的规则、对允许的代码点或字符范围的进一步限制、减轻视觉相似字符影响的保护措施等），应用层构造（见第3.5节）和相关事项。
Some PRECIS profile definitions encourage entities that enforce the rules to be liberal in what they accept. However, for usernames and passwords such a policy can be problematic, because it can lead to false accepts. An in-depth discussion can be found in [RFC6943].
一些PRECIS概要文件定义鼓励执行规则的实体在其接受的内容上自由。但是，对于用户名和密码，这样的策略可能会有问题，因为它会导致错误的接受。深入讨论见[RFC6943]。
Applying the rules for any given PRECIS profile is not necessarily an idempotent procedure for all code points. Therefore, an implementation SHOULD apply the rules repeatedly until the output string is stable; if the output string does not stabilize after reapplying the rules three (3) additional times after the first application, the implementation SHOULD terminate application of the rules and reject the input string as invalid.
对任何给定的PRECIS剖面应用规则并不一定是对所有代码点的幂等过程。因此，实现应该重复应用规则，直到输出字符串稳定为止；如果输出字符串在第一次应用后再次应用规则三（3）次后不稳定，则实现应终止规则的应用，并将输入字符串视为无效而拒绝。
The rules defined in this specification differ slightly from those defined by the SASLprep specification [RFC4013] (but not from [RFC7613]). In order to smooth the process of migrating from SASLprep to the approach defined herein, the following sections describe these differences, along with their implications for migration, in more detail.
本规范中定义的规则与SASLprep规范[RFC4013]（但与[RFC7613]）中定义的规则略有不同。为了使从SASLprep迁移到本文定义的方法的过程更加顺利，以下各节将更详细地描述这些差异及其对迁移的影响。
Deployments that currently use SASLprep for handling usernames might need to scrub existing data when they migrate to the rules defined in this specification. In particular:
当前使用SASLprep处理用户名的部署在迁移到此规范中定义的规则时可能需要清除现有数据。特别地：
o SASLprep specified the use of Unicode Normalization Form KC (NFKC), whereas the UsernameCaseMapped and UsernameCasePreserved profiles employ Unicode Normalization Form C (NFC). In practice, this change is unlikely to cause significant problems, because NFKC provides methods for mapping Unicode code points with compatibility equivalents to those equivalents, whereas the PRECIS
o SASLprep指定使用Unicode规范化表单KC（NFKC），而UsernameCaseMapped和UsernameCasePreserved配置文件使用Unicode规范化表单C（NFC）。实际上，这种更改不太可能引起重大问题，因为NFKC提供了将具有兼容性等价物的Unicode代码点映射到这些等价物的方法，而PRECIS
IdentifierClass entirely disallows Unicode code points with compatibility equivalents (i.e., during comparison, NFKC is more "aggressive" about finding matches than NFC). A few examples might suffice to indicate the nature of the problem:
IdentifierClass完全不允许具有兼容等价物的Unicode代码点（即，在比较过程中，NFKC比NFC更“积极”地查找匹配项）。几个例子可能足以说明问题的性质：
1. "ſ" (LATIN SMALL LETTER LONG S, U+017F) is compatibility equivalent to "s" (LATIN SMALL LETTER S, U+0073).
1. “ſ”（拉丁文小写字母长S，U+017F）的兼容性等同于“S”（拉丁文小写字母S，U+0073）。
2. "Ⅳ" (ROMAN NUMERAL FOUR, U+2163) is compatibility equivalent to "I" (LATIN CAPITAL LETTER I, U+0049) and "V" (LATIN CAPITAL LETTER V, U+0056).
2. “Ⅳ”（罗马数字四，U+2163）与“I”（拉丁文大写字母I，U+0049）和“V”（拉丁文大写字母V，U+0056）的兼容性相当。
3. "fi" (LATIN SMALL LIGATURE FI, U+FB01) is compatibility equivalent to "f" (LATIN SMALL LETTER F, U+0066) and "i" (LATIN SMALL LETTER I, U+0069).
3. “FI”（拉丁文小写连字FI，U+FB01）与“f”（拉丁文小写字母f，U+0066）和“i”（拉丁文小写字母i，U+0069）的兼容性相当。
Under SASLprep, the use of NFKC also handled the mapping of fullwidth and halfwidth code points to their decomposition mappings.
在SASLprep下，NFKC的使用还处理了全宽和半宽代码点到其分解映射的映射。
For migration purposes, operators might want to search their database of usernames for names containing Unicode code points with compatibility equivalents and, where there is no conflict, map those code points to their equivalents. Naturally, it is possible that during this process the operator will discover conflicting usernames; for instance, "HENRYIV" with the last two code points being LATIN CAPITAL LETTER I (U+0049) and LATIN CAPITAL LETTER V (U+0056) as opposed to "HENRYⅣ" with the last character being "Ⅳ" (ROMAN NUMERAL FOUR, U+2163), which is compatibility equivalent to U+0049 and U+0056). In these cases, the operator will need to determine how to proceed, for instance, by disabling the account whose name contains a Unicode code point with a compatibility equivalent. Such cases are probably rare, but it is important for operators to be aware of them.
出于迁移目的，运营商可能希望在其用户名数据库中搜索包含具有兼容性等价物的Unicode代码点的名称，并且在没有冲突的情况下，将这些代码点映射到其等价物。当然，在这个过程中，操作员可能会发现有冲突的用户名；例如，“亨利四世”的最后两个代码点是拉丁大写字母I（U+0049）和拉丁大写字母V（U+0056），而“亨利四世”的最后一个字符是“Ⅳ”（罗马数字四，U+2163），这与U+0049和U+0056的兼容性相当。在这些情况下，操作员将需要确定如何继续，例如，通过禁用名称包含具有等效兼容性的Unicode代码点的帐户。这种情况可能很少见，但运营商必须意识到这一点。
o SASLprep mapped the "characters commonly mapped to nothing" (from Appendix B.1 of [RFC3454]) to nothing, whereas the PRECIS IdentifierClass entirely disallows most of these code points, which correspond to the code points from the PRECIS "M" category defined under Section 9.13 of [RFC8264]. For migration purposes, the operator might want to remove from usernames any code points contained in the PRECIS "M" category (e.g., SOFT HYPHEN (U+00AD)). Because these code points would have been "mapped to nothing" in Stringprep, in practice a user would not notice the difference if, upon migration to PRECIS, the code points are removed.
o SASLprep将“通常映射为零的字符”（来自[RFC3454]的附录B.1）映射为零，而PRECIS IdentifierClass完全不允许这些代码点中的大多数，它们对应于[RFC8264]第9.13节定义的PRECIS“M”类别中的代码点。出于迁移目的，操作员可能希望从用户名中删除PRECIS“M”类别中包含的任何代码点（例如，软连字符（U+00AD））。因为这些代码点在Stringprep中“映射为空”，实际上，如果在迁移到PRECIS时删除了代码点，用户不会注意到差异。
o SASLprep allowed uppercase and titlecase code points, whereas the UsernameCaseMapped profile maps uppercase and titlecase code
o SASLprep允许大写和标题代码点，而UsernameCaseMapped配置文件映射大写和标题代码
points to their lowercase equivalents (by contrast, the UsernameCasePreserved profile matches SASLprep in this regard). For migration purposes, the operator can use either the UsernameCaseMapped profile (thus losing the case information) or the UsernameCasePreserved profile (thus ignoring case difference when comparing usernames).
指向它们的小写等价物（相比之下，UsernameCasePreserved配置文件在这方面与SASLprep匹配）。出于迁移目的，操作员可以使用UsernameCaseMapped配置文件（从而丢失案例信息）或usernamecaseperved配置文件（从而在比较用户名时忽略案例差异）。
Depending on local service policy, migration from SASLprep to this specification might not involve any scrubbing of data (because passwords might not be stored in the clear anyway); however, service providers need to be aware of possible issues that might arise during migration. In particular:
根据本地服务策略，从SASLprep迁移到此规范可能不涉及任何数据清理（因为密码可能不会存储在clear中）；但是，服务提供商需要了解迁移过程中可能出现的问题。特别地：
o SASLprep specified the use of Unicode Normalization Form KC (NFKC), whereas the OpaqueString profile employs Unicode Normalization Form C (NFC). Because NFKC is more aggressive about finding matches than NFC, in practice this change is unlikely to cause significant problems and indeed has the security benefit of probably resulting in fewer false accepts when comparing passwords. A few examples might suffice to indicate the nature of the problem:
o SASLprep指定使用Unicode规范化表单KC（NFKC），而OpaqueString配置文件使用Unicode规范化表单C（NFC）。由于NFKC在查找匹配项方面比NFC更具攻击性，因此在实践中，此更改不太可能导致重大问题，并且确实具有安全性优势，在比较密码时可能会导致更少的错误接受。几个例子可能足以说明问题的性质：
1. "ſ" (LATIN SMALL LETTER LONG S, U+017F) is compatibility equivalent to "s" (LATIN SMALL LETTER S, U+0073).
1. “ſ”（拉丁文小写字母长S，U+017F）的兼容性等同于“S”（拉丁文小写字母S，U+0073）。
2. "Ⅳ" (ROMAN NUMERAL FOUR, U+2163) is compatibility equivalent to "I" (LATIN CAPITAL LETTER I, U+0049) and "V" (LATIN CAPITAL LETTER V, U+0056).
2. “Ⅳ”（罗马数字四，U+2163）与“I”（拉丁文大写字母I，U+0049）和“V”（拉丁文大写字母V，U+0056）的兼容性相当。
3. "fi" (LATIN SMALL LIGATURE FI, U+FB01) is compatibility equivalent to "f" (LATIN SMALL LETTER F, U+0066) and "i" (LATIN SMALL LETTER I, U+0069).
3. “FI”（拉丁文小写连字FI，U+FB01）与“f”（拉丁文小写字母f，U+0066）和“i”（拉丁文小写字母i，U+0069）的兼容性相当。
Under SASLprep, the use of NFKC also handled the mapping of fullwidth and halfwidth code points to their decomposition mappings. Although it is expected that code points with compatibility equivalents are rare in existing passwords, some passwords that matched when SASLprep was used might no longer work when the rules in this specification are applied.
在SASLprep下，NFKC的使用还处理了全宽和半宽代码点到其分解映射的映射。虽然在现有密码中，具有兼容性等价物的代码点是很少见的，但当应用本规范中的规则时，使用SASLprep时匹配的某些密码可能不再有效。
o SASLprep mapped the "characters commonly mapped to nothing" (from Appendix B.1 of [RFC3454]) to nothing, whereas the PRECIS FreeformClass entirely disallows such code points, which correspond to the code points from the PRECIS "M" category defined under Section 9.13 of [RFC8264]. In practice, this change will probably have no effect on comparison, but user-oriented software
o SASLprep将“通常映射为零的字符”（来自[RFC3454]的附录B.1）映射为零，而PRECIS FreeformClass完全不允许此类代码点，这些代码点对应于[RFC8264]第9.13节定义的PRECIS“M”类别的代码点。在实践中，这种变化可能不会对比较产生影响，但会影响面向用户的软件
might reject such code points instead of ignoring them during password preparation.
可能会拒绝这些代码点，而不是在密码准备过程中忽略它们。
IANA has made the updates described below.
IANA已进行了如下所述的更新。
IANA has added the following entry to the "PRECIS Profiles" registry.
IANA已将以下条目添加到“PRECIS配置文件”注册表中。
Name: UsernameCaseMapped.
名称：UsernameCaseMapped。
Base Class: IdentifierClass.
基类：IdentifierClass。
Applicability: Usernames in security and application protocols.
适用性：安全和应用程序协议中的用户名。
Replaces: The SASLprep profile of Stringprep.
替换：Stringprep的SASLprep配置文件。
Width Mapping Rule: Map fullwidth and halfwidth code points to their decomposition mappings.
宽度映射规则：将全宽度和半宽度代码点映射到它们的分解映射。
Additional Mapping Rule: None.
其他映射规则：无。
Case Mapping Rule: Map uppercase and titlecase code points to lowercase.
大小写映射规则：将大写和titlecase代码点映射为小写。
Normalization Rule: NFC.
规范化规则：NFC。
Directionality Rule: The "Bidi Rule" defined in RFC 5893 applies.
方向性规则：RFC 5893中定义的“比迪规则”适用。
Enforcement: To be defined by security or application protocols that use this profile.
强制：由使用此配置文件的安全协议或应用程序协议定义。
Specification: Section 3.3 of RFC 8265.
规范：RFC 8265第3.3节。
IANA has added the following entry to the "PRECIS Profiles" registry.
IANA已将以下条目添加到“PRECIS配置文件”注册表中。
Name: UsernameCasePreserved.
名称：UsernameCasePreserved。
Base Class: IdentifierClass.
基类：IdentifierClass。
Applicability: Usernames in security and application protocols.
适用性：安全和应用程序协议中的用户名。
Replaces: The SASLprep profile of Stringprep.
替换：Stringprep的SASLprep配置文件。
Width Mapping Rule: Map fullwidth and halfwidth code points to their decomposition mappings.
宽度映射规则：将全宽度和半宽度代码点映射到它们的分解映射。
Additional Mapping Rule: None.
其他映射规则：无。
Case Mapping Rule: None.
案例映射规则：无。
Normalization Rule: NFC.
规范化规则：NFC。
Directionality Rule: The "Bidi Rule" defined in RFC 5893 applies.
方向性规则：RFC 5893中定义的“比迪规则”适用。
Enforcement: To be defined by security or application protocols that use this profile.
强制：由使用此配置文件的安全协议或应用程序协议定义。
Specification: Section 3.4 of RFC 8265.
规范：RFC 8265第3.4节。
IANA has added the following entry to the "PRECIS Profiles" registry.
IANA已将以下条目添加到“PRECIS配置文件”注册表中。
Name: OpaqueString.
名称：OpaqueString。
Base Class: FreeformClass.
基类：FreeformClass。
Applicability: Passwords and other opaque strings in security and application protocols.
适用性：安全和应用程序协议中的密码和其他不透明字符串。
Replaces: The SASLprep profile of Stringprep.
替换：Stringprep的SASLprep配置文件。
Width Mapping Rule: None.
宽度映射规则：无。
Additional Mapping Rule: Map non-ASCII space code points to SPACE (U+0020).
附加映射规则：将非ASCII空间代码点映射到空间（U+0020）。
Case Mapping Rule: None.
案例映射规则：无。
Normalization Rule: NFC.
规范化规则：NFC。
Directionality Rule: None.
方向性规则：无。
Enforcement: To be defined by security or application protocols that use this profile.
强制：由使用此配置文件的安全协议或应用程序协议定义。
Specification: Section 4.2 of RFC 8265.
规范：RFC 8265第4.2节。
The Stringprep specification [RFC3454] did not provide for entries in the "Stringprep Profiles" registry to have any state except "Current" or "Not Current". Because RFC 7613 obsoleted RFC 4013, which registered the SASLprep profile of Stringprep, IANA previously marked that profile as "Not Current" and cited RFC 7613 as an additional reference. IANA has modified the profile so that the current document is now cited as the additional reference.
Stringprep规范[RFC3454]未规定“Stringprep配置文件”注册表中的条目具有除“当前”或“非当前”之外的任何状态。由于RFC 7613淘汰了RFC 4013，后者注册了Stringprep的SASLprep配置文件，IANA先前将该配置文件标记为“非最新”，并引用RFC 7613作为附加参考。IANA已经修改了概要文件，因此现在引用当前文件作为附加参考。
The ability to include a wide range of characters in passwords and passphrases can increase the potential for creating a strong password with high entropy. However, in practice, the ability to include such characters ought to be weighed against the possible need to reproduce them on various devices using various input methods.
在密码和密码短语中包含大量字符的能力可以增加创建高熵强密码的可能性。然而，在实践中，包括这些字符的能力应该与使用各种输入方法在各种设备上重现这些字符的可能需要进行权衡。
In systems that conform to modern best practices for security, verification of passwords during authentication will not use the comparison defined in Section 4.2.3. Instead, because the system performs cryptographic calculations to verify the password, it will prepare the password as defined in Section 4.2.1 and enforce the rules as defined in Section 4.2.2 before performing the relevant calculations.
在符合现代安全最佳实践的系统中，验证期间的密码验证将不会使用第4.2.3节中定义的比较。相反，由于系统执行加密计算以验证密码，因此在执行相关计算之前，系统将按照第4.2.1节中的定义准备密码，并执行第4.2.2节中定义的规则。
The process of comparing identifiers (such as SASL simple usernames, authentication identifiers, and authorization identifiers) can lead to either false rejects or false accepts, both of which have security implications. A more detailed discussion can be found in [RFC6943].
比较标识符（如SASL简单用户名、身份验证标识符和授权标识符）的过程可能导致错误拒绝或错误接受，这两种情况都有安全隐患。更详细的讨论见[RFC6943]。
The security considerations described in [RFC8264] apply to the IdentifierClass and FreeformClass string classes used in this document for usernames and passwords, respectively.
[RFC8264]中描述的安全注意事项分别适用于本文档中用于用户名和密码的IdentifierClass和FreeformClass字符串类。
The security considerations described in [UTS39] apply to the use of Unicode code points in usernames and passwords.
[UTS39]中描述的安全注意事项适用于在用户名和密码中使用Unicode代码点。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<https://www.rfc-editor.org/info/rfc3629>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 5890，DOI 10.17487/RFC5890，2010年8月<https://www.rfc-editor.org/info/rfc5890>.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011, <https://www.rfc-editor.org/info/rfc6365>.
[RFC6365]Hoffman，P.和J.Klensin，“IETF国际化中使用的术语”，BCP 166，RFC 6365，DOI 10.17487/RFC6365，2011年9月<https://www.rfc-editor.org/info/rfc6365>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 8264, DOI 10.17487/RFC8264, October 2017, <https://www.rfc-editor.org/info/rfc8264>.
[RFC8264]Saint Andre，P.和M.Blanchet，“PRECIS框架：应用协议中国际化字符串的准备、实施和比较”，RFC 8264，DOI 10.17487/RFC8264，2017年10月<https://www.rfc-editor.org/info/rfc8264>.
[UAX11] Unicode Standard Annex #11, "East Asian Width", edited by Ken Lunde. An integral part of The Unicode Standard, <http://unicode.org/reports/tr11/>.
[UAX11]Unicode标准附件#11，“东亚宽度”，Ken Lunde编辑。Unicode标准不可分割的一部分<http://unicode.org/reports/tr11/>.
[Unicode] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[Unicode]Unicode联盟，“Unicode标准”<http://www.unicode.org/versions/latest/>.
[Err1812] RFC Errata, Erratum ID 1812, RFC 4013, <https://www.rfc-editor.org/errata/eid1812>.
[Err1812]RFC勘误表，勘误表ID 1812，RFC 4013<https://www.rfc-editor.org/errata/eid1812>.
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，STD 80，RFC 20，DOI 10.17487/RFC0020，1969年10月<https://www.rfc-editor.org/info/rfc20>.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, DOI 10.17487/RFC3454, December 2002, <https://www.rfc-editor.org/info/rfc3454>.
[RFC3454]Hoffman，P.和M.Blanchet，“国际化字符串的准备（“stringprep”）”，RFC 3454，DOI 10.17487/RFC3454，2002年12月<https://www.rfc-editor.org/info/rfc3454>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <https://www.rfc-editor.org/info/rfc3501>.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 3501，DOI 10.17487/RFC3501，2003年3月<https://www.rfc-editor.org/info/rfc3501>.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, <https://www.rfc-editor.org/info/rfc3987>.
[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，DOI 10.17487/RFC3987，2005年1月<https://www.rfc-editor.org/info/rfc3987>.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, DOI 10.17487/RFC4013, February 2005, <https://www.rfc-editor.org/info/rfc4013>.
[RFC4013]Zeilenga，K.，“SASLprep：用户名和密码的Stringprep配置文件”，RFC 4013，DOI 10.17487/RFC4013，2005年2月<https://www.rfc-editor.org/info/rfc4013>.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, <https://www.rfc-editor.org/info/rfc4422>.
[RFC4422]Melnikov，A.，Ed.和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，DOI 10.17487/RFC4422，2006年6月<https://www.rfc-editor.org/info/rfc4422>.
[RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, DOI 10.17487/RFC4616, August 2006, <https://www.rfc-editor.org/info/rfc4616>.
[RFC4616]Zeilenga，K.，Ed.“简单认证和安全层（SASL）机制”，RFC 4616，DOI 10.17487/RFC4616，2006年8月<https://www.rfc-editor.org/info/rfc4616>.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, DOI 10.17487/RFC5802, July 2010, <https://www.rfc-editor.org/info/rfc5802>.
[RFC5802]Newman，C.，Menon Sen，A.，Melnikov，A.，和N.Williams，“盐渍挑战响应认证机制（SCRAM）SASL和GSS-API机制”，RFC 5802，DOI 10.17487/RFC5802，2010年7月<https://www.rfc-editor.org/info/rfc5802>.
[RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, <https://www.rfc-editor.org/info/rfc5893>.
[RFC5893]Alvestrand，H.，Ed.和C.Karp，“应用程序国际化域名（IDNA）的从右到左脚本”，RFC 5893，DOI 10.17487/RFC5893，2010年8月<https://www.rfc-editor.org/info/rfc5893>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC 6120，DOI 10.17487/RFC6120，2011年3月<https://www.rfc-editor.org/info/rfc6120>.
[RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 2013, <https://www.rfc-editor.org/info/rfc6943>.
[RFC6943]Thaler，D.，Ed.，“出于安全目的的标识符比较问题”，RFC 6943，DOI 10.17487/RFC6943，2013年5月<https://www.rfc-editor.org/info/rfc6943>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015, <https://www.rfc-editor.org/info/rfc7542>.
[RFC7542]DeKok，A.，“网络访问标识符”，RFC 7542，DOI 10.17487/RFC7542，2015年5月<https://www.rfc-editor.org/info/rfc7542>.
[RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 7613, DOI 10.17487/RFC7613, August 2015, <https://www.rfc-editor.org/info/rfc7613>.
[RFC7613]Saint Andre，P.和A.Melnikov，“代表用户名和密码的国际化字符串的准备、实施和比较”，RFC 7613，DOI 10.17487/RFC7613，2015年8月<https://www.rfc-editor.org/info/rfc7613>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <https://www.rfc-editor.org/info/rfc7616>.
[RFC7616]Shekh Yusef，R.，Ed.，Ahrens，D.，和S.Bremer，“HTTP摘要访问认证”，RFC 7616，DOI 10.17487/RFC76162015年9月<https://www.rfc-editor.org/info/rfc7616>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, <https://www.rfc-editor.org/info/rfc7617>.
[RFC7617]Reschke，J.“基本”HTTP认证方案”，RFC 7617，DOI 10.17487/RFC76172015年9月<https://www.rfc-editor.org/info/rfc7617>.
[RFC7622] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Address Format", RFC 7622, DOI 10.17487/RFC7622, September 2015, <https://www.rfc-editor.org/info/rfc7622>.
[RFC7622]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：地址格式”，RFC 7622，DOI 10.17487/RFC7622，2015年9月<https://www.rfc-editor.org/info/rfc7622>.
[RFC8266] Saint-Andre, P., "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames", RFC 8266, DOI 10.17487/RFC8266, October 2017, <https://www.rfc-editor.org/info/rfc8266>.
[RFC8266]Saint Andre，P.，“代表昵称的国际化字符串的准备、实施和比较”，RFC 8266，DOI 10.17487/RFC8266，2017年10月<https://www.rfc-editor.org/info/rfc8266>.
[UTS39] Unicode Technical Standard #39, "Unicode Security Mechanisms", edited by Mark Davis and Michel Suignard, <http://unicode.org/reports/tr39/>.
[UTS39]Unicode技术标准#39，“Unicode安全机制”，由Mark Davis和Michel Suignard编辑<http://unicode.org/reports/tr39/>.
The following changes were made from [RFC7613].
对[RFC7613]进行了以下更改。
o Corrected the order of operations for the UsernameCaseMapped profile to ensure consistency with [RFC8264].
o 更正了UsernameCaseMapped配置文件的操作顺序，以确保与[RFC8264]一致。
o In accordance with working group discussions and updates to [RFC8264], removed the use of the Unicode toCaseFold() operation in favor of the Unicode toLowerCase() operation.
o 根据工作组的讨论和对[RFC8264]的更新，取消了Unicode toCaseFold（）操作的使用，转而使用Unicode toLowerCase（）操作。
o Modified the presentation (but not the content) of the rules.
o 修改了规则的表示（但不是内容）。
o Removed UTF-8 as a mandatory encoding, because that is a matter for the application.
o 删除了UTF-8作为强制编码，因为这是应用程序的问题。
o Clarified several editorial matters.
o 澄清了一些编辑事项。
o Updated references.
o 更新参考资料。
See [RFC7613] for a description of the differences from [RFC4013].
有关与[RFC4013]的差异说明，请参见[RFC7613]。
Acknowledgements
致谢
Thanks to Christian Schudt and Sam Whited for their bug reports and feedback.
感谢Christian Schudt和Sam Whited的bug报告和反馈。
See [RFC7613] for acknowledgements related to the specification that this document supersedes.
参见[RFC7613]了解与本文件所取代规范相关的确认。
Authors' Addresses
作者地址
Peter Saint-Andre Jabber.org P.O. Box 787 Parker, CO 80134 United States of America
Peter Saint Andre Jabber.org美国科罗拉多州帕克787号邮政信箱80134
Phone: +1 720 256 6756
Email: stpeter@jabber.org
URI: https://www.jabber.org/
Phone: +1 720 256 6756
Email: stpeter@jabber.org
URI: https://www.jabber.org/
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX United Kingdom
英国米德尔塞克斯郡汉普顿车站路36号城堡商业村5号Alexey Melnikov Isode有限公司TW12 2BX
Email: Alexey.Melnikov@isode.com
Email: Alexey.Melnikov@isode.com