SASLprep200x

[Paul Hoffman]

At 10:22 AM +0100 1/3/07, Simon Josefsson wrote:
>There is one assumption that is often made in IDNA discussion, and
>that is that IDNA strings are assumed to contain "natural language",
>or put differently, that strings that you would never find in a
>newspaper or spoken by a human, are not worth consideration.

That is an unfair characterization. Such strings are not considered 
as high priority, but they are definitely worth consideration, given 
that we cannot predict which strings might be in a newspaper and/or 
spoken in the future.

>That assumption doesn't hold for passwords.  The more entropy you can
>put into a password, the better.  Picking a password that, for some
>reason, never would have been part of a dictionary or printed in a
>newspaper is a _good_ idea.

Quite true.

>This is one case where I think the design goals of StringPrep and
>SASLPrep are different.  If this issue is not taken into consideration
>in the StringPrep200x design, I think SASLPrep will ultimately have to
>be forked and have a separate design.

Fully agree. The current SASLPrep works OK because of our liberalness 
in the original Stringprep; a future SASLPrep based on a more 
conservative Stringprep would inherently be more limited.

>That would be unfortunate,
>since much of the work is duplicated.

Fully disagree. If the SASL community wants to change SASLprep to use 
more characters, they can revise their current standard; they don't 
need to use StringPrep200x. Under no circumstances should the DNS 
work be limited by the password work.

>It seems better if StringPrep
>allowed this, and when desired, the upper-level IDNA architecture
>disallow such strings.  Then SASLPrep200x may use StringPrep200x.

...at the expense of greater confusion that, in my opinion, is not 
worth it. The SASL folks are quite able to do their own extension of 
their base spec.