SASLprep200x

[Vint Cerf]

To the degree that Stringprep enables insensitivity to UNICODE version
changes, this is good. To the extent that it is possible to profile
stringprep for IDN vs other applications, this is good too. I stand by the
view that IDN should not interfere with nor be interfered by SASL
considerations.

V
 


Vinton G Cerf
Chief Internet Evangelist
Google
Regus Suite 384
13800 Coppermine Road
Herndon, VA 20171
 
+1 703 234-1823
+1 703-234-5822 (f)
 
vint at google.com
www.google.com
 

-----Original Message-----
From: John C Klensin [mailto:klensin at jck.com] 
Sent: Thursday, January 04, 2007 7:06 PM
To: Vint Cerf; 'Paul Hoffman'; idna-update at alvestrand.no
Subject: RE: SASLprep200x



--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