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."]
Reference: [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 8264
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 8264
11.3. PRECIS Profiles Registry
IANA has created the "PRECIS Profiles" registry
(<https://www.iana.org/assignments/precis-parameters/>) to identify
profiles that use the PRECIS string classes. In accordance with
[RFC8126], 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., "Usernames in security and application protocols."]
Replaces: [the Stringprep profile that this PRECIS profile replaces,
Width Mapping Rule: [the behavioral rule for handling of width,
e.g., "Map fullwidth and halfwidth code points to their
Additional Mapping Rule: [any additional mappings that are required
or recommended, e.g., "Map non-ASCII space code points to SPACE
Case Mapping Rule: [the behavioral rule for handling of case, e.g.,
"Apply the Unicode toLowerCase() operation."]
Normalization Rule: [which Unicode normalization form is applied,
Directionality Rule: [the behavioral rule for handling of right-to-
left code points, e.g., "The 'Bidi Rule' defined in RFC 5893
Enforcement: [which entities enforce the rules, and when that
enforcement occurs during protocol operations]
Specification: [a pointer to relevant documentation, such as an RFC
In order to request a review, the registrant shall send a completed
template to the <firstname.lastname@example.org> list or its designated successor.
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
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 mapping,
normalization, and directionality rules appropriate for the
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
o Does the profile introduce any new security concerns such as those
described under Section 12 of this document (e.g., false accepts
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 accepts
and false rejects discussed in [RFC6943] (the terms "false positives"
and "false negatives" are used in that document). 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
multiplied beyond necessity (see Section 5.1). In particular,
designers of application protocols 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 accepts and false rejects 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 code points from the ASCII range; thus,
they exclude spaces, code points with compatibility equivalents, and
almost all symbols and punctuation marks. However, because such
strings can still include so-called "confusable code points" (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 code point. 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 they 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. (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 SASL [RFC4422], that do not take local character sets
12.5. Visually Similar Characters
Some code points 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. A well-known
example is confusion between "а" CYRILLIC SMALL LETTER A (U+0430) and
"a" LATIN SMALL LETTER A (U+0061). As another 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 code points
representing "STPETER" as they might appear when presented using a
"creative" font family. Confusion among such characters is perhaps
not unexpected, given that the alphabetic writing systems involved
all bear a family resemblance or historical lineage. Perhaps more
surprising is confusion among characters from disparate writing
systems, such as "O" (LATIN CAPITAL LETTER O, U+004F), "0" (DIGIT
ZERO, U+0030), "໐" (LAO DIGIT ZERO, U+0ED0), "ዐ" (ETHIOPIC SYLLABLE
PHARYNGEAL A, U+12D0), and other graphemes that have the appearance
of open circles. And the reader needs to be aware that the foregoing
represent merely a small sample of characters that are confusable in
In some instances 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 code
points might be the real string and the string formed of ASCII code
points 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 confused
introduces security vulnerabilities of the kind that have also
plagued the World Wide Web, specifically the phenomenon known as
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 code points 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 code points from
more than one script and SHOULD restrict registrations to code
points drawn from a very small number of scripts (e.g., scripts
that are well understood by the administrators of the service, to
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
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 accepts. 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
That said, software implementers need to be aware that there exist
trade-offs 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 SASL [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
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,
because the password is not available to the server in plaintext
Further discussion of password handling can be found in [RFC8265].
13. Interoperability Considerations
13.1. Coded Character Sets
It is known that some existing applications and systems do not
support the full Unicode coded character set, or even any characters
outside the ASCII repertoire [RFC20]. If two (or more) applications
or systems need to interoperate when exchanging data (e.g., for the
purpose of authenticating the combination of a username and
password), naturally they will need to have in common at least one
coded character set and the repertoire of characters being exchanged
(see [RFC6365] for definitions of these terms). Establishing such a
baseline is a matter for the application or system that uses PRECIS,
not for the PRECIS framework.
13.2. Dependency on Unicode
The only coded character set supported by PRECIS is Unicode. If an
application or system does not support Unicode or uses a different
coded character set [RFC6365], then the PRECIS rules cannot be
applied to that application or system.
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 or for specifications that define PRECIS string
classes or profiles thereof.
13.4. Unicode Versions
It is extremely important for protocol designers and application
developers to understand that various changes can occur across
versions of the Unicode Standard, and such changes can result in
instability of PRECIS categories. The following are merely a few
o As described in [RFC6452], between Unicode 5.2 (current at the
time IDNA2008 was originally published) and Unicode 6.0, three
code points underwent changes in their GeneralCategory, resulting
in modified handling, depending on which version of Unicode is
available on the underlying system.
o The HasCompat() categorization of a given input string could
change if, for example, the string includes a precomposed
character that was added in a recent version of Unicode.
o The East Asian width property, which is used in many PRECIS width
mapping rules, is not guaranteed to be stable across Unicode
13.5. 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].
At the time of this 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 but might not be limited to the following:
o The range of code points in the LetterDigits category
(Sections 4.2.1 and 9.1) might be narrowed.
o Some code points 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.
As described in Section 11.1, until these issues are settled, it is
reasonable for the IANA to apply the same precautionary principle
described in [IAB-Statement] to the "PRECIS Derived Property Value"
registry as is applied to the "IDNA Parameters" registry
<https://www.iana.org/assignments/idna-tables/>: that is, to not make
further updates to the registry.
Nevertheless, implementations and deployments are unlikely to
encounter significant problems as a consequence of these issues or
potential changes if they follow the advice given in this
specification to use the more restrictive IdentifierClass whenever
possible or, if using the FreeformClass, to allow only a restricted
set of code points, particularly avoiding code points whose
implications they do not understand.
14.1. Normative References
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
Appendix A. Changes from RFC 7564
The following changes were made from [RFC7564].
o Recommended the Unicode toLowerCase() operation over the Unicode
toCaseFold() operation in most PRECIS applications.
o Clarified the meaning of "preparation", and described the
motivation for including it in PRECIS.
o Updated references.
See [RFC7564] for a description of the differences from [RFC3454].
Thanks to Martin Duerst, William Fisher, John Klensin, Christian
Schudt, and Sam Whited for their feedback. Thanks to Sam Whited also
for submitting [Err4568].
See [RFC7564] for acknowledgements related to the specification that
this document supersedes.
Some algorithms and textual descriptions have been borrowed from
[RFC5892]. Some text regarding security has been borrowed from
[RFC5890], [RFC8265], and [RFC7622].
P.O. Box 787
Parker, CO 80134
United States of America
Phone: +1 720 256 6756
Québec, QC G1R 2E1