The following is a proposed charter for a "NewPrep" WG to work on
replacements for stringprep profiles in application and security
protocols such as XMPP and SASL. We plan to hold a BoF at IETF 77 to
explore whether it makes sense to form a working group on this topic. If
you are interested, please join the newprep(_at_)ietf(_dot_)org list:
https://www.ietf.org/mailman/listinfo/newprep
My apologies for cross-posting; please send replies to
newprep(_at_)ietf(_dot_)org(_dot_)
Thanks!
Peter
######
Proposed Charter for NewPrep WG
Last Updated: 2010-01-14
Problem Statement
The handling of non-ASCII strings in Internet protocols is a difficult
problem that has still not been solved in a generalized way. In 2002,
the IETF defined a method for preparation and comparison of
internationalized strings that could be re-used by various applications.
This method, stringprep (RFC 3454), has been re-used in several Internet
protocols that have defined "profiles" of stringprep, namely:
- The Nameprep profile (RFC 3490) for use in Internationalized Domain
Names (IDNs)
- The iSCSI profile (RFC 3722) for use in Internet Small Computer
Systems Interface (iSCSI) Names
- The Nodeprep and Resourceprep profiles (RFC 3920) for use in the
Extensible Messaging and Presence Protocol (XMPP)
- The Policy MIB profile (RFC 4011) for use in the Simple Network
Management Protocol (SNMP)
- The SASLprep profile (RFC 4013) for use in the Simple Authentication
and Security Layer (SASL)
- The trace profile (RFC 4505) for use with the SASL ANONYMOUS mechanism
In completing revisions to the IDN technology, the IETF's IDNAbis WG
decided to move away from the use of stringprep in domain names, instead
defining sets of allowed and disallowed characters based on Unicode
character properties (often called an "inclusion approach") rather than
defining explicit mappings of Unicode characters as in stringprep (an
"exclusion approach"). Although the IDNAbis WG had its reasons for
moving away from stringprep, and some of those reasons might not apply
to other applications (e.g., usernames in XMPP or usernames and
passwords in SASL), other reasons might apply more generally. In
particular, stringprep depends on a particular version of Unicode (3.2)
and cannot be upgraded to a new Unicode version without revising the
core stringprep technology.
However, any move away from stringprep by existing profiles would
introduce backward compatibility issues and migration challenges, which
need to be weighed against the benefits of a new string preparation
technology.
Objectives
The goal of this group is to assess whether an "inclusion approach"
similar to that taken in the revisions to Internationalized Doman
Names (IDNs) is appropriate for other stringprep profiles. Such an
approach would involve:
- A tiered model of permitted characters, especially the three
categories of valid, disallowed, and unassigned characters
- Protocol-specific lists of valid characters
- Potentially a reduction in the number of characters that are permitted
in usernames, passwords, and other identifiers
- Application of the foregoing concepts to existing profiles in ways
that respect the significant differences between those profiles
The group will analyze existing stringprep profiles to assess if it is
appropriate for them to move to an inclusion approach. If so, based on
consensus the group will do one of the following with regard to each
existing profile:
1. Directly complete a replacement for the profile, if it does not fall
within the scope of another active working group.
2. Collaborate with another active working group on developing a
replacement for its profile or profiles.
3. Advise the authors of profiles that were produced outside the context
of any working group regarding how to proceed.
Deliverables
1. Analysis of existing stringprep profiles.
2. Revisions to one or more existing stringprep profiles.
Milestones
To follow.
######
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf