tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7564

 
 
 

PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols

Part 3 of 3, p. 27 to 40
Prev RFC Part

 


prevText      Top      Up      ToC       Page 27 
11.  IANA Considerations

11.1.  PRECIS Derived Property Value Registry

   IANA has created and now maintains the "PRECIS Derived Property
   Value" registry that records the derived properties for the versions
   of Unicode that are released after (and including) version 7.0.  The
   derived property value is to be calculated in cooperation with a
   designated expert [RFC5226] according to the rules specified under
   Sections 8 and 9.

   The IESG is to be notified if backward-incompatible changes to the
   table of derived properties are discovered or if other problems arise
   during the process of creating the table of derived property values
   or during expert review.  Changes to the rules defined under
   Sections 8 and 9 require IETF Review.

11.2.  PRECIS Base Classes Registry

   IANA has created the "PRECIS Base Classes" registry.  In accordance
   with [RFC5226], the registration policy is "RFC Required".

   The registration template is as follows:

   Base Class:  [the name of the PRECIS string class]

   Description:  [a brief description of the PRECIS string class and its
      intended use, e.g., "A sequence of letters, numbers, and symbols
      that is used to identify or address a network entity."]

   Specification:  [the RFC number]

   The initial registrations are as follows:

   Base Class: FreeformClass.
   Description: A sequence of letters, numbers, symbols, spaces, and
         other code points that is used for free-form strings.
   Specification: Section 4.3 of RFC 7564.

   Base Class: IdentifierClass.
   Description: A sequence of letters, numbers, and symbols that is
         used to identify or address a network entity.
   Specification: Section 4.2 of RFC 7564.

Top      Up      ToC       Page 28 
11.3.  PRECIS Profiles Registry

   IANA has created the "PRECIS Profiles" registry to identify profiles
   that use the PRECIS string classes.  In accordance with [RFC5226],
   the registration policy is "Expert Review".  This policy was chosen
   in order to ease the burden of registration while ensuring that
   "customers" of PRECIS receive appropriate guidance regarding the
   sometimes complex and subtle internationalization issues related to
   profiles of PRECIS string classes.

   The registration template is as follows:

   Name:  [the name of the profile]

   Base Class:  [which PRECIS string class is being profiled]

   Applicability:  [the specific protocol elements to which this profile
      applies, e.g., "Localparts in XMPP addresses."]

   Replaces:  [the Stringprep profile that this PRECIS profile replaces,
      if any]

   Width Mapping Rule:  [the behavioral rule for handling of width,
      e.g., "Map fullwidth and halfwidth characters to their
      compatibility variants."]

   Additional Mapping Rule:  [any additional mappings that are required
      or recommended, e.g., "Map non-ASCII space characters to ASCII
      space."]

   Case Mapping Rule:  [the behavioral rule for handling of case, e.g.,
      "Unicode Default Case Folding"]

   Normalization Rule:  [which Unicode normalization form is applied,
      e.g., "NFC"]

   Directionality Rule:  [the behavioral rule for handling of right-to-
      left code points, e.g., "The 'Bidi Rule' defined in RFC 5893
      applies."]

   Enforcement:  [which entities enforce the rules, and when that
      enforcement occurs during protocol operations]

   Specification:  [a pointer to relevant documentation, such as an RFC
      or Internet-Draft]

   In order to request a review, the registrant shall send a completed
   template to the precis@ietf.org list or its designated successor.

Top      Up      ToC       Page 29 
   Factors to focus on while defining profiles and reviewing profile
   registrations include the following:

   o  Would an existing PRECIS string class or profile solve the
      problem?  If not, why not?  (See Section 5.1 for related
      considerations.)

   o  Is the problem being addressed by this profile well defined?

   o  Does the specification define what kinds of applications are
      involved and the protocol elements to which this profile applies?

   o  Is the profile clearly defined?

   o  Is the profile based on an appropriate dividing line between user
      interface (culture, context, intent, locale, device limitations,
      etc.) and the use of conformant strings in protocol elements?

   o  Are the width mapping, case mapping, additional mappings,
      normalization, and directionality rules appropriate for the
      intended use?

   o  Does the profile explain which entities enforce the rules, and
      when such enforcement occurs during protocol operations?

   o  Does the profile reduce the degree to which human users could be
      surprised or confused by application behavior (the "Principle of
      Least Astonishment")?

   o  Does the profile introduce any new security concerns such as those
      described under Section 12 of this document (e.g., false positives
      for authentication or authorization)?

12.  Security Considerations

12.1.  General Issues

   If input strings that appear "the same" to users are programmatically
   considered to be distinct in different systems, or if input strings
   that appear distinct to users are programmatically considered to be
   "the same" in different systems, then users can be confused.  Such
   confusion can have security implications, such as the false positives
   and false negatives discussed in [RFC6943].  One starting goal of
   work on the PRECIS framework was to limit the number of times that
   users are confused (consistent with the "Principle of Least
   Astonishment").  Unfortunately, this goal has been difficult to
   achieve given the large number of application protocols already in
   existence.  Despite these difficulties, profiles should not be

Top      Up      ToC       Page 30 
   multiplied beyond necessity (see Section 5.1).  In particular,
   application protocol designers should think long and hard before
   defining a new profile instead of using one that has already been
   defined, and if they decide to define a new profile then they should
   clearly explain their reasons for doing so.

   The security of applications that use this framework can depend in
   part on the proper preparation, enforcement, and comparison of
   internationalized strings.  For example, such strings can be used to
   make authentication and authorization decisions, and the security of
   an application could be compromised if an entity providing a given
   string is connected to the wrong account or online resource based on
   different interpretations of the string (again, see [RFC6943]).

   Specifications of application protocols that use this framework are
   strongly encouraged to describe how internationalized strings are
   used in the protocol, including the security implications of any
   false positives and false negatives that might result from various
   enforcement and comparison operations.  For some helpful guidelines,
   refer to [RFC6943], [RFC5890], [UTR36], and [UTS39].

12.2.  Use of the IdentifierClass

   Strings that conform to the IdentifierClass and any profile thereof
   are intended to be relatively safe for use in a broad range of
   applications, primarily because they include only letters, digits,
   and "grandfathered" non-space characters from the ASCII range; thus,
   they exclude spaces, characters with compatibility equivalents, and
   almost all symbols and punctuation marks.  However, because such
   strings can still include so-called confusable characters (see
   Section 12.5), protocol designers and implementers are encouraged to
   pay close attention to the security considerations described
   elsewhere in this document.

12.3.  Use of the FreeformClass

   Strings that conform to the FreeformClass and many profiles thereof
   can include virtually any Unicode character.  This makes the
   FreeformClass quite expressive, but also problematic from the
   perspective of possible user confusion.  Protocol designers are
   hereby warned that the FreeformClass contains code points they might
   not understand, and are encouraged to profile the IdentifierClass
   wherever feasible; however, if an application protocol requires more
   code points than are allowed by the IdentifierClass, protocol
   designers are encouraged to define a profile of the FreeformClass
   that restricts the allowable code points as tightly as possible.

Top      Up      ToC       Page 31 
   (The PRECIS Working Group considered the option of allowing
   "superclasses" as well as profiles of PRECIS string classes, but
   decided against allowing superclasses to reduce the likelihood of
   security and interoperability problems.)

12.4.  Local Character Set Issues

   When systems use local character sets other than ASCII and Unicode,
   this specification leaves the problem of converting between the local
   character set and Unicode up to the application or local system.  If
   different applications (or different versions of one application)
   implement different rules for conversions among coded character sets,
   they could interpret the same name differently and contact different
   application servers or other network entities.  This problem is not
   solved by security protocols, such as Transport Layer Security (TLS)
   [RFC5246] and the Simple Authentication and Security Layer (SASL)
   [RFC4422], that do not take local character sets into account.

12.5.  Visually Similar Characters

   Some characters are visually similar and thus can cause confusion
   among humans.  Such characters are often called "confusable
   characters" or "confusables".

   The problem of confusable characters is not necessarily caused by the
   use of Unicode code points outside the ASCII range.  For example, in
   some presentations and to some individuals the string "ju1iet"
   (spelled with DIGIT ONE, U+0031, as the third character) might appear
   to be the same as "juliet" (spelled with LATIN SMALL LETTER L,
   U+006C), especially on casual visual inspection.  This phenomenon is
   sometimes called "typejacking".

   However, the problem is made more serious by introducing the full
   range of Unicode code points into protocol strings.  For example, the
   characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 from the
   Cherokee block look similar to the ASCII characters "STPETER" as they
   might appear when presented using a "creative" font family.

   In some examples of confusable characters, it is unlikely that the
   average human could tell the difference between the real string and
   the fake string.  (Indeed, there is no programmatic way to
   distinguish with full certainty which is the fake string and which is
   the real string; in some contexts, the string formed of Cherokee
   characters might be the real string and the string formed of ASCII
   characters might be the fake string.)  Because PRECIS-compliant
   strings can contain almost any properly encoded Unicode code point,
   it can be relatively easy to fake or mimic some strings in systems
   that use the PRECIS framework.  The fact that some strings are easily

Top      Up      ToC       Page 32 
   confused introduces security vulnerabilities of the kind that have
   also plagued the World Wide Web, specifically the phenomenon known as
   phishing.

   Despite the fact that some specific suggestions about identification
   and handling of confusable characters appear in the Unicode Security
   Considerations [UTR36] and the Unicode Security Mechanisms [UTS39],
   it is also true (as noted in [RFC5890]) that "there are no
   comprehensive technical solutions to the problems of confusable
   characters."  Because it is impossible to map visually similar
   characters without a great deal of context (such as knowing the font
   families used), the PRECIS framework does nothing to map similar-
   looking characters together, nor does it prohibit some characters
   because they look like others.

   Nevertheless, specifications for application protocols that use this
   framework are strongly encouraged to describe how confusable
   characters can be abused to compromise the security of systems that
   use the protocol in question, along with any protocol-specific
   suggestions for overcoming those threats.  In particular, software
   implementations and service deployments that use PRECIS-based
   technologies are strongly encouraged to define and implement
   consistent policies regarding the registration, storage, and
   presentation of visually similar characters.  The following
   recommendations are appropriate:

   1.  An application service SHOULD define a policy that specifies the
       scripts or blocks of characters that the service will allow to be
       registered (e.g., in an account name) or stored (e.g., in a
       filename).  Such a policy SHOULD be informed by the languages and
       scripts that are used to write registered account names; in
       particular, to reduce confusion, the service SHOULD forbid
       registration or storage of strings that contain characters from
       more than one script and SHOULD restrict registrations to
       characters drawn from a very small number of scripts (e.g.,
       scripts that are well understood by the administrators of the
       service, to improve manageability).

   2.  User-oriented application software SHOULD define a policy that
       specifies how internationalized strings will be presented to a
       human user.  Because every human user of such software has a
       preferred language or a small set of preferred languages, the
       software SHOULD gather that information either explicitly from
       the user or implicitly via the operating system of the user's
       device.  Furthermore, because most languages are typically
       represented by a single script or a small set of scripts, and
       because most scripts are typically contained in one or more
       blocks of characters, the software SHOULD warn the user when

Top      Up      ToC       Page 33 
       presenting a string that mixes characters from more than one
       script or block, or that uses characters outside the normal range
       of the user's preferred language(s).  (Such a recommendation is
       not intended to discourage communication across different
       communities of language users; instead, it recognizes the
       existence of such communities and encourages due caution when
       presenting unfamiliar scripts or characters to human users.)

   The challenges inherent in supporting the full range of Unicode code
   points have in the past led some to hope for a way to
   programmatically negotiate more restrictive ranges based on locale,
   script, or other relevant factors; to tag the locale associated with
   a particular string; etc.  As a general-purpose internationalization
   technology, the PRECIS framework does not include such mechanisms.

12.6.  Security of Passwords

   Two goals of passwords are to maximize the amount of entropy and to
   minimize the potential for false positives.  These goals can be
   achieved in part by allowing a wide range of code points and by
   ensuring that passwords are handled in such a way that code points
   are not compared aggressively.  Therefore, it is NOT RECOMMENDED for
   application protocols to profile the FreeformClass for use in
   passwords in a way that removes entire categories (e.g., by
   disallowing symbols or punctuation).  Furthermore, it is NOT
   RECOMMENDED for application protocols to map uppercase and titlecase
   code points to their lowercase equivalents in such strings; instead,
   it is RECOMMENDED to preserve the case of all code points contained
   in such strings and to compare them in a case-sensitive manner.

   That said, software implementers need to be aware that there exist
   tradeoffs between entropy and usability.  For example, allowing a
   user to establish a password containing "uncommon" code points might
   make it difficult for the user to access a service when using an
   unfamiliar or constrained input device.

   Some application protocols use passwords directly, whereas others
   reuse technologies that themselves process passwords (one example of
   such a technology is the Simple Authentication and Security Layer
   [RFC4422]).  Moreover, passwords are often carried by a sequence of
   protocols with backend authentication systems or data storage systems
   such as RADIUS [RFC2865] and the Lightweight Directory Access
   Protocol (LDAP) [RFC4510].  Developers of application protocols are
   encouraged to look into reusing these profiles instead of defining
   new ones, so that end-user expectations about passwords are
   consistent no matter which application protocol is used.

Top      Up      ToC       Page 34 
   In protocols that provide passwords as input to a cryptographic
   algorithm such as a hash function, the client will need to perform
   proper preparation of the password before applying the algorithm,
   since the password is not available to the server in plaintext form.

   Further discussion of password handling can be found in
   [PRECIS-Users-Pwds].

13.  Interoperability Considerations

13.1.  Encoding

   Although strings that are consumed in PRECIS-based application
   protocols are often encoded using UTF-8 [RFC3629], the exact encoding
   is a matter for the application protocol that uses PRECIS, not for
   the PRECIS framework.

13.2.  Character Sets

   It is known that some existing systems are unable to support the full
   Unicode character set, or even any characters outside the ASCII
   range.  If two (or more) applications need to interoperate when
   exchanging data (e.g., for the purpose of authenticating a username
   or password), they will naturally need to have in common at least one
   coded character set (as defined by [RFC6365]).  Establishing such a
   baseline is a matter for the application protocol that uses PRECIS,
   not for the PRECIS framework.

13.3.  Unicode Versions

   Changes to the properties of Unicode code points can occur as the
   Unicode Standard is modified from time to time.  For example, three
   code points underwent changes in their GeneralCategory between
   Unicode 5.2 (current at the time IDNA2008 was originally published)
   and Unicode 6.0, as described in [RFC6452].  Implementers might need
   to be aware that the treatment of these characters differs depending
   on which version of Unicode is available on the system that is using
   IDNA2008 or PRECIS.  Other such differences might arise between the
   version of Unicode current at the time of this writing (7.0) and
   future versions.

13.4.  Potential Changes to Handling of Certain Unicode Code Points

   As part of the review of Unicode 7.0 for IDNA, a question was raised
   about a newly added code point that led to a re-analysis of the
   normalization rules used by IDNA and inherited by this document
   (Section 5.2.4).  Some of the general issues are described in
   [IAB-Statement] and pursued in more detail in [IDNA-Unicode].

Top      Up      ToC       Page 35 
   At the time of writing, these issues have yet to be settled.
   However, implementers need to be aware that this specification is
   likely to be updated in the future to address these issues.  The
   potential changes include the following:

   o  The range of characters in the LetterDigits category
      (Sections 4.2.1 and 9.1) might be narrowed.

   o  Some characters with special properties that are now allowed might
      be excluded.

   o  More "Additional Mapping Rules" (Section 5.2.2) might be defined.

   o  Alternative normalization methods might be added.

   Nevertheless, implementations and deployments that are sensitive to
   the advice given in this specification are unlikely to encounter
   significant problems as a consequence of these issues or potential
   changes -- specifically, the advice to use the more restrictive
   IdentifierClass whenever possible or, if using the FreeformClass, to
   allow only a restricted set of characters, particularly avoiding
   characters whose implications they do not actually understand.

14.  References

14.1.  Normative References

   [RFC20]    Cerf, V., "ASCII format for network interchange", STD 80,
              RFC 20, DOI 10.17487/RFC0020, October 1969,
              <http://www.rfc-editor.org/info/rfc20>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network
              Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
              <http://www.rfc-editor.org/info/rfc5198>.

   [RFC6365]  Hoffman, P. and J. Klensin, "Terminology Used in
              Internationalization in the IETF", BCP 166, RFC 6365,
              DOI 10.17487/RFC6365, September 2011,
              <http://www.rfc-editor.org/info/rfc6365>.

Top      Up      ToC       Page 36 
   [Unicode]  The Unicode Consortium, "The Unicode Standard",
              <http://www.unicode.org/versions/latest/>.

   [Unicode7.0]
              The Unicode Consortium, "The Unicode Standard, Version
              7.0.0", (Mountain View, CA: The Unicode Consortium, 2014
              ISBN 978-1-936213-09-2),
              <http://www.unicode.org/versions/Unicode7.0.0/>.

14.2.  Informative References

   [DerivedCoreProperties]
              The Unicode Consortium, "DerivedCoreProperties-7.0.0.txt",
              Unicode Character Database, February 2014,
              <http://www.unicode.org/Public/UCD/latest/ucd/
              DerivedCoreProperties.txt>.

   [IAB-Statement]
              Internet Architecture Board, "IAB Statement on Identifiers
              and Unicode 7.0.0", February 2015, <https://www.iab.org/
              documents/correspondence-reports-documents/
              2015-2/iab-statement-on-identifiers-and-unicode-7-0-0/>.

   [IDNA-Unicode]
              Klensin, J. and P. Faltstrom, "IDNA Update for Unicode
              7.0.0", Work in Progress,
              draft-klensin-idna-5892upd-unicode70-04, March 2015.

   [PRECIS-Mappings]
              Yoneya, Y. and T. Nemoto, "Mapping characters for PRECIS
              classes", Work in Progress, draft-ietf-precis-mappings-10,
              May 2015.

   [PRECIS-Nickname]
              Saint-Andre, P., "Preparation, Enforcement, and Comparison
              of Internationalized Strings Representing Nicknames", Work
              in Progress, draft-ietf-precis-nickname-17, April 2015.

   [PRECIS-Users-Pwds]
              Saint-Andre, P. and A. Melnikov, "Preparation,
              Enforcement, and Comparison of Internationalized Strings
              Representing Usernames and Passwords", Work in Progress,
              draft-ietf-precis-saslprepbis-17, May 2015.

Top      Up      ToC       Page 37 
   [PropertyAliases]
              The Unicode Consortium, "PropertyAliases-7.0.0.txt",
              Unicode Character Database, November 2013,
              <http://www.unicode.org/Public/UCD/latest/ucd/
              PropertyAliases.txt>.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, DOI 10.17487/RFC2865, June 2000,
              <http://www.rfc-editor.org/info/rfc2865>.

   [RFC3454]  Hoffman, P. and M. Blanchet, "Preparation of
              Internationalized Strings ("stringprep")", RFC 3454,
              DOI 10.17487/RFC3454, December 2002,
              <http://www.rfc-editor.org/info/rfc3454>.

   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, DOI 10.17487/RFC3490, March 2003,
              <http://www.rfc-editor.org/info/rfc3490>.

   [RFC3491]  Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
              Profile for Internationalized Domain Names (IDN)",
              RFC 3491, DOI 10.17487/RFC3491, March 2003,
              <http://www.rfc-editor.org/info/rfc3491>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <http://www.rfc-editor.org/info/rfc3629>.

   [RFC4422]  Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422,
              DOI 10.17487/RFC4422, June 2006,
              <http://www.rfc-editor.org/info/rfc4422>.

   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): Technical Specification Road Map", RFC 4510,
              DOI 10.17487/RFC4510, June 2006,
              <http://www.rfc-editor.org/info/rfc4510>.

   [RFC4690]  Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
              Recommendations for Internationalized Domain Names
              (IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006,
              <http://www.rfc-editor.org/info/rfc4690>.

Top      Up      ToC       Page 38 
   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
              Syntax Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <http://www.rfc-editor.org/info/rfc5234>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <http://www.rfc-editor.org/info/rfc5890>.

   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891,
              DOI 10.17487/RFC5891, August 2010,
              <http://www.rfc-editor.org/info/rfc5891>.

   [RFC5892]  Faltstrom, P., Ed., "The Unicode Code Points and
              Internationalized Domain Names for Applications (IDNA)",
              RFC 5892, DOI 10.17487/RFC5892, August 2010,
              <http://www.rfc-editor.org/info/rfc5892>.

   [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,
              <http://www.rfc-editor.org/info/rfc5893>.

   [RFC5894]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Background, Explanation, and
              Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010,
              <http://www.rfc-editor.org/info/rfc5894>.

   [RFC5895]  Resnick, P. and P. Hoffman, "Mapping Characters for
              Internationalized Domain Names in Applications (IDNA)
              2008", RFC 5895, DOI 10.17487/RFC5895, September 2010,
              <http://www.rfc-editor.org/info/rfc5895>.

Top      Up      ToC       Page 39 
   [RFC6452]  Faltstrom, P., Ed., and P. Hoffman, Ed., "The Unicode Code
              Points and Internationalized Domain Names for Applications
              (IDNA) - Unicode 6.0", RFC 6452, DOI 10.17487/RFC6452,
              November 2011, <http://www.rfc-editor.org/info/rfc6452>.

   [RFC6885]  Blanchet, M. and A. Sullivan, "Stringprep Revision and
              Problem Statement for the Preparation and Comparison of
              Internationalized Strings (PRECIS)", RFC 6885,
              DOI 10.17487/RFC6885, March 2013,
              <http://www.rfc-editor.org/info/rfc6885>.

   [RFC6943]  Thaler, D., Ed., "Issues in Identifier Comparison for
              Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May
              2013, <http://www.rfc-editor.org/info/rfc6943>.

   [UAX11]    Unicode Standard Annex #11, "East Asian Width", edited by
              Ken Lunde. An integral part of The Unicode Standard,
              <http://unicode.org/reports/tr11/>.

   [UAX15]    Unicode Standard Annex #15, "Unicode Normalization Forms",
              edited by Mark Davis and Ken Whistler. An integral part of
              The Unicode Standard, <http://unicode.org/reports/tr15/>.

   [UAX9]     Unicode Standard Annex #9, "Unicode Bidirectional
              Algorithm", edited by Mark Davis, Aharon Lanin, and Andrew
              Glass. An integral part of The Unicode Standard,
              <http://unicode.org/reports/tr9/>.

   [UTR36]    Unicode Technical Report #36, "Unicode Security
              Considerations", by Mark Davis and Michel Suignard,
              <http://unicode.org/reports/tr36/>.

   [UTS39]    Unicode Technical Standard #39, "Unicode Security
              Mechanisms", edited by Mark Davis and Michel Suignard,
              <http://unicode.org/reports/tr39/>.

   [XMPP-Addr-Format]
              Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Address Format", Work in Progress,
              draft-ietf-xmpp-6122bis-22, May 2015.

Top      Up      ToC       Page 40 
Acknowledgements

   The authors would like to acknowledge the comments and contributions
   of the following individuals during working group discussion: David
   Black, Edward Burns, Dan Chiba, Mark Davis, Alan DeKok, Martin
   Duerst, Patrik Faltstrom, Ted Hardie, Joe Hildebrand, Bjoern
   Hoehrmann, Paul Hoffman, Jeffrey Hutzelman, Simon Josefsson, John
   Klensin, Alexey Melnikov, Takahiro Nemoto, Yoav Nir, Mike Parker,
   Pete Resnick, Andrew Sullivan, Dave Thaler, Yoshiro Yoneya, and
   Florian Zeitz.

   Special thanks are due to John Klensin and Patrik Faltstrom for their
   challenging feedback and detailed reviews.

   Charlie Kaufman, Tom Taylor, and Tim Wicinski reviewed the document
   on behalf of the Security Directorate, the General Area Review Team,
   and the Operations and Management Directorate, respectively.

   During IESG review, Alissa Cooper, Stephen Farrell, and Barry Leiba
   provided comments that led to further improvements.

   Some algorithms and textual descriptions have been borrowed from
   [RFC5892].  Some text regarding security has been borrowed from
   [RFC5890], [PRECIS-Users-Pwds], and [XMPP-Addr-Format].

   Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
   employing him during his work on earlier draft versions of this
   document.

Authors' Addresses

   Peter Saint-Andre
   &yet

   EMail: peter@andyet.com
   URI:   https://andyet.com/


   Marc Blanchet
   Viagenie
   246 Aberdeen
   Quebec, QC  G1R 2E1
   Canada

   EMail: Marc.Blanchet@viagenie.ca
   URI:   http://www.viagenie.ca/