< draft-ietf-precis-saslprepbis-01.txt		draft-ietf-precis-saslprepbis-02.txt >
	PRECIS P. Saint-Andre		PRECIS P. Saint-Andre
	Internet-Draft Cisco Systems, Inc.		Internet-Draft Cisco Systems, Inc.
	Obsoletes: 4013 (if approved) A. Melnikov		Obsoletes: 4013 (if approved) A. Melnikov
	Intended status: Standards Track Isode Ltd		Intended status: Standards Track Isode Ltd
	Expires: September 28, 2013 March 27, 2013		Expires: October 27, 2013 April 25, 2013
	Preparation and Comparison of Internationalized Strings Representing		Preparation and Comparison of Internationalized Strings Representing
	Simple User Names and Passwords		Simple User Names and Passwords
	draft-ietf-precis-saslprepbis-01		draft-ietf-precis-saslprepbis-02
	Abstract		Abstract
	This document describes how to handle Unicode strings representing		This document describes how to handle Unicode strings representing
	simple user names and passwords, primarily for purposes of		simple user names and passwords, primarily for purposes of
	comparison. This profile is intended to be used by Simple		comparison. This profile is intended to be used by Simple
	Authentication and Security Layer (SASL) mechanisms (such as PLAIN		Authentication and Security Layer (SASL) mechanisms (such as PLAIN
	and SCRAM-SHA-1), as well as other protocols that exchange simple		and SCRAM-SHA-1), as well as other protocols that exchange simple
	user names or passwords. This document obsoletes RFC 4013.		user names or passwords. This document obsoletes RFC 4013.
	Status of This Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 September 28, 2013.		This Internet-Draft will expire on October 27, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2		1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Simple User Names . . . . . . . . . . . . . . . . . . . . . . 4		2. Simple User Names . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. Preparation . . . . . . . . . . . . . . . . . . . . . . . 5		2.2. Preparation . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 5		3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Preparation . . . . . . . . . . . . . . . . . . . . . . . 6		3.2. Preparation . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.1. User Names . . . . . . . . . . . . . . . . . . . . . . . 7		4.1. User Names . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 8		4.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	5.1. Password/Passphrase Strength . . . . . . . . . . . . . . 9		5.1. Password/Passphrase Strength . . . . . . . . . . . . . . . 9
	5.2. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 9		5.2. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 9
	5.3. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 9		5.3. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	6.1. Use of IdentifierClass . . . . . . . . . . . . . . . . . 9		6.1. Use of IdentifierClass . . . . . . . . . . . . . . . . . . 10
	6.2. Use of FreeformClass . . . . . . . . . . . . . . . . . . 10		6.2. Use of FreeformClass . . . . . . . . . . . . . . . . . . . 10
	7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.1. Normative References . . . . . . . . . . . . . . . . . . 10		8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	8.2. Informative References . . . . . . . . . . . . . . . . . 11		8.2. Informative References . . . . . . . . . . . . . . . . . . 11
	Appendix A. Differences from RFC 4013 . . . . . . . . . . . . . 12		Appendix A. Differences from RFC 4013 . . . . . . . . . . . . . . 12
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 12		Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	1.1. Overview		1.1. Overview
	User names and passwords are used pervasively in authentication and		User names and passwords are used pervasively in authentication and
	authorization on the Internet. To increase the likelihood that the		authorization on the Internet. To increase the likelihood that the
	input and comparison of user names and passwords will work in ways		input and comparison of user names and passwords will work in ways
	that make sense for typical users throughout the world, this document		that make sense for typical users throughout the world, this document
	defines rules for preparing and comparing internationalized strings		defines rules for preparing and comparing internationalized strings
	skipping to change at page 4, line 30 ¶		skipping to change at page 5, line 5 ¶
	[RFC3629], and structured either as an ordered sequence of		[RFC3629], and structured either as an ordered sequence of
	"simpleparts" (where the complete simple user name can consist of a		"simpleparts" (where the complete simple user name can consist of a
	single simplepart or a space-separated sequence of simpleparts) or as		single simplepart or a space-separated sequence of simpleparts) or as
	a simplepart@domainpart (where the domainpart is an IP literal, an		a simplepart@domainpart (where the domainpart is an IP literal, an
	IPv4 address, or a fully-qualified domain name).		IPv4 address, or a fully-qualified domain name).
	Therefore the syntax for a simple user name is defined as follows		Therefore the syntax for a simple user name is defined as follows
	using the Augmented Backus-Naur Form (ABNF) as specified in		using the Augmented Backus-Naur Form (ABNF) as specified in
	[RFC5234].		[RFC5234].
	simpleusername = simplepart [1*(1*SP simplepart)]		simpleusername = simplepart [1*(1*SP simplepart)]
	/ simplepart '@' domainpart		/ simplepart '@' domainpart
	simplepart = 1*(idpoint)		simplepart = 1*(idpoint)
	;		;
	; an "idpoint" is a UTF-8 encoded		; an "idpoint" is a UTF-8 encoded
	; Unicode code point that conforms to		; Unicode code point that conforms to
	; the PRECIS "IdentifierClass"		; the PRECIS "IdentifierClass"
	;		;
	domainpart = IP-literal / IPv4address / ifqdn		domainpart = IP-literal / IPv4address / ifqdn
	;		;
	; the "IPv4address" and "IP-literal"		; the "IPv4address" and "IP-literal"
	; rules are defined in RFC 3986, and		; rules are defined in RFC 3986, and
	; the first-match-wins (a.k.a. "greedy")		; the first-match-wins (a.k.a. "greedy")
	; algorithm described in RFC 3986		; algorithm described in RFC 3986
	; applies to the matching process		; applies to the matching process
	;		;
	; note well that reuse of the IP-literal		; note well that reuse of the IP-literal
	; rule from RFC 3986 implies that IPv6		; rule from RFC 3986 implies that IPv6
	; addresses are enclosed in square		; addresses are enclosed in square
	; brackets (i.e., beginning with '['		; brackets (i.e., beginning with '['
	; and ending with ']')		; and ending with ']')
	;		;
	ifqdn = 1*1023(domainpoint)		ifqdn = 1*1023(domainpoint)
	;		;
	; a "domainpoint" is a UTF-8 encoded		; a "domainpoint" is a UTF-8 encoded
	; Unicode code point that conforms to		; Unicode code point that conforms to
	; RFC 5890		; RFC 5890
	;		;
	Note well that all code points and blocks not explicitly allowed in		Note well that all code points and blocks not explicitly allowed in
	the PRECIS IdentifierClass are disallowed; this includes private use		the PRECIS IdentifierClass are disallowed; this includes private use
	characters, surrogate code points, and the other code points and		characters, surrogate code points, and the other code points and
	blocks defined as "Prohibited Output" in Section 2.3 of RFC 4013.		blocks defined as "Prohibited Output" in Section 2.3 of RFC 4013.
	Note also that common constructions such as "user@example.com" are		Note also that common constructions such as "user@example.com" are
	allowed as simple user names when using software that conforms to		allowed as simple user names when using software that conforms to
	this specification, as they were under [RFC4013].		this specification, as they were under [RFC4013].
	2.2. Preparation		2.2. Preparation
	A simple user name MUST NOT be zero bytes in length. This rule is to		A simple user name MUST NOT be zero bytes in length. This rule is to
	be enforced after any normalization and mapping of code points.		be enforced after any normalization and mapping of code points.
	Each simplepart of a simple user name MUST conform to the definition		Each simplepart of a simple user name MUST conform to the definition
	of the PRECIS IdentifierClass provided in [FRAMEWORK], where the		of the PRECIS IdentifierClass provided in [FRAMEWORK], where the
	normalization, casemapping, and directionality rules are as described		width mapping, additional mapping, case mapping, normalization, and
	below.		directionality rules are as described below.
	1. Unicode Normalization Form C (NFC) MUST be applied to all
	characters.
	2. Uppercase and titlecase characters MUST be mapped to their
	lowercase equivalents.
	3. Additional mappings MAY be applied, such as those defined in		1. Fullwidth and halfwidth characters MUST be mapped to their
			decomposition equivalents.
			2. Additional mappings MAY be applied, such as those defined in
	[I-D.ietf-precis-mappings].		[I-D.ietf-precis-mappings].
			3. Uppercase and titlecase characters MUST be mapped to their
			lowercase equivalents.
			4. Unicode Normalization Form C (NFC) MUST be applied to all
			characters.
	With regard to directionality, the "Bidi Rule" provided in [RFC5893]		With regard to directionality, the "Bidi Rule" provided in [RFC5893]
	applies.		applies.
	3. Passwords		3. Passwords
	3.1. Definition		3.1. Definition
	For purposes of preparation and comparison of passwords, this		For purposes of preparation and comparison of passwords, this
	document specifies that a password is a string of Unicode code points		document specifies that a password is a string of Unicode code points
	[UNICODE], encoded using UTF-8 [RFC3629], and conformant to the		[UNICODE], encoded using UTF-8 [RFC3629], and conformant to the
	PRECIS FreeformClass.		PRECIS FreeformClass.
	Therefore the syntax for a password is defined as follows using the		Therefore the syntax for a password is defined as follows using the
	Augmented Backus-Naur Form (ABNF) as specified in [RFC5234].		Augmented Backus-Naur Form (ABNF) as specified in [RFC5234].
	password = 1*(freepoint)		password = 1*(freepoint)
	;		;
	; a "freepoint" is a UTF-8 encoded		; a "freepoint" is a UTF-8 encoded
	; Unicode code point that conforms to		; Unicode code point that conforms to
	; the PRECIS "FreeformClass"		; the PRECIS "FreeformClass"
	;		;
	Note well that all code points and blocks not explicitly allowed in		Note well that all code points and blocks not explicitly allowed in
	the PRECIS FreeformClass are disallowed; this includes private use		the PRECIS FreeformClass are disallowed; this includes private use
	characters, surrogate code points, and the other code points and		characters, surrogate code points, and the other code points and
	blocks defined as "Prohibited Output" in Section 2.3 of RFC 4013.		blocks defined as "Prohibited Output" in Section 2.3 of RFC 4013.
	3.2. Preparation		3.2. Preparation
	A password MUST NOT be zero bytes in length. This rule is to be		A password MUST NOT be zero bytes in length. This rule is to be
	enforced after any normalization and mapping of code points.		enforced after any normalization and mapping of code points.
	A password MUST be treated as follows, where the operations specified		A password MUST be treated as follows, where the operations specified
	MUST be completed in the order shown:		MUST be completed in the order shown:
	1. Apply Unicode Normalization Form C (NFC) to all characters.		1. Width mapping is not applied.
	2. Map any instances of non-ASCII space to ASCII space (U+0020).		2. Map any instances of non-ASCII space to ASCII space (U+0020).
			3. Case mapping is not applied.
	3. Ensure that the resulting string conforms to the definition of		4. Apply Unicode Normalization Form C (NFC) to all characters.
			5. Ensure that the resulting string conforms to the definition of
	the PRECIS FreeformClass.		the PRECIS FreeformClass.
	With regard to directionality, the "Bidi Rule" (defined in [RFC5893])		With regard to directionality, the "Bidi Rule" (defined in [RFC5893])
	and similar rules are unnecessary and inapplicable to passwords,		and similar rules are unnecessary and inapplicable to passwords,
	since they can reduce the range of characters that are allowed in a		since they can reduce the range of characters that are allowed in a
	string and therefore reduce the amount of entropy that is possible in		string and therefore reduce the amount of entropy that is possible in
	a password. Furthermore, such rules are intended to minimize the		a password. Furthermore, such rules are intended to minimize the
	possibility that the same string will be displayed differently on a		possibility that the same string will be displayed differently on a
	system set for right-to-left display and a system set for left-to-		system set for right-to-left display and a system set for left-to-
	right display; however, passwords are typically not displayed at all		right display; however, passwords are typically not displayed at all
	skipping to change at page 7, line 26 ¶		skipping to change at page 7, line 50 ¶
	equivalents to those equivalents, whereas the PRECIS		equivalents to those equivalents, whereas the PRECIS
	IdentifierClass entirely disallows Unicode code points with		IdentifierClass entirely disallows Unicode code points with
	compatibility equivalents (i.e., during comparison NFKC is more		compatibility equivalents (i.e., during comparison NFKC is more
	"aggressive" about finding matches than is NFC). A few examples		"aggressive" about finding matches than is NFC). A few examples
	might suffice to indicate the nature of the problem: (1) U+017F		might suffice to indicate the nature of the problem: (1) U+017F
	LATIN SMALL LETTER LONG S is compatibility equivalent to U+0073		LATIN SMALL LETTER LONG S is compatibility equivalent to U+0073
	LATIN SMALL LETTER S (2) U+2163 ROMAN NUMERAL FOUR is		LATIN SMALL LETTER S (2) U+2163 ROMAN NUMERAL FOUR is
	compatibility equivalent to U+0049 LATIN CAPITAL LETTER I and		compatibility equivalent to U+0049 LATIN CAPITAL LETTER I and
	U+0056 LATIN CAPITAL LETTER V (3) U+FB01 LATIN SMALL LIGATURE FI		U+0056 LATIN CAPITAL LETTER V (3) U+FB01 LATIN SMALL LIGATURE FI
	is compatibility equivalent to U+0066 LATIN SMALL LETTER F and		is compatibility equivalent to U+0066 LATIN SMALL LETTER F and
	U+0069 LATIN SMALL LETTER I. Under SASLprep, the use of NFKC also		U+0069 LATIN SMALL LETTER I. Under SASLprep, the use of NFKC also
	handled the mapping of fullwidth and halfwidth code points to		handled the mapping of fullwidth and halfwidth code points to
	their decomposition equivalents (see [I-D.ietf-precis-mappings]).		their decomposition equivalents (see [I-D.ietf-precis-mappings]).
	Although it is expected that code points with compatibility		Although it is expected that code points with compatibility
	equivalents are rare in existing user names, for migration		equivalents are rare in existing user names, for migration
	purposes deployments might want to search their database of user		purposes deployments might want to search their database of user
	names for Unicode code points with compatibility equivalents and		names for Unicode code points with compatibility equivalents and
	map those code points to their compatibility equivalents.		map those code points to their compatibility equivalents.
	o SASLprep mapped non-ASCII spaces to ASCII space (U+0020), whereas		o SASLprep mapped non-ASCII spaces to ASCII space (U+0020), whereas
	the PRECIS IdentifierClass entirely disallows non-ASCII spaces.		the PRECIS IdentifierClass entirely disallows non-ASCII spaces.
	The non-ASCII space characters are U+00A0 NO-BREAK SPACE, U+1680		The non-ASCII space characters are U+00A0 NO-BREAK SPACE, U+1680
	OGHAM SPACE MARK, U+180E MONGOLIAN VOWEL SEPARATOR, U+2000 EN QUAD		OGHAM SPACE MARK, U+180E MONGOLIAN VOWEL SEPARATOR, U+2000 EN QUAD
	through U+200A HAIR SPACE, U+202F NARROW NO-BREAK SPACE, U+205F		through U+200A HAIR SPACE, U+202F NARROW NO-BREAK SPACE, U+205F
	MEDIUM MATHEMATICAL SPACE, and U+3000 IDEOGRAPHIC SPACE. For		MEDIUM MATHEMATICAL SPACE, and U+3000 IDEOGRAPHIC SPACE. For
	migration purposes, deployments might want to convert non-ASCII		migration purposes, deployments might want to convert non-ASCII
	space characters to ASCII space in simple user names.		space characters to ASCII space in simple user names.
	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 "M" category defined under		correspond to the code points from the "M" category defined under
	Section 6.13 of [FRAMEWORK] (with the exception of U+1806		Section 6.13 of [FRAMEWORK] (with the exception of U+1806
	MONGOLIAN TODO SOFT HYPHEN, which was "commonly mapped to nothing"		MONGOLIAN TODO SOFT HYPHEN, which was "commonly mapped to nothing"
	in Unicode 3.2 but at the time of this writing does not have a		in Unicode 3.2 but at the time of this writing does not have a
	derived property of Default_Ignorable_Code_Point in Unicode 6.1).		derived property of Default_Ignorable_Code_Point in Unicode 6.1).
	For migration purposes, deployments might want to remove code		For migration purposes, deployments might want to remove code
	points contained in the PRECIS "M" category from simple user		points contained in the PRECIS "M" category from simple user
	skipping to change at page 8, line 36 ¶		skipping to change at page 9, line 10 ¶
	Unicode Normalization Form C (NFC). Because NFKC is more		Unicode Normalization Form C (NFC). Because NFKC is more
	aggressive about finding matches than NFC, in practice this change		aggressive about finding matches than NFC, in practice this change
	is unlikely to cause significant problems and indeed has the		is unlikely to cause significant problems and indeed has the
	security benefit of probably resulting in fewer false positives		security benefit of probably resulting in fewer false positives
	when comparing passwords. A few examples might suffice to		when comparing passwords. A few examples might suffice to
	indicate the nature of the problem: (1) U+017F LATIN SMALL LETTER		indicate the nature of the problem: (1) U+017F LATIN SMALL LETTER
	LONG S is compatibility equivalent to U+0073 LATIN SMALL LETTER S		LONG S is compatibility equivalent to U+0073 LATIN SMALL LETTER S
	(2) U+2163 ROMAN NUMERAL FOUR is compatibility equivalent to		(2) U+2163 ROMAN NUMERAL FOUR is compatibility equivalent to
	U+0049 LATIN CAPITAL LETTER I and U+0056 LATIN CAPITAL LETTER V		U+0049 LATIN CAPITAL LETTER I and U+0056 LATIN CAPITAL LETTER V
	(3) U+FB01 LATIN SMALL LIGATURE FI is compatibility equivalent to		(3) U+FB01 LATIN SMALL LIGATURE FI is compatibility equivalent to
	U+0066 LATIN SMALL LETTER F and U+0069 LATIN SMALL LETTER I.		U+0066 LATIN SMALL LETTER F and U+0069 LATIN SMALL LETTER I. Under
	Under SASLprep, the use of NFKC also handled the mapping of		SASLprep, the use of NFKC also handled the mapping of fullwidth
	fullwidth and halfwidth code points to their decomposition		and halfwidth code points to their decomposition equivalents (see
	equivalents (see [I-D.ietf-precis-mappings]). Although it is		[I-D.ietf-precis-mappings]). Although it is expected that code
	expected that code points with compatibility equivalents are rare		points with compatibility equivalents are rare in existing
	in existing passwords, some passwords that matched when SASLprep		passwords, some passwords that matched when SASLprep was used
	was used might no longer work when the rules in this specification		might no longer work when the rules in this specification are
	are applied.		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 "M" category defined under		to the code points from the "M" category defined under Section
	Section 6.13 of [FRAMEWORK] (with the exception of U+1806		6.13 of [FRAMEWORK] (with the exception of U+1806 MONGOLIAN TODO
	MONGOLIAN TODO SOFT HYPHEN, which was commonly mapped to nothing		SOFT HYPHEN, which was commonly mapped to nothing in Unicode 3.2
	in Unicode 3.2 but at the time of this writing is allowed by		but at the time of this writing is allowed by Unicode 6.1). In
	Unicode 6.1). In practice, this change will probably have no		practice, this change will probably have no effect on comparison,
	effect on comparison, but user-oriented software might reject such		but user-oriented software might reject such code points instead
	code points instead of ignoring them during password preparation.		of ignoring them during password preparation.
	5. Security Considerations		5. Security Considerations
	5.1. Password/Passphrase Strength		5.1. Password/Passphrase Strength
	The ability to include a wide range of characters in passwords and		The ability to include a wide range of characters in passwords and
	passphrases can increase the potential for creating a strong password		passphrases can increase the potential for creating a strong password
	with high entropy. However, in practice, the ability to include such		with high entropy. However, in practice, the ability to include such
	characters ought to be weighed against the possible need to reproduce		characters ought to be weighed against the possible need to reproduce
	them on various devices using various input methods.		them on various devices using various input methods.
	skipping to change at page 9, line 37 ¶		skipping to change at page 10, line 13 ¶
	Unicode characters in user names and passwords.		Unicode characters in user names and passwords.
	6. IANA Considerations		6. IANA Considerations
	6.1. Use of IdentifierClass		6.1. Use of IdentifierClass
	The IANA shall add an entry to the PRECIS Usage Registry for reuse of		The IANA shall add an entry to the PRECIS Usage Registry for reuse of
	the PRECIS IdentifierClass in SASL, as follows:		the PRECIS IdentifierClass in SASL, as follows:
	Applicability: Usernames in SASL and Kerberos.		Applicability: Usernames in SASL and Kerberos.
	Base Class: IdentifierClass.		Base Class: IdentifierClass.
	Subclass: No.		Subclass: No.
	Replaces: The SASLprep profile of Stringprep.		Replaces: The SASLprep profile of Stringprep.
			Width Mapping: Map fullwidth and halfwidth characters to their
	Normalization: NFC.		decomposition equivalents.
	Casemapping: Map uppercase and titlecase characters to lowercase.
	Additional Mappings: None.		Additional Mappings: None.
			Case Mapping: Map uppercase and titlecase characters to lowercase.
			Normalization: NFC.
	Directionality: The "Bidi Rule" defined in RFC 5893 applies.		Directionality: The "Bidi Rule" defined in RFC 5893 applies.
	Specification: RFC XXXX. [Note to RFC Editor: please change XXXX to		Specification: RFC XXXX. [Note to RFC Editor: please change XXXX to
	the number issued for this specification.]		the number issued for this specification.]
	6.2. Use of FreeformClass		6.2. Use of FreeformClass
	The IANA shall add an entry to the PRECIS Usage Registry for reuse of		The IANA shall add an entry to the PRECIS Usage Registry for reuse of
	the PRECIS FreeformClass in SASL, as follows:		the PRECIS FreeformClass in SASL, as follows:
	Applicability: Passwords in SASL and Kerberos.		Applicability: Passwords in SASL and Kerberos.
	Base Class: FreeformClass		Base Class: FreeformClass
	Subclass: No.		Subclass: No.
	Replaces: The SASLprep profile of Stringprep.		Replaces: The SASLprep profile of Stringprep.
			Width Mapping: None.
	Normalization: NFC.
	Casemapping: None.
	Additional Mappings: Map non-ASCII space characters to ASCII space.		Additional Mappings: Map non-ASCII space characters to ASCII space.
			Case Mapping: None.
			Normalization: NFC.
	Directionality: None.		Directionality: None.
	Specification: RFC XXXX. [Note to RFC Editor: please change XXXX to		Specification: RFC XXXX. [Note to RFC Editor: please change XXXX to
	the number issued for this specification.]		the number issued for this specification.]
	7. Open Issues		7. Open Issues
	We need to compare the output obtained when applying the new rules		We need to compare the output obtained when applying the new rules
	with Unicode 3.2 and Unicode 6.1 data to the output obtained when		with Unicode 3.2 and Unicode 6.1 data to the output obtained when
	applying the SASLprep rules with Unicode 3.2 data, then make sure		applying the SASLprep rules with Unicode 3.2 data, then make sure
	that the PRECIS Working Group and KITTEN Working Group are		that the PRECIS Working Group and KITTEN Working Group are
	comfortable with any changes to the Unicode characters that are		comfortable with any changes to the Unicode characters that are
	allowed and disallowed. (See also the migration issues described		allowed and disallowed. (See also the migration issues described
	under Section 4.)		under Section 4.)
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[FRAMEWORK]		[FRAMEWORK]
	Saint-Andre, P. and M. Blanchet, "Precis Framework:		Saint-Andre, P. and M. Blanchet, "Precis Framework:
	Handling Internationalized Strings in Protocols", draft-		Handling Internationalized Strings in Protocols",
	ietf-precis-framework-07 (work in progress), March 2013.		draft-ietf-precis-framework-07 (work in progress),
			March 2013.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, November 2003.		10646", STD 63, RFC 3629, November 2003.
	[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	skipping to change at page 11, line 30 ¶		skipping to change at page 11, line 43 ¶
	progress), December 2012.		progress), December 2012.
	[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of		[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
	Internationalized Strings ("stringprep")", RFC 3454,		Internationalized Strings ("stringprep")", RFC 3454,
	December 2002.		December 2002.
	[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names		[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
	and Passwords", RFC 4013, February 2005.		and Passwords", RFC 4013, February 2005.
	[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple		[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
	Authentication and Security Layer (SASL)", RFC 4422, June		Authentication and Security Layer (SASL)", RFC 4422,
	2006.		June 2006.
	[RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and		[RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and
	Security Layer (SASL) Mechanism", RFC 4616, August 2006.		Security Layer (SASL) Mechanism", RFC 4616, August 2006.
	[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,		[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
	"Salted Challenge Response Authentication Mechanism		"Salted Challenge Response Authentication Mechanism
	(SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.		(SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.
	[RFC5890] Klensin, J., "Internationalized Domain Names for		[RFC5890] Klensin, J., "Internationalized Domain Names for
	Applications (IDNA): Definitions and Document Framework",		Applications (IDNA): Definitions and Document Framework",
End of changes. 31 change blocks.
	119 lines changed or deleted		105 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/