On 1/5/2016 8:37 AM, Stephane Bortzmeyer wrote:
On Mon, Jan 04, 2016 at 09:30:32PM -0800,
Sean Leonard <[email protected]> wrote
a message of 120 lines which said:
how to take the Unicode input and get a consistent and reasonable
stream of bits out on both ends. For example: should the password be
case folded, converted to NFKC, encoded in UTF-8 vs. UTF-16BE, etc.?
There is already a standard on that, RFC 7613 "Preparation,
Enforcement, and Comparison of Internationalized Strings Representing
Usernames and Passwords" <http://www.rfc-editor.org/rfc/rfc7613.txt>
and I suggest we use it and do not reinvent the wheel.
Hello (sorry for my delayed response):
Yes, I am aware of PRECIS. I actually asked the PRECIS mailing list a
couple of months ago but got no feedback.
PRECIS is an overarching framework; it doesn't specify mappings in
particular. So merely saying "PRECIS!" is not enough.
In my proposal, the parameter "password-mapping" can take two relevant
PRECIS forms:
*precis
*precis-XXX (where XXX is a registered profile name)
In the first form, the mapping is defined by the OpaqueString profile,
/as amended from time to time/. This is the PRECIS password profile but
it doesn't specify a version or anything so additional characters may be
admitted in the future or treated differently, as the standards get
updated (including the Unicode standard). It is meant to be "living".
In the second form, it's PRECIS but is fixed to the specific profile
name. An interesting use case might be the recently registered
"Nickname" class [RFC7700] and
<http://www.iana.org/assignments/precis-parameters/profiles/Nickname.txt>.
In that profile, spaces are stripped and characters are treated
case-insensitively with Unicode Default Case Folding (among other
things). In applications where the encryption key is derived from a user
handle, this might be a relevant profile to name. Compare with
UsernameCaseMapped, etc.
Sean
