SASLprep200x

[John C Klensin]

--On Thursday, 04 January, 2007 18:39 -0500 Vint Cerf
<vint at google.com> wrote:

> I would argue strongly that we should NOT allow DNS to be
> conflated with strings used as passwords - these should be
> absolutely distinct in the sense that the DNS rules really
> need to be constrained for reasons far beyond anything one
> might associate with password preferences.

Vint,

While I agree, I really don't see a problem here and, to the
extent to which there is an issue, I think Simon has identified
the way out.  At the moment, we have a base list of rules from
which to select in Stringprep.  One of our goals, IMO a
necessary one, is to make Stringprep as nearly as possible
Unicode-version-agnostic.  But doing that doesn't have any
inherent impact on either IDNA or SASL or even on what
Stringprep does and does not permit (at least within the Unicode
3.2 context and conceptually more generally).

Then we have a pair of profiles of Stringprep -- Nameprep for
IDNA (I suspect it really should have been called "IDNAprep")
and its cousin for SASL ("SASLprep" for lack of a better term,
although I don't remember offhand if the SASL document actually
use that term).  In the versions now in effect, these profiles
are very "thin" -- they just call out Stringprep tables to be
used and how they are to be applied.  

>From my point of view, both Paul and Simon are correct, even
though they seem to be disagreeing with each other.  We should
have, if at all possible, a common character-interpretation
framework that applies to both (and, ideally, to more general
use of Unicode strings, as represented in the still-on-hold
Net-Unicode draft).  Certainly the two have at least one key
requirement in common: there had better be no disagreement
between client and server, or between two clients or two
servers, as to whether a string matches of not.  

But, beyond that, the two may diverge and it may be desirable to
make the profiles a little "thicker".  For example, if we could
figure out how to prohibit mixed-script labels in IDNA and get a
lot of leverage from it, we would probably do so.  I think it is
fairly clear at this point that we cannot, so this example is
probably moot, but it may still make a good illustration.   But
we might want to actually encourage script-mixing in
pass-phrases and some other security credentials, just as we
encourage odd mixtures of case, numerals, and assorted symbols
and punctuation in all-ASCII environments today.  The latter are
illustrative of a difference that already exists: ASCII special
characters are common and encouraged in passwords and
pass-phrases, but prohibited in domain name labels by the LDH
rule.

We may also not be able to make a general rule here because the
right conventions for passwords may not be the right conventions
for credential or certificate names.  The optimal requirements
for latter may be somewhat closer to the optimal requirements
for IDNs.  Or they may not.   The good news here, as Paul
suggests, is that the SASL- (and PKI) related WGs are sensitive
to the issues and quite capable of working through the cases and
developing solutions that meet their needs... as long as we
don't change Stringprep out from under them in a way that
invalidates existing and sensible credentials.  And we have no
intention of doing that... I hope.

      regards,
       john