PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols
obsoleted by
- rfc-8264 — PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols
obsoletes
- rfc-3454 — Preparation of Internationalized Strings ("stringprep")
Extracted elements (30)
PRECIS uses an 'inclusion model' in which a string class consists only of code points that are explicitly allowed; any code point not explicitly allowed is forbidden. This contrasts with an exclusion model and provides a more predictable security posture.
Spaces are excluded from the IdentifierClass because many Unicode characters are visually confusable with ASCII space, space characters are often not rendered in UIs, and some devices emit non-ASCII space equivalents (e.g., U+200D) on a spacebar press. The working group considered this a feature rather than a limitation.
Stringprep (RFC 3454) was tied to Unicode version 3.2, making it impossible to be agile with respect to new Unicode versions. PRECIS replaces Stringprep by defining string classes in terms of Unicode code point properties and a derivation algorithm, allowing it to apply to any future Unicode version without republication.
The community concluded that most use cases are addressed by exactly two string classes—IdentifierClass (safety over expressiveness) and FreeformClass (expressiveness over safety)—rather than one per application protocol, in order to enable code sharing and consistent user expectations.
Changes to Unicode code point properties between versions can alter derived property values, potentially causing different behavior across implementations running different Unicode versions. Implementers should be aware that treatment of certain characters may differ between Unicode 5.2, 7.0, and future versions.
The PRECIS framework does not mandate a specific wire encoding; UTF-8 is commonly used but the exact encoding is the application protocol's responsibility. Systems unable to support the full Unicode character set must establish a common baseline coded character set at the application layer.
A character with the derived property value CONTEXTJ or CONTEXTO MUST NOT be used unless an appropriate contextual rule has been established and the context of the character is consistent with that rule.
A profile MUST NOT add as valid any code points that are disallowed by the relevant PRECIS string class; it may only further restrict the allowed set.
An application service SHOULD define a policy restricting which scripts or character blocks may be registered or stored, and SHOULD forbid strings that mix characters from more than one script, to reduce confusable-character attacks.
If case mapping is desired, it is RECOMMENDED to use Unicode Default Case Folding. It is NOT RECOMMENDED to map uppercase/titlecase to lowercase for strings used as passwords; instead, case-sensitive comparison with preserved case is RECOMMENDED.
Implementations MUST NOT modify the order of operations within the derived property calculation algorithm, since doing so would cause inconsistent results across implementations.
It is NOT RECOMMENDED for application protocols to profile the FreeformClass for passwords in a way that removes entire categories (e.g., symbols or punctuation), since this reduces entropy. Case-sensitive comparison is RECOMMENDED for password strings.
Profile authors who consider defining a new directionality rule are strongly discouraged from doing so; they SHOULD instead use the Bidi Rule (RFC 5893) for IdentifierClass-based profiles or follow the Unicode bidirectional algorithm (UAX9) for FreeformClass-based profiles.
Rules for a PRECIS string class or profile MUST be applied in the following fixed order: (1) Width Mapping, (2) Additional Mapping, (3) Case Mapping, (4) Normalization, (5) Directionality, (6) Behavioral rules (valid/contextual/disallowed/unassigned).
Unicode normalization form C (NFC) is RECOMMENDED for the normalization rule of a profile, in accordance with RFC 5198.
Width mapping is RECOMMENDED when NFC normalization is used (as opposed to NFKD/NFKC), because allowing fullwidth and halfwidth characters to remain unmapped to their compatibility variants would violate the Principle of Least Astonishment.
A PRECIS profile MUST specify: width mapping rule, additional mapping rule, case mapping rule, normalization rule, and directionality rule. It MAY further restrict allowable characters but MUST NOT add code points disallowed by the base string class.
FreeformClass allows LetterDigits (A), OtherLetterDigits (R), ASCII7 (K), HasCompat (Q), Spaces (N), Symbols (O), and Punctuation (P) as valid; Exceptions and JoinControl are allowed under contextual rules; OldHangulJamo, Controls, and PrecisIgnorableProperties are disallowed. Unassigned code points are disallowed.
IdentifierClass allows LetterDigits (A), printable ASCII7 U+0021–U+007E (K), and Exceptions/JoinControl under contextual rules; it disallows OldHangulJamo, Controls, PrecisIgnorableProperties, Spaces, Symbols, Punctuation, HasCompat, and OtherLetterDigits. Unassigned code points are treated as disallowed.
PRECIS defines three actions: Preparation (ensuring characters are allowed by the string class), Enforcement (applying all rules of a profile to determine if a string can be used in a protocol slot), and Comparison (applying rules to two strings to determine equivalence). Servers are responsible for enforcement; clients for preparation.
The ASCII7 (K) category grandfathers all printable non-space 7-bit ASCII code points (U+0021–U+007E) as PVALID, exempting them from other rules on the assumption that disallowing them would be counter-productive given their ubiquity.
The derived property calculation algorithm checks code points in a strict priority order: Exceptions → BackwardCompatible → Unassigned → ASCII7 → JoinControl → OldHangulJamo → PrecisIgnorableProperties → Controls → HasCompat → LetterDigits → OtherLetterDigits → Spaces → Symbols → Punctuation → DISALLOWED.
The PRECIS derived property values are: PVALID (valid in any string class), FREE_PVAL / ID_PVAL (class-specific valid), CONTEXTJ / CONTEXTO (contextual rule required), DISALLOWED (not permitted in any class), and UNASSIGNED (not yet designated in Unicode). These values drive the per-class behavioral rules.
IANA created the 'PRECIS Base Classes' registry with registration policy 'RFC Required'. Initial entries are IdentifierClass (Section 4.2) and FreeformClass (Section 4.3) of RFC 7564.
IANA created the 'PRECIS Profiles' registry with registration policy 'Expert Review'. Each entry must specify: Name, Base Class, Applicability, Replaces (old Stringprep profile), Width Mapping Rule, Additional Mapping Rule, Case Mapping Rule, Normalization Rule, Directionality Rule, Enforcement, and Specification.
IANA maintains the 'PRECIS Derived Property Value' registry, recording derived property values for Unicode versions 7.0 and later. Changes to the rules in Sections 8 and 9 require IETF Review; backward-incompatible table changes must be reported to the IESG.
False positives and false negatives in string comparison can compromise authentication and authorization. If strings that appear identical to users are programmatically distinct across systems, or vice versa, security vulnerabilities arise. Profile proliferation exacerbates this risk.
The FreeformClass allows virtually any Unicode character, making it highly expressive but hazardous. Protocol designers are warned about code points they may not understand and are encouraged to profile the IdentifierClass wherever feasible, or to restrict FreeformClass profiles as tightly as possible.
Visually similar (confusable) characters can be used to impersonate identifiers—e.g., Cherokee block characters resembling ASCII 'STPETER'. PRECIS does not prohibit confusables because there is no comprehensive technical solution; application protocols are strongly encouraged to define script-restriction policies and warn users about mixed-script strings.
When passwords are input to a cryptographic algorithm (e.g., a hash), the client must perform proper PRECIS preparation before applying the algorithm, since the server does not receive the password in plaintext and cannot re-enforce the profile.