doc: Add RFC documents

1 files changed, 1458 insertions, 0 deletions

diff --git a/doc/rfc/rfc8265.txt b/doc/rfc/rfc8265.txt
new file mode 100644
index 0000000..94d823c
--- /dev/null
+++ b/doc/rfc/rfc8265.txt
@@ -0,0 +1,1458 @@
+
+
+
+
+
+
+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
+
+
+ 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.
+
+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.
+
+   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.
+
+Copyright Notice
+
+   Copyright (c) 2017 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+
+
+
+Saint-Andre & Melnikov       Standards Track                    [Page 1]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+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
+
+
+
+
+Saint-Andre & Melnikov       Standards Track                    [Page 2]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+1.  Introduction
+
+   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]).
+
+   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].
+
+   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").
+
+   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.)
+
+   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.
+
+
+
+
+Saint-Andre & Melnikov       Standards Track                    [Page 3]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+   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].
+
+   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.
+
+2.  Terminology
+
+   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]).
+
+   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.
+
+
+
+Saint-Andre & Melnikov       Standards Track                    [Page 4]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+   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).
+
+   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.
+
+3.  Usernames
+
+3.1.  Definition
+
+   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.
+
+   The syntax for a username is defined as follows, using the Augmented
+   Backus-Naur Form (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
+                   ;
+
+   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].
+
+      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
+
+
+
+Saint-Andre & Melnikov       Standards Track                    [Page 5]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+      existing SASL mechanisms and in application protocols that use
+      SASL, and even in most application protocols that do not currently
+      use 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).
+
+   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.
+
+3.2.  Case Mapping vs. Case Preservation
+
+   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.
+
+   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.
+
+   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],
+
+
+
+Saint-Andre & Melnikov       Standards Track                    [Page 6]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+      SASL mechanisms are not to apply this or any other profile to
+      authorization identifiers, only to authentication identifiers.
+
+   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  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).
+
+   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).
+
+3.3.  UsernameCaseMapped Profile
+
+3.3.1.  Rules
+
+   The following rules are defined for use within the UsernameCaseMapped
+   profile of the PRECIS IdentifierClass.
+
+   1.  Width Mapping Rule: Map fullwidth and halfwidth code points to
+       their decomposition mappings (see Unicode Standard Annex #11
+       [UAX11]).
+
+   2.  Additional Mapping Rule: There is no additional mapping rule.
+
+
+
+
+
+Saint-Andre & Melnikov       Standards Track                    [Page 7]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+   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.
+
+   4.  Normalization Rule: Apply Unicode Normalization Form C (NFC) to
+       all strings.
+
+   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.
+
+3.3.2.  Preparation
+
+   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.
+
+   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].
+
+3.3.3.  Enforcement
+
+   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:
+
+   1.  Case Mapping Rule
+
+   2.  Normalization Rule
+
+   3.  Directionality Rule
+
+   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).
+
+
+
+Saint-Andre & Melnikov       Standards Track                    [Page 8]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+   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).
+
+3.3.4.  Comparison
+
+   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").
+
+   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).
+
+3.4.  UsernameCasePreserved Profile
+
+3.4.1.  Rules
+
+   The following rules are defined for use within the
+   UsernameCasePreserved profile of the PRECIS IdentifierClass.
+
+   1.  Width Mapping Rule: Map fullwidth and halfwidth code points to
+       their decomposition mappings (see Unicode Standard Annex #11
+       [UAX11]).
+
+   2.  Additional Mapping Rule: There is no additional mapping rule.
+
+   3.  Case Mapping Rule: There is no case mapping rule.
+
+   4.  Normalization Rule: Apply Unicode Normalization Form C (NFC) to
+       all strings.
+
+   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.
+
+3.4.2.  Preparation
+
+   An entity that prepares a string for subsequent enforcement according
+   to this profile MUST proceed as follows (applying the steps in the
+   order shown).
+
+
+
+Saint-Andre & Melnikov       Standards Track                    [Page 9]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+   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.
+
+   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].
+
+3.4.3.  Enforcement
+
+   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:
+
+   1.  Normalization Rule
+
+   2.  Directionality Rule
+
+   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).
+
+3.4.4.  Comparison
+
+   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").
+
+   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).
+
+
+
+
+
+
+Saint-Andre & Melnikov       Standards Track                   [Page 10]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+3.5.  Application-Layer Constructs
+
+   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).
+
+3.6.  Examples
+
+   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)     |
+      +--------------------------+---------------------------------+
+
+                   Table 1: A Sample of Legal Userparts
+
+   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
+
+
+
+Saint-Andre & Melnikov       Standards Track                   [Page 11]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+   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.
+
+   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) |
+      +--------------------------+---------------------------------+
+
+       Table 2: A Sample of Strings That Violate the Userpart Rules
+
+   Regarding example 8: although this is not a valid userpart, it is a
+   valid username because it is a space-separated sequence of userparts.
+
+   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.
+
+   Regarding example 11: symbol characters such as "∞" (INFINITY,
+   U+221E) are not allowed in the PRECIS IdentifierClass.
+
+
+
+
+
+
+
+Saint-Andre & Melnikov       Standards Track                   [Page 12]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+4.  Passwords
+
+4.1.  Definition
+
+   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]).
+
+   The syntax for a password is defined as follows, using the Augmented
+   Backus-Naur Form (ABNF) [RFC5234].
+
+      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]).
+
+   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.
+
+      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
+
+
+
+Saint-Andre & Melnikov       Standards Track                   [Page 13]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+   the algorithm, because the password is not available to the server in
+   plaintext form.
+
+4.2.  OpaqueString Profile
+
+   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]).
+
+4.2.1.  Preparation
+
+   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].
+
+4.2.2.  Enforcement
+
+   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):
+
+   1.  Width Mapping Rule: Fullwidth and halfwidth code points MUST NOT
+       be mapped to their decomposition mappings (see Unicode Standard
+       Annex #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.
+
+   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).
+
+   4.  Normalization Rule: Unicode Normalization Form C (NFC) MUST be
+       applied to all strings.
+
+   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
+
+
+
+Saint-Andre & Melnikov       Standards Track                   [Page 14]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+       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).
+
+4.2.3.  Comparison
+
+   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").
+
+   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.
+
+4.3.  Examples
+
+   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).
+
+
+
+
+
+
+
+
+
+
+
+
+Saint-Andre & Melnikov       Standards Track                   [Page 15]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+   +------------------------------------+------------------------------+
+   | # | 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
+
+   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 &#x9;by>          | Control characters like TAB  |
+   |   |                                | (U+0009) are disallowed      |
+   +------------------------------------+------------------------------+
+
+       Table 4: A Sample of Strings That Violate the Password Rules
+
+   Note: Following the "XML Notation" used in [RFC3987], the character
+   TAB (U+0009) in example 18 is represented as &#x9 because otherwise
+   it could not be shown in running text.
+
+5.  Use in Application Protocols
+
+   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
+
+
+
+Saint-Andre & Melnikov       Standards Track                   [Page 16]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+   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.
+
+   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.
+
+   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].
+
+   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.
+
+6.  Migration
+
+   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.
+
+6.1.  Usernames
+
+   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:
+
+   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
+
+
+
+Saint-Andre & Melnikov       Standards Track                   [Page 17]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+      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:
+
+      1.  "ſ" (LATIN SMALL LETTER LONG S, U+017F) is compatibility
+          equivalent to "s" (LATIN SMALL LETTER 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).
+
+      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).
+
+      Under SASLprep, the use of NFKC also handled the mapping of
+      fullwidth and halfwidth code points to their decomposition
+      mappings.
+
+      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.
+
+   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 allowed uppercase and titlecase code points, whereas the
+      UsernameCaseMapped profile maps uppercase and titlecase code
+
+
+
+Saint-Andre & Melnikov       Standards Track                   [Page 18]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+      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).
+
+6.2.  Passwords
+
+   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:
+
+   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:
+
+      1.  "ſ" (LATIN SMALL LETTER LONG S, U+017F) is compatibility
+          equivalent to "s" (LATIN SMALL LETTER 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).
+
+      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).
+
+      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.
+
+   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
+
+
+
+Saint-Andre & Melnikov       Standards Track                   [Page 19]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+      might reject such code points instead of ignoring them during
+      password preparation.
+
+7.  IANA Considerations
+
+   IANA has made the updates described below.
+
+7.1.  UsernameCaseMapped Profile
+
+   IANA has added the following entry to the "PRECIS Profiles" registry.
+
+   Name:  UsernameCaseMapped.
+
+   Base Class:  IdentifierClass.
+
+   Applicability:  Usernames in security and application protocols.
+
+   Replaces:  The SASLprep profile of Stringprep.
+
+   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.
+
+   Normalization Rule:  NFC.
+
+   Directionality Rule:  The "Bidi Rule" defined in RFC 5893 applies.
+
+   Enforcement:  To be defined by security or application protocols that
+      use this profile.
+
+   Specification:  Section 3.3 of RFC 8265.
+
+7.2.  UsernameCasePreserved Profile
+
+   IANA has added the following entry to the "PRECIS Profiles" registry.
+
+   Name:  UsernameCasePreserved.
+
+   Base Class:  IdentifierClass.
+
+   Applicability:  Usernames in security and application protocols.
+
+   Replaces:  The SASLprep profile of Stringprep.
+
+
+
+
+Saint-Andre & Melnikov       Standards Track                   [Page 20]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+   Width Mapping Rule:  Map fullwidth and halfwidth code points to their
+      decomposition mappings.
+
+   Additional Mapping Rule:  None.
+
+   Case Mapping Rule:  None.
+
+   Normalization Rule:  NFC.
+
+   Directionality Rule:  The "Bidi Rule" defined in RFC 5893 applies.
+
+   Enforcement:  To be defined by security or application protocols that
+      use this profile.
+
+   Specification:  Section 3.4 of RFC 8265.
+
+7.3.  OpaqueString Profile
+
+   IANA has added the following entry to the "PRECIS Profiles" registry.
+
+   Name:  OpaqueString.
+
+   Base Class:  FreeformClass.
+
+   Applicability:  Passwords and other opaque strings in security and
+      application protocols.
+
+   Replaces:  The SASLprep profile of Stringprep.
+
+   Width Mapping Rule:  None.
+
+   Additional Mapping Rule:  Map non-ASCII space code points to SPACE
+      (U+0020).
+
+   Case Mapping Rule:  None.
+
+   Normalization Rule:  NFC.
+
+   Directionality Rule:  None.
+
+   Enforcement:  To be defined by security or application protocols that
+      use this profile.
+
+   Specification:  Section 4.2 of RFC 8265.
+
+
+
+
+
+
+
+Saint-Andre & Melnikov       Standards Track                   [Page 21]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+7.4.  Stringprep Profile
+
+   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.
+
+8.  Security Considerations
+
+8.1.  Password/Passphrase Strength
+
+   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.
+
+8.2.  Password/Passphrase Comparison
+
+   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.
+
+8.3.  Identifier Comparison
+
+   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].
+
+8.4.  Reuse of PRECIS
+
+   The security considerations described in [RFC8264] apply to the
+   IdentifierClass and FreeformClass string classes used in this
+   document for usernames and passwords, respectively.
+
+8.5.  Reuse of Unicode
+
+   The security considerations described in [UTS39] apply to the use of
+   Unicode code points in usernames and passwords.
+
+
+
+
+Saint-Andre & Melnikov       Standards Track                   [Page 22]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+9.  References
+
+9.1.  Normative References
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [UAX11]    Unicode Standard Annex #11, "East Asian Width", edited by
+              Ken Lunde.  An integral part of The Unicode Standard,
+              <http://unicode.org/reports/tr11/>.
+
+   [Unicode]  The Unicode Consortium, "The Unicode Standard",
+              <http://www.unicode.org/versions/latest/>.
+
+
+
+
+
+
+
+Saint-Andre & Melnikov       Standards Track                   [Page 23]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+9.2.  Informative References
+
+   [Err1812]  RFC Errata, Erratum 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>.
+
+   [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>.
+
+   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+              4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
+              <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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+
+Saint-Andre & Melnikov       Standards Track                   [Page 24]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+   [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>.
+
+   [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>.
+
+   [RFC7542]  DeKok, A., "The Network Access Identifier", RFC 7542,
+              DOI 10.17487/RFC7542, May 2015,
+              <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>.
+
+   [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>.
+
+   [RFC7617]  Reschke, J., "The 'Basic' HTTP Authentication Scheme",
+              RFC 7617, DOI 10.17487/RFC7617, September 2015,
+              <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>.
+
+   [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>.
+
+   [UTS39]    Unicode Technical Standard #39, "Unicode Security
+              Mechanisms", edited by Mark Davis and Michel Suignard,
+              <http://unicode.org/reports/tr39/>.
+
+Appendix A.  Changes from RFC 7613
+
+   The following changes were made from [RFC7613].
+
+   o  Corrected the order of operations for the UsernameCaseMapped
+      profile to ensure consistency with [RFC8264].
+
+
+
+
+Saint-Andre & Melnikov       Standards Track                   [Page 25]
+
+RFC 8265             PRECIS: Usernames and Passwords        October 2017
+
+
+   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  Modified the presentation (but not the content) of the rules.
+
+   o  Removed UTF-8 as a mandatory encoding, because that is a matter
+      for the application.
+
+   o  Clarified several editorial matters.
+
+   o  Updated references.
+
+   See [RFC7613] for a description of the differences from [RFC4013].
+
+Acknowledgements
+
+   Thanks to Christian Schudt and Sam Whited for their bug reports and
+   feedback.
+
+   See [RFC7613] for acknowledgements related to the specification that
+   this document supersedes.
+
+Authors' Addresses
+
+   Peter Saint-Andre
+   Jabber.org
+   P.O. Box 787
+   Parker, CO  80134
+   United States of America
+
+   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
+
+   Email: Alexey.Melnikov@isode.com
+
+
+
+
+
+
+
+Saint-Andre & Melnikov       Standards Track                   [Page 26]