PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols
obsoletes
- rfc-7564 — PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols
Extracted elements (28)
PRECIS replaces Stringprep (RFC 3454) because Stringprep was tied to Unicode 3.2, making it inflexible as Unicode evolved. IDNA2008 abandoned Stringprep/Nameprep, prompting other Stringprep users to seek a more agile approach that derives code point properties algorithmically rather than enumerating a static table.
PRECIS separates 'preparation' (limited preprocessing for constrained devices), 'enforcement' (full rule application by authoritative servers), and 'comparison' (octet-for-octet matching of output strings). Servers are responsible for enforcement because clients may lack capacity and cannot be trusted for security-sensitive contexts such as authentication.
PRECIS uses an 'inclusion model' where a string class consists only of explicitly allowed code points, so any code point not explicitly allowed is forbidden. This prioritizes safety and predictability over expressiveness and avoids the ambiguity of exclusion-based models.
Profile proliferation is explicitly discouraged because too many profiles cause inconsistent behavior across applications, violating the 'Principle of Least Astonishment'. The document recommends using existing profiles and only defining new ones with strong justification, to enable shared code and consistent user expectations.
Spaces are excluded from the IdentifierClass because many Unicode code points are confusable with SPACE (U+0020), space code points are often invisible in user interfaces, and some devices generate non-SPACE code points (e.g., ZERO WIDTH JOINER U+200D) when users press the space bar. The PRECIS WG considered discouraging spaces in identifiers a feature, not a limitation.
The HasCompat (Q) category is disallowed in the IdentifierClass but valid in the FreeformClass. This ensures that IdentifierClass strings are stable under NFKC normalization—code points with compatibility equivalents could map to different strings under normalization, creating ambiguity in identifiers used for authentication or authorization.
The PRECIS framework does not define new directionality rules because no widely accepted solution exists for the safe display of arbitrary bidirectional strings. Profile authors are strongly encouraged to use the 'Bidi Rule' (RFC 5893) for IdentifierClass profiles or the Unicode bidirectional algorithm (UAX9) for FreeformClass profiles rather than inventing new rules.
PRECIS derived property values can differ across Unicode versions because code point properties can change. The registry maintains separate tables per Unicode version starting from 6.3, and the BackwardCompatible (G) list can be adjusted to preserve stability. Applications must specify which Unicode version they use to ensure consistent behavior.
Systems not supporting the full Unicode coded character set will face interoperability issues when exchanging PRECIS-compliant strings. Establishing a common coded character set baseline is the responsibility of the application using PRECIS, not the framework itself. Local character set conversion rules, if inconsistently implemented, can cause the same name to be interpreted differently by different systems.
A profile of a PRECIS string class MUST define the width mapping, additional mapping (if any), case mapping, normalization, and directionality rules. A profile MAY restrict allowable code points further but MUST NOT add as valid any code points that are disallowed by the underlying PRECIS string class.
A string MUST NOT contain any characters whose validity is context-dependent (CONTEXTJ or CONTEXTO) unless validity is positively confirmed by a contextual rule. If the code point is missing a rule, or if the rule result is negative or inconclusive, the string is invalid.
Because applying PRECIS profile rules is not necessarily idempotent, an implementation SHOULD apply the rules repeatedly until the output string is stable. If the output does not stabilize after three additional applications beyond the first, the implementation SHOULD terminate and reject the input string as invalid.
If case mapping is desired, it is RECOMMENDED to use the Unicode toLowerCase() operation rather than toCaseFold(). The toCaseFold() operation is appropriate for search comparisons but is not well understood by most developers and users, making toLowerCase() the safer general choice.
In accordance with RFC 5198, Normalization Form C (NFC) is RECOMMENDED for the normalization rule of a PRECIS profile. Extreme care should be taken when specifying NFKC or NFKD, as these normalization forms can cause significant information loss depending on the language and script involved.
It is NOT RECOMMENDED for application protocols to profile the FreeformClass for passwords in a way that removes entire code point categories (e.g., disallowing symbols or punctuation), as this reduces entropy. It is NOT RECOMMENDED to map case in password strings; case preservation and case-sensitive comparison are RECOMMENDED instead.
The rules for a string class or profile MUST be applied in this order: (1) Width Mapping, (2) Additional Mapping, (3) Case Mapping, (4) Normalization, (5) Directionality, (6) Behavioral rules for code point validity. Implementations MUST NOT modify the order of operations within the derived property calculation algorithm.
Width mapping is RECOMMENDED when a profile uses NFC normalization, because leaving fullwidth and halfwidth code points unmapped to their compatibility variants would violate the 'Principle of Least Astonishment'. Profiles using NFKD or NFKC subsume width mapping within compatibility decomposition and need not specify it separately.
FreeformClass is a PRECIS string class for free-form strings such as passwords and display nicknames. In addition to LetterDigits and ASCII7, it allows Spaces, Symbols, Punctuation, HasCompat, and OtherLetterDigits code points. It still disallows OldHangulJamo, Controls, and PrecisIgnorableProperties. Expressiveness is prioritized over safety.
IdentifierClass is a PRECIS string class for protocol strings such as usernames, filenames, and chat room names. It allows LetterDigits (category A) and printable ASCII7 (U+0021–U+007E, category K), and disallows spaces, symbols, punctuation, HasCompat code points, OtherLetterDigits, OldHangulJamo, Controls, and PrecisIgnorableProperties. Safety is prioritized over expressiveness.
PRECIS defines 18 code point categories (A–R). Categories A–J are inherited from IDNA2008 (RFC 5892): LetterDigits, Unstable, IgnorableProperties, IgnorableBlocks, LDH, Exceptions, BackwardCompatible, JoinControl, OldHangulJamo, Unassigned. Categories K–R are PRECIS-specific: ASCII7, Controls, PrecisIgnorableProperties, Spaces, Symbols, Punctuation, HasCompat, OtherLetterDigits.
The PRECIS derived property assigns each Unicode code point a value: PVALID (allowed in any class), FREE_PVAL (allowed only in FreeformClass), CONTEXTJ/CONTEXTO (allowed only when a contextual rule is satisfied), DISALLOWED (not permitted in any class), or UNASSIGNED (not yet designated in Unicode). ID_PVAL and FREE_DIS are defined but not used in practice.
IANA maintains the 'PRECIS Base Classes' registry with registration policy 'RFC Required'. Initial registrations are FreeformClass (Section 4.3) and IdentifierClass (Section 4.2). Each entry includes the class name, description, and specification reference.
IANA maintains the 'PRECIS Derived Property Value' registry recording derived properties for each Unicode version starting from 6.3. Values are calculated per Sections 8 and 9 with a designated expert. Changes to calculation rules require IETF Review; backward-incompatible changes must be reported to the IESG.
IANA maintains the 'PRECIS Profiles' registry with registration policy 'Expert Review'. Each profile registration must specify: name, base class, applicability, replaced Stringprep profile (if any), width/additional/case mapping rules, normalization rule, directionality rule, enforcement details, and specification reference.
Inconsistent string interpretation across systems can cause false accepts or false rejects in authentication and authorization, potentially connecting an entity to the wrong account. Protocol specifications using PRECIS are strongly encouraged to describe the security implications of their enforcement and comparison operations, referencing RFC 6943.
The FreeformClass allows virtually any Unicode code point, making it expressive but hazardous. Protocol designers are warned it contains code points they may not understand; they should prefer profiling the IdentifierClass, or if they must use FreeformClass restrict it as tightly as possible. Defining superclasses of PRECIS string classes is explicitly prohibited.
Visually similar ('confusable') Unicode characters pose significant security risks enabling phishing and spoofing. Since there are no comprehensive technical solutions, application services SHOULD restrict allowed scripts/blocks for registration and SHOULD forbid strings mixing code points from more than one script. The PRECIS framework itself does not map or prohibit confusable characters.
The derived property calculation algorithm is a priority-ordered decision tree: Exceptions → BackwardCompatible → Unassigned (UNASSIGNED) → ASCII7 (PVALID) → JoinControl (CONTEXTJ) → OldHangulJamo (DISALLOWED) → PrecisIgnorableProperties (DISALLOWED) → Controls (DISALLOWED) → HasCompat (FREE_PVAL) → LetterDigits (PVALID) → OtherLetterDigits (FREE_PVAL) → Spaces (FREE_PVAL) → Symbols (FREE_PVAL) → Punctuation (FREE_PVAL) → else DISALLOWED. Order MUST NOT be modified.