Future of SASLprep

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

"Frank Ellermann" <nobody@xxxxxxxxxxxxxxxxx> writes:

> I'm fine with using SASLprep "everywhere" (incl. CRAM-MD5)
> in SASL, or maybe switch to RFC 5198 "everywhere" when it
> turns out that SASLprep is not implemented.

Given how poor SASLprep works in practice (*), I think this could be
discussed (but separately from CRAM-MD5).

The IDNAbis effort seems now well under way, and it seems clear we
cannot re-use much of their work since they abandon the StringPrep
approach.  Passwords have quite different properties than domain names:
it is normal and encouraged for passwords to contain characters from
different scripts.  For example, some of the steps made by current
SASLprep reduces entropy (e.g., translates ª to a), which seems like a
property we failed to discuss at the time.  We cannot re-use much of the
output from the IDNAbis design discussions either, because they are
based on different assumptions.

The discussions about Unicode versioning in RFC 5198 is better than in
SASLprep.  Some elements of SASLprep, such as prohibiting certain
non-printable characters is useful.

Possibly SASLprep2 could be a profile of RFC 5198: applying certain
algorithmic tests to restrict some characters on top of the RFC 5198
output.

/Simon

(*) Primarily because of the restriction to Unicode 3.2, but partly
because it hasn't been widely implemented.