draft-ietf-precis-7613bis-01.txt   draft-ietf-precis-7613bis-02.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Filament Internet-Draft Filament
Obsoletes: 7613 (if approved) A. Melnikov Obsoletes: 7613 (if approved) A. Melnikov
Intended status: Standards Track Isode Ltd Intended status: Standards Track Isode Ltd
Expires: November 6, 2016 May 5, 2016 Expires: March 7, 2017 September 3, 2016
Preparation, Enforcement, and Comparison of Internationalized Strings Preparation, Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords Representing Usernames and Passwords
draft-ietf-precis-7613bis-01 draft-ietf-precis-7613bis-02
Abstract Abstract
This document describes updated methods for handling Unicode strings This document describes updated methods for handling Unicode strings
representing usernames and passwords. The previous approach was representing usernames and passwords. The previous approach was
known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454). known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454).
The methods specified in this document provide a more sustainable The methods specified in this document provide a more sustainable
approach to the handling of internationalized usernames and approach to the handling of internationalized usernames and
passwords. The preparation, enforcement, and comparison of passwords. The preparation, enforcement, and comparison of
internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 November 6, 2016. This Internet-Draft will expire on March 7, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. OpaqueString Profile . . . . . . . . . . . . . . . . . . 13 4.2. OpaqueString Profile . . . . . . . . . . . . . . . . . . 13
4.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 13 4.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 13
4.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 14 4.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 14
4.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 14 4.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 14
4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Use in Application Protocols . . . . . . . . . . . . . . . . 15 5. Use in Application Protocols . . . . . . . . . . . . . . . . 15
6. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Usernames . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Usernames . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 19 7.1. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 18
7.2. UsernameCasePreserved Profile . . . . . . . . . . . . . . 19 7.2. UsernameCasePreserved Profile . . . . . . . . . . . . . . 19
7.3. OpaqueString Profile . . . . . . . . . . . . . . . . . . 20 7.3. OpaqueString Profile . . . . . . . . . . . . . . . . . . 20
7.4. Stringprep Profile . . . . . . . . . . . . . . . . . . . 20 7.4. Stringprep Profile . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8.1. Password/Passphrase Strength . . . . . . . . . . . . . . 21 8.1. Password/Passphrase Strength . . . . . . . . . . . . . . 20
8.2. Identifier Comparison . . . . . . . . . . . . . . . . . . 21 8.2. Identifier Comparison . . . . . . . . . . . . . . . . . . 21
8.3. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 21 8.3. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 21
8.4. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 21 8.4. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Differences from RFC 7613 . . . . . . . . . . . . . 24 Appendix A. Differences from RFC 7613 . . . . . . . . . . . . . 24
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 24 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Usernames and passwords are widely used for authentication and Usernames and passwords are widely used for authentication and
authorization on the Internet, either directly when provided in authorization on the Internet, either directly when provided in
plaintext (as in the PLAIN Simple Authentication and Security Layer plaintext (as in the PLAIN Simple Authentication and Security Layer
(SASL) mechanism [RFC4616] and the HTTP Basic scheme [RFC7617]) or (SASL) mechanism [RFC4616] and the HTTP Basic scheme [RFC7617]) or
indirectly when provided as the input to a cryptographic algorithm indirectly when provided as the input to a cryptographic algorithm
such as a hash function (as in the Salted Challenge Response such as a hash function (as in the Salted Challenge Response
Authentication Mechanism (SCRAM) SASL mechanism [RFC5802] and the Authentication Mechanism (SCRAM) SASL mechanism [RFC5802] and the
skipping to change at page 6, line 23 skipping to change at page 6, line 23
The following rules apply within the UsernameCaseMapped profile of The following rules apply within the UsernameCaseMapped profile of
the PRECIS IdentifierClass. the PRECIS IdentifierClass.
1. Width-Mapping Rule: Map fullwidth and halfwidth characters to 1. Width-Mapping Rule: Map fullwidth and halfwidth characters to
their decomposition mappings (see Unicode Standard Annex #11 their decomposition mappings (see Unicode Standard Annex #11
[UAX11]). [UAX11]).
2. Additional Mapping Rule: There is no additional mapping rule. 2. Additional Mapping Rule: There is no additional mapping rule.
3. Case-Mapping Rule: Map uppercase and titlecase characters to 3. Case-Mapping Rule: Map uppercase and titlecase characters to
their lowercase equivalents, preferably using Unicode Default their lowercase equivalents, preferably using the Unicode
Case Folding as defined in the Unicode Standard [Unicode] (at the toLower() operation as defined in the Unicode Standard [Unicode];
time of this writing, the algorithm is specified in Chapter 3 of see further discussion in Section 3.4.
[Unicode7.0], but the chapter number might change in a future
version of the Unicode Standard); see further discussion in
Section 3.4.
4. Normalization Rule: Apply Unicode Normalization Form C (NFC) to 4. Normalization Rule: Apply Unicode Normalization Form C (NFC) to
all characters. all characters.
5. Directionality Rule: Apply the "Bidi Rule" defined in [RFC5893] 5. Directionality Rule: Apply the "Bidi Rule" defined in [RFC5893]
to strings that contain right-to-left characters (i.e., each of to strings that contain right-to-left characters (i.e., each of
the six conditions of the Bidi Rule must be satisfied); for the six conditions of the Bidi Rule must be satisfied); for
strings that do not contain right-to-left characters, there is no strings that do not contain right-to-left characters, there is no
special processing for directionality. special processing for directionality.
skipping to change at page 7, line 13 skipping to change at page 7, line 11
[RFC7564]. [RFC7564].
3. Encode the string as UTF-8 [RFC3629]. 3. Encode the string as UTF-8 [RFC3629].
3.2.3. Enforcement 3.2.3. Enforcement
An entity that performs enforcement according to this profile MUST An entity that performs enforcement according to this profile MUST
prepare a string as described in Section 3.2.2 and MUST also apply prepare a string as described in Section 3.2.2 and MUST also apply
the following rules specified in Section 3.2.1 in the order shown: the following rules specified in Section 3.2.1 in the order shown:
1. Normalization Rule 1. Case-Mapping Rule
2. Directionality Rule 2. Normalization Rule
3. Case-Mapping Rule 3. Directionality Rule
After all of the foregoing rules have been enforced, the entity MUST After all of the foregoing rules have been enforced, the entity MUST
ensure that the username is not zero bytes in length (this is done ensure that the username is not zero bytes in length (this is done
after enforcing the rules to prevent applications from mistakenly after enforcing the rules to prevent applications from mistakenly
omitting a username entirely, because when internationalized omitting a username entirely, because when internationalized
characters are accepted, a non-empty sequence of characters can characters are accepted, a non-empty sequence of characters can
result in a zero-length username after canonicalization). result in a zero-length username after canonicalization).
3.2.4. Comparison 3.2.4. Comparison
An entity that performs comparison of two strings according to this An entity that performs comparison of two strings according to this
profile MUST prepare each string as specified in Section 3.2.2 and profile MUST prepare each string as specified in Section 3.2.2 and
then enforce the rules specified in Section 3.2.3. The two strings then MUST enforce the rules specified in Section 3.2.3. The two
are to be considered equivalent if they are an exact octet-for-octet strings are to be considered equivalent if they are an exact octet-
match (sometimes called "bit-string identity"). for-octet match (sometimes called "bit-string identity").
3.3. UsernameCasePreserved Profile 3.3. UsernameCasePreserved Profile
3.3.1. Rules 3.3.1. Rules
The following rules apply within the UsernameCasePreserved profile of The following rules apply within the UsernameCasePreserved profile of
the PRECIS IdentifierClass. the PRECIS IdentifierClass.
1. Width-Mapping Rule: Map fullwidth and halfwidth characters to 1. Width-Mapping Rule: Map fullwidth and halfwidth characters to
their decomposition mappings (see Unicode Standard Annex #11 their decomposition mappings (see Unicode Standard Annex #11
skipping to change at page 8, line 38 skipping to change at page 8, line 34
3.3.3. Enforcement 3.3.3. Enforcement
An entity that performs enforcement according to this profile MUST An entity that performs enforcement according to this profile MUST
prepare a string as described in Section 3.3.2 and MUST also apply prepare a string as described in Section 3.3.2 and MUST also apply
the following rules specified in Section 3.3.1 in the order shown: the following rules specified in Section 3.3.1 in the order shown:
1. Normalization Rule 1. Normalization Rule
2. Directionality Rule 2. Directionality Rule
3. Case-Mapping Rule
After all of the foregoing rules have been enforced, the entity MUST After all of the foregoing rules have been enforced, the entity MUST
ensure that the username is not zero bytes in length (this is done ensure that the username is not zero bytes in length (this is done
after enforcing the rules to prevent applications from mistakenly after enforcing the rules to prevent applications from mistakenly
omitting a username entirely, because when internationalized omitting a username entirely, because when internationalized
characters are accepted, a non-empty sequence of characters can characters are accepted, a non-empty sequence of characters can
result in a zero-length username after canonicalization). result in a zero-length username after canonicalization).
3.3.4. Comparison 3.3.4. Comparison
An entity that performs comparison of two strings according to this An entity that performs comparison of two strings according to this
profile MUST prepare each string as specified in Section 3.3.2 and profile MUST prepare each string as specified in Section 3.3.2 and
then enforce the rules specified in Section 3.3.3. The two strings then MUST enforce the rules specified in Section 3.3.3. The two
are to be considered equivalent if they are an exact octet-for-octet strings are to be considered equivalent if they are an exact octet-
match (sometimes called "bit-string identity"). for-octet match (sometimes called "bit-string identity").
3.4. Case Mapping vs. Case Preservation 3.4. Case Mapping vs. Case Preservation
In order to accommodate the widest range of username constructs in In order to accommodate the widest range of username constructs in
applications, this document defines two username profiles: applications, this document defines two username profiles:
UsernameCaseMapped and UsernameCasePreserved. These two profiles UsernameCaseMapped and UsernameCasePreserved. These two profiles
differ only in the Case-Mapping Rule and are otherwise identical. differ only in the Case-Mapping Rule and are otherwise identical.
Case mapping is a matter for the application protocol, protocol Case mapping is a matter for the application protocol, protocol
implementation, or end deployment. In general, this document implementation, or end deployment. In general, this document
skipping to change at page 12, line 16 skipping to change at page 12, line 16
| # | Non-Userpart String | Notes | | # | Non-Userpart String | Notes |
+--------------------------+---------------------------------+ +--------------------------+---------------------------------+
| 8 | <foo bar> | Space (U+0020) is disallowed in | | 8 | <foo bar> | Space (U+0020) is disallowed in |
| | | the userpart | | | | the userpart |
+--------------------------+---------------------------------+ +--------------------------+---------------------------------+
| 9 | <> | Zero-length userpart | | 9 | <> | Zero-length userpart |
+--------------------------+---------------------------------+ +--------------------------+---------------------------------+
| 10| <henry&#x2163;> | The sixth character is ROMAN | | 10| <henry&#x2163;> | The sixth character is ROMAN |
| | | NUMERAL FOUR (U+2163) | | | | NUMERAL FOUR (U+2163) |
+--------------------------+---------------------------------+ +--------------------------+---------------------------------+
| 11| <&#x265A;> | A localpart of BLACK CHESS KING | | 11| <&#x265A;> | A user part of BLACK CHESS KING |
| | | (U+265A) | | | | (U+265A) |
+--------------------------+---------------------------------+ +--------------------------+---------------------------------+
Table 2: A Sample of Strings That Violate the Userpart Rule Table 2: A Sample of Strings That Violate the Userpart Rule
Here again, several points are worth noting. Regarding example 8: Here again, several points are worth noting. Regarding example 8:
although this is not a valid userpart, it is a valid username because although this is not a valid userpart, it is a valid username because
it is a space-separated sequence of userparts. Regarding example 10: it is a space-separated sequence of userparts. Regarding example 10:
the Unicode character ROMAN NUMERAL FOUR (U+2163) has a compatibility the Unicode character ROMAN NUMERAL FOUR (U+2163) has a compatibility
equivalent of the string formed of LATIN CAPITAL LETTER I (U+0049) equivalent of the string formed of LATIN CAPITAL LETTER I (U+0049)
skipping to change at page 14, line 21 skipping to change at page 14, line 21
1. Width-Mapping Rule: Fullwidth and halfwidth characters MUST NOT 1. Width-Mapping Rule: Fullwidth and halfwidth characters MUST NOT
be mapped to their decomposition mappings (see Unicode Standard be mapped to their decomposition mappings (see Unicode Standard
Annex #11 [UAX11]). Annex #11 [UAX11]).
2. Additional Mapping Rule: Any instances of non-ASCII space MUST be 2. Additional Mapping Rule: Any instances of non-ASCII space MUST be
mapped to ASCII space (U+0020); a non-ASCII space is any Unicode mapped to ASCII space (U+0020); a non-ASCII space is any Unicode
code point having a Unicode general category of "Zs" (with the code point having a Unicode general category of "Zs" (with the
exception of U+0020). exception of U+0020).
3. Case-Mapping Rule: Uppercase and titlecase characters MUST NOT be 3. Case-Mapping Rule: There is no case mapping rule (because mapping
mapped to their lowercase equivalents. uppercase and titlecase characters to their lowercase equivalents
would lead to false positives and thus to reduced security).
4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be 4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be
applied to all characters. applied to all characters.
5. Directionality Rule: There is no directionality rule. The "Bidi 5. Directionality Rule: There is no directionality rule. The "Bidi
Rule" (defined in [RFC5893]) and similar rules are unnecessary Rule" (defined in [RFC5893]) and similar rules are unnecessary
and inapplicable to passwords, because they can reduce the range and inapplicable to passwords, because they can reduce the range
of characters that are allowed in a string and therefore reduce of characters that are allowed in a string and therefore reduce
the amount of entropy that is possible in a password. Such rules the amount of entropy that is possible in a password. Such rules
are intended to minimize the possibility that the same string are intended to minimize the possibility that the same string
skipping to change at page 14, line 47 skipping to change at page 14, line 48
systems in the way that non-secret strings like domain names and systems in the way that non-secret strings like domain names and
usernames are. Furthermore, it is perfectly acceptable for usernames are. Furthermore, it is perfectly acceptable for
opaque strings other than passwords to be presented differently opaque strings other than passwords to be presented differently
in different layout systems, as long as the presentation is in different layout systems, as long as the presentation is
consistent in any given layout system. consistent in any given layout system.
4.2.3. Comparison 4.2.3. Comparison
An entity that performs comparison of two strings according to this An entity that performs comparison of two strings according to this
profile MUST prepare each string as specified in Section 4.2.1 and profile MUST prepare each string as specified in Section 4.2.1 and
then enforce the rules specified in Section 4.2.2. The two strings then MUST enforce the rules specified in Section 4.2.2. The two
are to be considered equivalent if they are an exact octet-for-octet strings are to be considered equivalent if they are an exact octet-
match (sometimes called "bit-string identity"). for-octet match (sometimes called "bit-string identity").
4.3. Examples 4.3. Examples
The following examples illustrate a small number of passwords that The following examples illustrate a small number of passwords that
are consistent with the format defined above (note that the are consistent with the format defined above (note that the
characters "<" and ">" are used here to delineate the actual characters "<" and ">" are used here to delineate the actual
passwords and are not part of the password strings). passwords and are not part of the password strings).
+------------------------------------+------------------------------+ +------------------------------------+------------------------------+
| # | Password | Notes | | # | Password | Notes |
skipping to change at page 17, line 32 skipping to change at page 17, line 32
U+0056); in these cases, the operator will need to determine how U+0056); in these cases, the operator will need to determine how
to proceed -- for instance, by disabling the account whose name to proceed -- for instance, by disabling the account whose name
contains a Unicode code point with a compatibility equivalent. contains a Unicode code point with a compatibility equivalent.
Such cases are probably rare, but it is important for operators to Such cases are probably rare, but it is important for operators to
be aware of them. be aware of them.
o SASLprep mapped the "characters commonly mapped to nothing" from o SASLprep mapped the "characters commonly mapped to nothing" from
Appendix B.1 of [RFC3454]) to nothing, whereas the PRECIS Appendix B.1 of [RFC3454]) to nothing, whereas the PRECIS
IdentifierClass entirely disallows most of these characters, which IdentifierClass entirely disallows most of these characters, which
correspond to the code points from the PRECIS "M" category defined correspond to the code points from the PRECIS "M" category defined
under Section 9.13 of [RFC7564] (with the exception of MONGOLIAN under Section 9.13 of [RFC7564]. For migration purposes, the
TODO SOFT HYPHEN (U+1806), which was "commonly mapped to nothing" operator might want to remove from usernames any code points
in Unicode 3.2 but at the time of this writing does not have a contained in the PRECIS "M" category (e.g., SOFT HYPHEN (U+00AD)).
derived property of Default_Ignorable_Code_Point in Unicode 7.0). Because these code points would have been "mapped to nothing" in
For migration purposes, the operator might want to remove from stringprep, in practice a user would not notice the difference if,
usernames any code points contained in the PRECIS "M" category upon migration to PRECIS, the code points are removed.
(e.g., SOFT HYPHEN (U+00AD)). Because these code points would
have been "mapped to nothing" in stringprep, in practice a user
would not notice the difference if, upon migration to PRECIS, the
code points are removed.
o SASLprep allowed uppercase and titlecase characters, whereas the o SASLprep allowed uppercase and titlecase characters, whereas the
UsernameCaseMapped profile maps uppercase and titlecase characters UsernameCaseMapped profile maps uppercase and titlecase characters
to their lowercase equivalents (by contrast, the to their lowercase equivalents (by contrast, the
UsernameCasePreserved profile matches SASLprep in this regard). UsernameCasePreserved profile matches SASLprep in this regard).
For migration purposes, the operator can use either the For migration purposes, the operator can use either the
UsernameCaseMapped profile (thus losing the case information) or UsernameCaseMapped profile (thus losing the case information) or
the UsernameCasePreserved profile (thus ignoring case difference the UsernameCasePreserved profile (thus ignoring case difference
when comparing usernames). when comparing usernames).
skipping to change at page 18, line 44 skipping to change at page 18, line 38
fullwidth and halfwidth code points to their decomposition fullwidth and halfwidth code points to their decomposition
mappings. Although it is expected that code points with mappings. Although it is expected that code points with
compatibility equivalents are rare in existing passwords, some compatibility equivalents are rare in existing passwords, some
passwords that matched when SASLprep was used might no longer work passwords that matched when SASLprep was used might no longer work
when the rules in this specification are applied. when the rules in this specification are applied.
o SASLprep mapped the "characters commonly mapped to nothing" from o SASLprep mapped the "characters commonly mapped to nothing" from
Appendix B.1 of [RFC3454]) to nothing, whereas the PRECIS Appendix B.1 of [RFC3454]) to nothing, whereas the PRECIS
FreeformClass entirely disallows such characters, which correspond FreeformClass entirely disallows such characters, which correspond
to the code points from the PRECIS "M" category defined under to the code points from the PRECIS "M" category defined under
Section 9.13 of [RFC7564] (with the exception of MONGOLIAN TODO Section 9.13 of [RFC7564]. In practice, this change will probably
SOFT HYPHEN (U+1806), which was commonly mapped to nothing in have no effect on comparison, but user-oriented software might
Unicode 3.2 but at the time of this writing is allowed by Unicode reject such code points instead of ignoring them during password
7.0). In practice, this change will probably have no effect on preparation.
comparison, but user-oriented software might reject such code
points instead of ignoring them during password preparation.
7. IANA Considerations 7. IANA Considerations
IANA has made the updates described below. IANA has made the updates described below.
7.1. UsernameCaseMapped Profile 7.1. UsernameCaseMapped Profile
IANA has added the following entry to the "PRECIS Profiles" registry. IANA has added the following entry to the "PRECIS Profiles" registry.
Name: UsernameCaseMapped. Name: UsernameCaseMapped.
skipping to change at page 22, line 24 skipping to change at page 22, line 15
[RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation, Enforcement, and Comparison of Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols", RFC Internationalized Strings in Application Protocols", RFC
7564, DOI 10.17487/RFC7564, May 2015, 7564, DOI 10.17487/RFC7564, May 2015,
<http://www.rfc-editor.org/info/rfc7564>. <http://www.rfc-editor.org/info/rfc7564>.
[UAX11] Unicode Standard Annex #11, "East Asian Width", edited by [UAX11] Unicode Standard Annex #11, "East Asian Width", edited by
Ken Lunde. An integral part of The Unicode Standard, Ken Lunde. An integral part of The Unicode Standard,
<http://unicode.org/reports/tr11/>. <http://unicode.org/reports/tr11/>.
[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/>.
[Unicode] The Unicode Consortium, "The Unicode Standard", [Unicode] The Unicode Consortium, "The Unicode Standard",
<http://www.unicode.org/versions/latest/>. <http://www.unicode.org/versions/latest/>.
9.2. Informative References 9.2. Informative References
[Err1812] RFC Errata, "Erratum ID 1812", RFC 4013, [Err1812] RFC Errata, "Erratum ID 1812", RFC 4013,
<http://www.rfc-editor.org>. <http://www.rfc-editor.org>.
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, [RFC20] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969, RFC 20, DOI 10.17487/RFC0020, October 1969,
skipping to change at page 24, line 22 skipping to change at page 24, line 9
<http://www.rfc-editor.org/info/rfc7622>. <http://www.rfc-editor.org/info/rfc7622>.
[UTS39] Unicode Technical Standard #39, "Unicode Security [UTS39] Unicode Technical Standard #39, "Unicode Security
Mechanisms", edited by Mark Davis and Michel Suignard, Mechanisms", edited by Mark Davis and Michel Suignard,
<http://unicode.org/reports/tr39/>. <http://unicode.org/reports/tr39/>.
Appendix A. Differences from RFC 7613 Appendix A. Differences from RFC 7613
The following modifications were made from [RFC7613]. The following modifications were made from [RFC7613].
o Corrected the order of operations for the UsernameCaseMapped
profile to ensure consistency with RFC 7564.
o In accordance with working group discussions and updates to
[RFC7564], removed the use of the Unicode CaseFold() operation in
favor of the Unicode toLower() operation.
o Modified the presentation (but not the content) of the rules. o Modified the presentation (but not the content) of the rules.
o Clarified several editorial matters. o Clarified several editorial matters.
See [RFC7613] for a description of the differences from [RFC4013]. See [RFC7613] for a description of the differences from [RFC4013].
Appendix B. Acknowledgements Appendix B. Acknowledgements
This document borrows some text from [RFC4013] and [RFC6120]. Thanks to Christian Schudt and Sam Whited for their bug reports and
feedback.
The following individuals provided helpful feedback on this document:
Marc Blanchet, Ben Campbell, Alan DeKok, Joe Hildebrand, Jeffrey
Hutzelman, Simon Josefsson, Jonathan Lennox, James Manger, Matt
Miller, Chris Newman, Yutaka OIWA, Pete Resnick, Andrew Sullivan,
Nico Williams, and Yoshiro YONEYA. Nico Williams in particular
deserves special recognition for providing text that was used in
Section 3.4. Thanks also to Takahiro NEMOTO and Yoshiro YONEYA for
implementation feedback.
Robert Sparks and Derek Atkins reviewed the document on behalf of the
General Area Review Team and the Security Directorate, respectively.
Benoit Claise and Stephen Farrell provided helpful input during IESG
review.
Thanks to Matt Miller as document shepherd, Marc Blanchet and Yoshiro
YONEYA as working group chairs, and Pete Resnick and Barry Leiba as
area directors.
Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for See [RFC7613] for acknowledgements related to the specification that
employing him during his work on earlier draft versions of this this document supersedes.
document.
Authors' Addresses Authors' Addresses
Peter Saint-Andre Peter Saint-Andre
Filament Filament
Email: peter@filament.com Email: peter@filament.com
URI: https://filament.com/ URI: https://filament.com/
Alexey Melnikov Alexey Melnikov
 End of changes. 22 change blocks. 
77 lines changed or deleted 49 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/