proposed charter for "NewPrep" WG

[Peter Saint-Andre <[e-mail]>]

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 [e-mail] list:

https://www.ietf.org/mailman/listinfo/newprep

My apologies for cross-posting; please send replies to [e-mail].

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.

######