< draft-ietf-precis-7564bis-08.txt   draft-ietf-precis-7564bis-09.txt >
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Filament Internet-Draft Filament
Obsoletes: 7564 (if approved) M. Blanchet Obsoletes: 7564 (if approved) M. Blanchet
Intended status: Standards Track Viagenie Intended status: Standards Track Viagenie
Expires: December 29, 2017 June 27, 2017 Expires: January 17, 2018 July 16, 2017
PRECIS Framework: Preparation, Enforcement, and Comparison of PRECIS Framework: Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols Internationalized Strings in Application Protocols
draft-ietf-precis-7564bis-08 draft-ietf-precis-7564bis-09
Abstract Abstract
Application protocols using Unicode code points in protocol strings Application protocols using Unicode code points in protocol strings
need to properly handle such strings in order to enforce need to properly handle such strings in order to enforce
internationalization rules for strings placed in various protocol internationalization rules for strings placed in various protocol
slots (such as addresses and identifiers) and to perform valid slots (such as addresses and identifiers) and to perform valid
comparison operations (e.g., for purposes of authentication or comparison operations (e.g., for purposes of authentication or
authorization). This document defines a framework enabling authorization). This document defines a framework enabling
application protocols to perform the preparation, enforcement, and application protocols to perform the preparation, enforcement, and
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 29, 2017. This Internet-Draft will expire on January 17, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 39
4.2.2. Contextual Rule Required . . . . . . . . . . . . . . 10 4.2.2. Contextual Rule Required . . . . . . . . . . . . . . 10
4.2.3. Disallowed . . . . . . . . . . . . . . . . . . . . . 10 4.2.3. Disallowed . . . . . . . . . . . . . . . . . . . . . 10
4.2.4. Unassigned . . . . . . . . . . . . . . . . . . . . . 11 4.2.4. Unassigned . . . . . . . . . . . . . . . . . . . . . 11
4.2.5. Examples . . . . . . . . . . . . . . . . . . . . . . 11 4.2.5. Examples . . . . . . . . . . . . . . . . . . . . . . 11
4.3. FreeformClass . . . . . . . . . . . . . . . . . . . . . . 11 4.3. FreeformClass . . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. Valid . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.1. Valid . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.2. Contextual Rule Required . . . . . . . . . . . . . . 12 4.3.2. Contextual Rule Required . . . . . . . . . . . . . . 12
4.3.3. Disallowed . . . . . . . . . . . . . . . . . . . . . 12 4.3.3. Disallowed . . . . . . . . . . . . . . . . . . . . . 12
4.3.4. Unassigned . . . . . . . . . . . . . . . . . . . . . 12 4.3.4. Unassigned . . . . . . . . . . . . . . . . . . . . . 12
4.3.5. Examples . . . . . . . . . . . . . . . . . . . . . . 12 4.3.5. Examples . . . . . . . . . . . . . . . . . . . . . . 12
5. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Profiles Must Not Be Multiplied beyond Necessity . . . . 13 5. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Profiles Must Not Be Multiplied beyond Necessity . . . . 15
5.2.1. Width Mapping Rule . . . . . . . . . . . . . . . . . 14 5.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.2. Additional Mapping Rule . . . . . . . . . . . . . . . 14 5.2.1. Width Mapping Rule . . . . . . . . . . . . . . . . . 16
5.2.3. Case Mapping Rule . . . . . . . . . . . . . . . . . . 15 5.2.2. Additional Mapping Rule . . . . . . . . . . . . . . . 16
5.2.4. Normalization Rule . . . . . . . . . . . . . . . . . 15 5.2.3. Case Mapping Rule . . . . . . . . . . . . . . . . . . 17
5.2.5. Directionality Rule . . . . . . . . . . . . . . . . . 16 5.2.4. Normalization Rule . . . . . . . . . . . . . . . . . 17
5.3. A Note about Spaces . . . . . . . . . . . . . . . . . . . 17 5.2.5. Directionality Rule . . . . . . . . . . . . . . . . . 18
6. Applications . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3. A Note about Spaces . . . . . . . . . . . . . . . . . . . 19
6.1. How to Use PRECIS in Applications . . . . . . . . . . . . 17 6. Applications . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Further Excluded Characters . . . . . . . . . . . . . . . 19 6.1. How to Use PRECIS in Applications . . . . . . . . . . . . 19
6.3. Building Application-Layer Constructs . . . . . . . . . . 19 6.2. Further Excluded Characters . . . . . . . . . . . . . . . 21
7. Order of Operations . . . . . . . . . . . . . . . . . . . . . 20 6.3. Building Application-Layer Constructs . . . . . . . . . . 21
8. Code Point Properties . . . . . . . . . . . . . . . . . . . . 20
9. Category Definitions Used to Calculate Derived Property . . . 23 7. Order of Operations . . . . . . . . . . . . . . . . . . . . . 22
9.1. LetterDigits (A) . . . . . . . . . . . . . . . . . . . . 24 8. Code Point Properties . . . . . . . . . . . . . . . . . . . . 22
9.2. Unstable (B) . . . . . . . . . . . . . . . . . . . . . . 24 9. Category Definitions Used to Calculate Derived Property . . . 25
9.3. IgnorableProperties (C) . . . . . . . . . . . . . . . . . 24 9.1. LetterDigits (A) . . . . . . . . . . . . . . . . . . . . 26
9.4. IgnorableBlocks (D) . . . . . . . . . . . . . . . . . . . 24 9.2. Unstable (B) . . . . . . . . . . . . . . . . . . . . . . 26
9.5. LDH (E) . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.3. IgnorableProperties (C) . . . . . . . . . . . . . . . . . 26
9.6. Exceptions (F) . . . . . . . . . . . . . . . . . . . . . 24 9.4. IgnorableBlocks (D) . . . . . . . . . . . . . . . . . . . 26
9.7. BackwardCompatible (G) . . . . . . . . . . . . . . . . . 24 9.5. LDH (E) . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.8. JoinControl (H) . . . . . . . . . . . . . . . . . . . . . 25 9.6. Exceptions (F) . . . . . . . . . . . . . . . . . . . . . 26
9.9. OldHangulJamo (I) . . . . . . . . . . . . . . . . . . . . 25 9.7. BackwardCompatible (G) . . . . . . . . . . . . . . . . . 26
9.10. Unassigned (J) . . . . . . . . . . . . . . . . . . . . . 25 9.8. JoinControl (H) . . . . . . . . . . . . . . . . . . . . . 27
9.11. ASCII7 (K) . . . . . . . . . . . . . . . . . . . . . . . 25 9.9. OldHangulJamo (I) . . . . . . . . . . . . . . . . . . . . 27
9.12. Controls (L) . . . . . . . . . . . . . . . . . . . . . . 25 9.10. Unassigned (J) . . . . . . . . . . . . . . . . . . . . . 27
9.13. PrecisIgnorableProperties (M) . . . . . . . . . . . . . . 26 9.11. ASCII7 (K) . . . . . . . . . . . . . . . . . . . . . . . 27
9.14. Spaces (N) . . . . . . . . . . . . . . . . . . . . . . . 26 9.12. Controls (L) . . . . . . . . . . . . . . . . . . . . . . 27
9.15. Symbols (O) . . . . . . . . . . . . . . . . . . . . . . . 26 9.13. PrecisIgnorableProperties (M) . . . . . . . . . . . . . . 28
9.16. Punctuation (P) . . . . . . . . . . . . . . . . . . . . . 26 9.14. Spaces (N) . . . . . . . . . . . . . . . . . . . . . . . 28
9.17. HasCompat (Q) . . . . . . . . . . . . . . . . . . . . . . 26 9.15. Symbols (O) . . . . . . . . . . . . . . . . . . . . . . . 28
9.18. OtherLetterDigits (R) . . . . . . . . . . . . . . . . . . 27 9.16. Punctuation (P) . . . . . . . . . . . . . . . . . . . . . 28
10. Guidelines for Designated Experts . . . . . . . . . . . . . . 27 9.17. HasCompat (Q) . . . . . . . . . . . . . . . . . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9.18. OtherLetterDigits (R) . . . . . . . . . . . . . . . . . . 29
11.1. PRECIS Derived Property Value Registry . . . . . . . . . 28 10. Guidelines for Designated Experts . . . . . . . . . . . . . . 29
11.2. PRECIS Base Classes Registry . . . . . . . . . . . . . . 28 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
11.3. PRECIS Profiles Registry . . . . . . . . . . . . . . . . 29 11.1. PRECIS Derived Property Value Registry . . . . . . . . . 30
12. Security Considerations . . . . . . . . . . . . . . . . . . . 31 11.2. PRECIS Base Classes Registry . . . . . . . . . . . . . . 30
12.1. General Issues . . . . . . . . . . . . . . . . . . . . . 31 11.3. PRECIS Profiles Registry . . . . . . . . . . . . . . . . 31
12.2. Use of the IdentifierClass . . . . . . . . . . . . . . . 31 12. Security Considerations . . . . . . . . . . . . . . . . . . . 33
12.3. Use of the FreeformClass . . . . . . . . . . . . . . . . 32 12.1. General Issues . . . . . . . . . . . . . . . . . . . . . 33
12.4. Local Character Set Issues . . . . . . . . . . . . . . . 32 12.2. Use of the IdentifierClass . . . . . . . . . . . . . . . 33
12.5. Visually Similar Characters . . . . . . . . . . . . . . 32 12.3. Use of the FreeformClass . . . . . . . . . . . . . . . . 34
12.6. Security of Passwords . . . . . . . . . . . . . . . . . 34 12.4. Local Character Set Issues . . . . . . . . . . . . . . . 34
13. Interoperability Considerations . . . . . . . . . . . . . . . 35 12.5. Visually Similar Characters . . . . . . . . . . . . . . 34
13.1. Coded Character Sets . . . . . . . . . . . . . . . . . . 35 12.6. Security of Passwords . . . . . . . . . . . . . . . . . 36
13.2. Dependency on Unicode . . . . . . . . . . . . . . . . . 36 13. Interoperability Considerations . . . . . . . . . . . . . . . 37
13.3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 36 13.1. Coded Character Sets . . . . . . . . . . . . . . . . . . 37
13.4. Unicode Versions . . . . . . . . . . . . . . . . . . . . 36 13.2. Dependency on Unicode . . . . . . . . . . . . . . . . . 37
13.3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 38
13.4. Unicode Versions . . . . . . . . . . . . . . . . . . . . 38
13.5. Potential Changes to Handling of Certain Unicode Code 13.5. Potential Changes to Handling of Certain Unicode Code
Points . . . . . . . . . . . . . . . . . . . . . . . . . 36 Points . . . . . . . . . . . . . . . . . . . . . . . . . 38
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
14.1. Normative References . . . . . . . . . . . . . . . . . . 37 14.1. Normative References . . . . . . . . . . . . . . . . . . 39
14.2. Informative References . . . . . . . . . . . . . . . . . 38 14.2. Informative References . . . . . . . . . . . . . . . . . 40
Appendix A. Changes from RFC 7564 . . . . . . . . . . . . . . . 42 Appendix A. Changes from RFC 7564 . . . . . . . . . . . . . . . 44
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 42 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
Application protocols using Unicode code points [Unicode] in protocol Application protocols using Unicode code points [Unicode] in protocol
strings need to properly handle such strings in order to enforce strings need to properly handle such strings in order to enforce
internationalization rules for strings placed in various protocol internationalization rules for strings placed in various protocol
slots (such as addresses and identifiers) and to perform valid slots (such as addresses and identifiers) and to perform valid
comparison operations (e.g., for purposes of authentication or comparison operations (e.g., for purposes of authentication or
authorization). This document defines a framework enabling authorization). This document defines a framework enabling
application protocols to perform the preparation, enforcement, and application protocols to perform the preparation, enforcement, and
skipping to change at page 7, line 16 skipping to change at page 7, line 16
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. Preparation, Enforcement, and Comparison 3. Preparation, Enforcement, and Comparison
This document distinguishes between three different actions that an This document distinguishes between three different actions that an
entity can take with regard to a string: entity can take with regard to a string:
o Enforcement entails applying all of the rules specified for a o Enforcement entails applying all of the rules specified for a
particular string class or profile thereof to an individual particular string class or profile thereof to a single input
string, for the purpose of checking whether the string conforms to string, for the purpose of checking whether the string conforms to
all of the rules and thus determining if the string can be used in all of the rules and thus determining if the string can be used in
a given protocol slot. a given protocol slot.
o Comparison entails applying all of the rules specified for a o Comparison entails applying all of the rules specified for a
particular string class or profile thereof to two separate particular string class or profile thereof to two separate input
strings, for the purpose of determining if the two strings are strings, for the purpose of determining if the two strings are
equivalent. equivalent.
o Preparation primarily entails ensuring that the code points in an o Preparation primarily entails ensuring that the code points in a
individual string are allowed by the underlying PRECIS string single input string are allowed by the underlying PRECIS string
class, and sometimes also entails applying one or more of the class, and sometimes also entails applying one or more of the
rules specified for a particular string class or profile thereof. rules specified for a particular string class or profile thereof.
Preparation can be appropriate for constrained devices that can to Preparation can be appropriate for constrained devices that can to
some extent restrict the code points in a string to a limited some extent restrict the code points in a string to a limited
repertoire of characters but that do not have the processing power repertoire of characters but that do not have the processing power
or onboard memory to perform operations such as Unicode or onboard memory to perform operations such as Unicode
normalization. However, preparation does not ensure that an input normalization. However, preparation does not ensure that an input
string conforms to all of the rules for a string class or profile string conforms to all of the rules for a string class or profile
thereof. thereof.
skipping to change at page 13, line 7 skipping to change at page 13, line 7
4.3.5. Examples 4.3.5. Examples
As described in the Introduction to this document, the string classes As described in the Introduction to this document, the string classes
do not handle all issues related to string preparation and comparison do not handle all issues related to string preparation and comparison
(such as case mapping); instead, such issues are handled at the level (such as case mapping); instead, such issues are handled at the level
of profiles. Examples for profiles of the FreeformClass can be found of profiles. Examples for profiles of the FreeformClass can be found
in [I-D.ietf-precis-7613bis] (the OpaqueString profile) and in [I-D.ietf-precis-7613bis] (the OpaqueString profile) and
[I-D.ietf-precis-7700bis] (the Nickname profile). [I-D.ietf-precis-7700bis] (the Nickname profile).
4.4. Summary
The following table summarizes the differences between the
IdentifierClass and the FreeformClass, i.e., the disposition of a
code point as valid, contextual rule required, disallowed, or
unassigned) depending on its PRECIS category.
+===============================+=================+===============+
| CATEGORY | IDENTIFIERCLASS | FREEFORMCLASS |
+===============================+=================+===============+
| (A) LetterDigits | Valid | Valid |
+-------------------------------+-----------------+---------------+
| (B) Unstable | [N/A (unused)] |
+-------------------------------+-----------------+---------------+
| (C) IgnorableProperties | [N/A (unused)] |
+-------------------------------+-----------------+---------------+
| (D) IgnorableBlocks | [N/A (unused)] |
+-------------------------------+-----------------+---------------+
| (E) LDH | [N/A (unused)] |
+-------------------------------+-----------------+---------------+
| (F) Exceptions | Contextual | Contextual |
| | Rule Required | Rule Required |
+-------------------------------+-----------------+---------------+
| (G) BackwardCompatible | [Handled by IDNA Rules] |
+-------------------------------+-----------------+---------------+
| (H) JoinControl | Contextual | Contextual |
| | Rule Required | Required |
+-------------------------------+-----------------+---------------+
| (I) OldHangulJamo | Disallowed | Disallowed |
+-------------------------------+-----------------+---------------+
| (J) Unassigned | Unassigned | Unassigned |
+-------------------------------+-----------------+---------------+
| (K) ASCII7 | Valid | Valid |
+-------------------------------+-----------------+---------------+
| (L) Controls | Disallowed | Disallowed |
+-------------------------------+-----------------+---------------+
| (M) PrecisIgnorableProperties | Disallowed | Disallowed |
+-------------------------------+-----------------+---------------+
| (N) Spaces | Disallowed | Valid |
+-------------------------------+-----------------+---------------+
| (O) Symbols | Disallowed | Valid |
+-------------------------------+-----------------+---------------+
| (P) Punctuation | Disallowed | Valid |
+-------------------------------+-----------------+---------------+
| (Q) HasCompat | Disallowed | Valid |
+-------------------------------+-----------------+---------------+
| (R) OtherLetterDigits | Disallowed | Valid |
+-------------------------------+-----------------+---------------+
Table 1: Comparative Disposition of Code Points
5. Profiles 5. Profiles
This framework document defines the valid, contextual-rule-required, This framework document defines the valid, contextual-rule-required,
disallowed, and unassigned rules for the IdentifierClass and the disallowed, and unassigned rules for the IdentifierClass and the
FreeformClass. A profile of a PRECIS string class MUST define the FreeformClass. A profile of a PRECIS string class MUST define the
width mapping, additional mappings (if any), case mapping, width mapping, additional mappings (if any), case mapping,
normalization, and directionality rules. A profile MAY also restrict normalization, and directionality rules. A profile MAY also restrict
the allowable code points above and beyond the definition of the the allowable code points above and beyond the definition of the
relevant PRECIS string class (but MUST NOT add as valid any code relevant PRECIS string class (but MUST NOT add as valid any code
points that are disallowed by the relevant PRECIS string class). points that are disallowed by the relevant PRECIS string class).
skipping to change at page 15, line 32 skipping to change at page 17, line 32
users understand its implications, so toLowerCase() is almost always users understand its implications, so toLowerCase() is almost always
the safer choice. the safer choice.
Note: Neither toLowerCase() nor toCaseFold() is designed to handle Note: Neither toLowerCase() nor toCaseFold() is designed to handle
various language-specific issues (such as so-called "dotless i" in various language-specific issues (such as so-called "dotless i" in
several Turkic languages). The reader is referred to the PRECIS several Turkic languages). The reader is referred to the PRECIS
mappings document [RFC7790], which describes these issues in mappings document [RFC7790], which describes these issues in
greater detail. greater detail.
In order to maximize entropy and minimize the potential for false In order to maximize entropy and minimize the potential for false
positives, it is NOT RECOMMENDED for application protocols to map accepts, it is NOT RECOMMENDED for application protocols to map
uppercase and titlecase code points to their lowercase equivalents uppercase and titlecase code points to their lowercase equivalents
when strings conforming to the FreeformClass, or a profile thereof, when strings conforming to the FreeformClass, or a profile thereof,
are used in passwords; instead, it is RECOMMENDED to preserve the are used in passwords; instead, it is RECOMMENDED to preserve the
case of all code points contained in such strings and then perform case of all code points contained in such strings and then perform
case-sensitive comparison. See also the related discussion in case-sensitive comparison. See also the related discussion in
Section 12.6 and in [I-D.ietf-precis-7613bis]. Section 12.6 and in [I-D.ietf-precis-7613bis].
5.2.4. Normalization Rule 5.2.4. Normalization Rule
The normalization rule of a profile specifies which Unicode The normalization rule of a profile specifies which Unicode
skipping to change at page 20, line 41 skipping to change at page 22, line 41
addition, this order is consistent with IDNA2008, and with both addition, this order is consistent with IDNA2008, and with both
IDNA2003 and Stringprep before then, for the purpose of enabling code IDNA2003 and Stringprep before then, for the purpose of enabling code
reuse and of ensuring as much continuity as possible with the reuse and of ensuring as much continuity as possible with the
Stringprep profiles that are obsoleted by several PRECIS profiles. Stringprep profiles that are obsoleted by several PRECIS profiles.
Because of the order of operations specified here, applying the rules Because of the order of operations specified here, applying the rules
for any given PRECIS profile is not necessarily an idempotent for any given PRECIS profile is not necessarily an idempotent
procedure (e.g., under certain circumstances, such as when Unicode procedure (e.g., under certain circumstances, such as when Unicode
normalization form KC is used, performing Unicode normalization after normalization form KC is used, performing Unicode normalization after
case mapping can still yield uppercase characters for certain code case mapping can still yield uppercase characters for certain code
points); therefore, implementations might need to apply the rules points). Therefore, an implementation SHOULD apply the rules
more than once to an internationalized string. repeatedly until the output string is stable; if the output string
does not stabilize within a reasonable number of iterations, the
implementation SHOULD terminate application of the rules and reject
the input string as invalid.
8. Code Point Properties 8. Code Point Properties
In order to implement the string classes described above, this In order to implement the string classes described above, this
document does the following: document does the following:
1. Reviews and classifies the collections of code points in the 1. Reviews and classifies the collections of code points in the
Unicode coded character set by examining various code point Unicode coded character set by examining various code point
properties. properties.
skipping to change at page 28, line 36 skipping to change at page 30, line 36
derived property value is to be calculated in cooperation with a derived property value is to be calculated in cooperation with a
designated expert [RFC5226] according to the rules specified under designated expert [RFC5226] according to the rules specified under
Sections 8 and 9. Sections 8 and 9.
The IESG is to be notified if backward-incompatible changes to the The IESG is to be notified if backward-incompatible changes to the
table of derived properties are discovered or if other problems arise table of derived properties are discovered or if other problems arise
during the process of creating the table of derived property values during the process of creating the table of derived property values
or during expert review. Changes to the rules defined under or during expert review. Changes to the rules defined under
Sections 8 and 9 require IETF Review. Sections 8 and 9 require IETF Review.
Note: IANA is requested to not make further updates to this registry
until it receives notice from the IESG that the issues described in
[IAB-Statement] and Section 13.5 of this document have been settled.
11.2. PRECIS Base Classes Registry 11.2. PRECIS Base Classes Registry
IANA has created the "PRECIS Base Classes" registry. In accordance IANA has created the "PRECIS Base Classes" registry. In accordance
with [RFC5226], the registration policy is "RFC Required". with [RFC5226], the registration policy is "RFC Required".
The registration template is as follows: The registration template is as follows:
Base Class: [the name of the PRECIS string class] Base Class: [the name of the PRECIS string class]
Description: [a brief description of the PRECIS string class and its Description: [a brief description of the PRECIS string class and its
skipping to change at page 30, line 48 skipping to change at page 32, line 51
intended use? intended use?
o Does the profile explain which entities enforce the rules, and o Does the profile explain which entities enforce the rules, and
when such enforcement occurs during protocol operations? when such enforcement occurs during protocol operations?
o Does the profile reduce the degree to which human users could be o Does the profile reduce the degree to which human users could be
surprised or confused by application behavior (the "Principle of surprised or confused by application behavior (the "Principle of
Least Astonishment")? Least Astonishment")?
o Does the profile introduce any new security concerns such as those o Does the profile introduce any new security concerns such as those
described under Section 12 of this document (e.g., false positives described under Section 12 of this document (e.g., false accepts
for authentication or authorization)? for authentication or authorization)?
12. Security Considerations 12. Security Considerations
12.1. General Issues 12.1. General Issues
If input strings that appear "the same" to users are programmatically If input strings that appear "the same" to users are programmatically
considered to be distinct in different systems, or if input strings considered to be distinct in different systems, or if input strings
that appear distinct to users are programmatically considered to be that appear distinct to users are programmatically considered to be
"the same" in different systems, then users can be confused. Such "the same" in different systems, then users can be confused. Such
confusion can have security implications, such as the false positives confusion can have security implications, such as the false accepts
and false negatives discussed in [RFC6943]. One starting goal of and false rejects discussed in [RFC6943] (the terms "false positives"
work on the PRECIS framework was to limit the number of times that 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 users are confused (consistent with the "Principle of Least
Astonishment"). Unfortunately, this goal has been difficult to Astonishment"). Unfortunately, this goal has been difficult to
achieve given the large number of application protocols already in achieve given the large number of application protocols already in
existence. Despite these difficulties, profiles should not be existence. Despite these difficulties, profiles should not be
multiplied beyond necessity (see Section 5.1). In particular, multiplied beyond necessity (see Section 5.1). In particular,
application protocol designers should think long and hard before application protocol designers should think long and hard before
defining a new profile instead of using one that has already been 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 defined, and if they decide to define a new profile then they should
clearly explain their reasons for doing so. clearly explain their reasons for doing so.
skipping to change at page 31, line 37 skipping to change at page 33, line 38
part on the proper preparation, enforcement, and comparison of part on the proper preparation, enforcement, and comparison of
internationalized strings. For example, such strings can be used to internationalized strings. For example, such strings can be used to
make authentication and authorization decisions, and the security of make authentication and authorization decisions, and the security of
an application could be compromised if an entity providing a given an application could be compromised if an entity providing a given
string is connected to the wrong account or online resource based on string is connected to the wrong account or online resource based on
different interpretations of the string (again, see [RFC6943]). different interpretations of the string (again, see [RFC6943]).
Specifications of application protocols that use this framework are Specifications of application protocols that use this framework are
strongly encouraged to describe how internationalized strings are strongly encouraged to describe how internationalized strings are
used in the protocol, including the security implications of any used in the protocol, including the security implications of any
false positives and false negatives that might result from various false accepts and false rejects that might result from various
enforcement and comparison operations. For some helpful guidelines, enforcement and comparison operations. For some helpful guidelines,
refer to [RFC6943], [RFC5890], [UTR36], and [UTS39]. refer to [RFC6943], [RFC5890], [UTR36], and [UTS39].
12.2. Use of the IdentifierClass 12.2. Use of the IdentifierClass
Strings that conform to the IdentifierClass and any profile thereof Strings that conform to the IdentifierClass and any profile thereof
are intended to be relatively safe for use in a broad range of are intended to be relatively safe for use in a broad range of
applications, primarily because they include only letters, digits, applications, primarily because they include only letters, digits,
and "grandfathered" non-space code points from the ASCII range; thus, and "grandfathered" non-space code points from the ASCII range; thus,
they exclude spaces, code points with compatibility equivalents, and they exclude spaces, code points with compatibility equivalents, and
skipping to change at page 34, line 23 skipping to change at page 36, line 27
points drawn from a very small number of scripts (e.g., scripts points drawn from a very small number of scripts (e.g., scripts
that are well understood by the administrators of the service, to that are well understood by the administrators of the service, to
improve manageability). improve manageability).
2. User-oriented application software SHOULD define a policy that 2. User-oriented application software SHOULD define a policy that
specifies how internationalized strings will be presented to a specifies how internationalized strings will be presented to a
human user. Because every human user of such software has a human user. Because every human user of such software has a
preferred language or a small set of preferred languages, the preferred language or a small set of preferred languages, the
software SHOULD gather that information either explicitly from software SHOULD gather that information either explicitly from
the user or implicitly via the operating system of the user's the user or implicitly via the operating system of the user's
device. Furthermore, because most languages are typically device.
represented by a single script or a small set of scripts, and
because most scripts are typically contained in one or more
blocks of code points, the software SHOULD warn the user when
presenting a string that mixes code points from more than one
script or block, or that uses code points 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 code points to human users.)
The challenges inherent in supporting the full range of Unicode code The challenges inherent in supporting the full range of Unicode code
points have in the past led some to hope for a way to points have in the past led some to hope for a way to
programmatically negotiate more restrictive ranges based on locale, programmatically negotiate more restrictive ranges based on locale,
script, or other relevant factors; to tag the locale associated with script, or other relevant factors; to tag the locale associated with
a particular string; etc. As a general-purpose internationalization a particular string; etc. As a general-purpose internationalization
technology, the PRECIS framework does not include such mechanisms. technology, the PRECIS framework does not include such mechanisms.
12.6. Security of Passwords 12.6. Security of Passwords
Two goals of passwords are to maximize the amount of entropy and to Two goals of passwords are to maximize the amount of entropy and to
minimize the potential for false positives. These goals can be minimize the potential for false accepts. These goals can be
achieved in part by allowing a wide range of code points and by 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 ensuring that passwords are handled in such a way that code points
are not compared aggressively. Therefore, it is NOT RECOMMENDED for are not compared aggressively. Therefore, it is NOT RECOMMENDED for
application protocols to profile the FreeformClass for use in application protocols to profile the FreeformClass for use in
passwords in a way that removes entire categories (e.g., by passwords in a way that removes entire categories (e.g., by
disallowing symbols or punctuation). Furthermore, it is NOT disallowing symbols or punctuation). Furthermore, it is NOT
RECOMMENDED for application protocols to map uppercase and titlecase RECOMMENDED for application protocols to map uppercase and titlecase
code points to their lowercase equivalents in such strings; instead, code points to their lowercase equivalents in such strings; instead,
it is RECOMMENDED to preserve the case of all code points contained it is RECOMMENDED to preserve the case of all code points contained
in such strings and to compare them in a case-sensitive manner. in such strings and to compare them in a case-sensitive manner.
skipping to change at page 37, line 8 skipping to change at page 38, line 49
As part of the review of Unicode 7.0 for IDNA, a question was raised 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 about a newly added code point that led to a re-analysis of the
normalization rules used by IDNA and inherited by this document normalization rules used by IDNA and inherited by this document
(Section 5.2.4). Some of the general issues are described in (Section 5.2.4). Some of the general issues are described in
[IAB-Statement] and pursued in more detail in [IDNA-Unicode]. [IAB-Statement] and pursued in more detail in [IDNA-Unicode].
At the time of writing, these issues have yet to be settled. At the time of writing, these issues have yet to be settled.
However, implementers need to be aware that this specification is However, implementers need to be aware that this specification is
likely to be updated in the future to address these issues. The likely to be updated in the future to address these issues. The
potential changes include the following: potential changes include but might not be limited to the following:
o The range of code points in the LetterDigits category o The range of code points in the LetterDigits category
(Sections 4.2.1 and 9.1) might be narrowed. (Sections 4.2.1 and 9.1) might be narrowed.
o Some code points with special properties that are now allowed o Some code points with special properties that are now allowed
might be excluded. might be excluded.
o More "Additional Mapping Rules" (Section 5.2.2) might be defined. o More "Additional Mapping Rules" (Section 5.2.2) might be defined.
o Alternative normalization methods might be added. o Alternative normalization methods might be added.
Until these issues are sorted out, it is reasonable for the IANA to As described in Section 11.1, until these issues are settled, it is
apply the same precautionary principle described in [IAB-Statement] reasonable for the IANA to apply the same precautionary principle
to the PRECIS Derived Property Value Registry as is applied to the described in [IAB-Statement] to the PRECIS Derived Property Value
Internationalized Domain Names for Applications (IDNA) Parameters Registry as is applied to the Internationalized Domain Names for
registry: that is, to not make further updates to the registry. Applications (IDNA) Parameters registry: that is, to not make further
updates to the registry.
Nevertheless, implementations and deployments are unlikely to Nevertheless, implementations and deployments are unlikely to
encounter significant problems as a consequence of these issues or encounter significant problems as a consequence of these issues or
potential changes if they follow the advice given in this potential changes if they follow the advice given in this
specification to use the more restrictive IdentifierClass whenever specification to use the more restrictive IdentifierClass whenever
possible or, if using the FreeformClass, to allow only a restricted possible or, if using the FreeformClass, to allow only a restricted
set of code points, particularly avoiding code points whose set of code points, particularly avoiding code points whose
implications they do not understand. implications they do not understand.
14. References 14. References
skipping to change at page 38, line 28 skipping to change at page 40, line 20
<http://www.unicode.org/Public/UCD/latest/ucd/ <http://www.unicode.org/Public/UCD/latest/ucd/
DerivedCoreProperties.txt>. DerivedCoreProperties.txt>.
[Err4568] RFC Errata, "Erratum ID 4568", RFC 7564, [Err4568] RFC Errata, "Erratum ID 4568", RFC 7564,
<http://www.rfc-editor.org>. <http://www.rfc-editor.org>.
[I-D.ietf-precis-7613bis] [I-D.ietf-precis-7613bis]
Saint-Andre, P. and A. Melnikov, "Preparation, Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", draft-ietf-precis- Representing Usernames and Passwords", draft-ietf-precis-
7613bis-08 (work in progress), June 2017. 7613bis-09 (work in progress), July 2017.
[I-D.ietf-precis-7700bis] [I-D.ietf-precis-7700bis]
Saint-Andre, P., "Preparation, Enforcement, and Comparison Saint-Andre, P., "Preparation, Enforcement, and Comparison
of Internationalized Strings Representing Nicknames", of Internationalized Strings Representing Nicknames",
draft-ietf-precis-7700bis-08 (work in progress), June draft-ietf-precis-7700bis-09 (work in progress), July
2017. 2017.
[IAB-Statement] [IAB-Statement]
Internet Architecture Board, "IAB Statement on Identifiers Internet Architecture Board, "IAB Statement on Identifiers
and Unicode 7.0.0", February 2015, and Unicode 7.0.0", February 2015,
<https://www.iab.org/documents/correspondence-reports- <https://www.iab.org/documents/correspondence-reports-
documents/2015-2/iab-statement-on-identifiers-and-unicode- documents/2015-2/iab-statement-on-identifiers-and-unicode-
7-0-0/>. 7-0-0/>.
[IDNA-Unicode] [IDNA-Unicode]
skipping to change at page 42, line 17 skipping to change at page 44, line 17
The following changes were made from [RFC7564]. The following changes were made from [RFC7564].
o Recommended the Unicode toLowerCase() operation over the Unicode o Recommended the Unicode toLowerCase() operation over the Unicode
toCaseFold() operation in most PRECIS applications. toCaseFold() operation in most PRECIS applications.
o Clarified the meaning of "preparation" and described the o Clarified the meaning of "preparation" and described the
motivation for including it in PRECIS. motivation for including it in PRECIS.
o Updated references. o Updated references.
See [I-D.ietf-precis-7613bis] for a description of the differences See [RFC7564] for a description of the differences from [RFC3454].
from [RFC3454].
Appendix B. Acknowledgements Appendix B. Acknowledgements
Thanks to Martin Duerst, William Fisher, John Klensin, Christian Thanks to Martin Duerst, William Fisher, John Klensin, Christian
Schudt, and Sam Whited for their feedback. Thanks to Sam Whited also Schudt, and Sam Whited for their feedback. Thanks to Sam Whited also
for submitting [Err4568]. for submitting [Err4568].
See [RFC7564] for acknowledgements related to the specification that See [RFC7564] for acknowledgements related to the specification that
this document supersedes. this document supersedes.
 End of changes. 22 change blocks. 
95 lines changed or deleted 146 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/