Re: Proposed SASL WG charter description

[Kurt Zeilenga <[e-mail]>]

On Sep 8, 2008, at 4:26 AM, Simon Josefsson wrote:

>
> Alexey Melnikov <[e-mail]> writes:
>
>> Frank Ellermann wrote:
>>
>>> Kurt Zeilenga wrote:
>>>
>>>
>>>> This group will produce a document revising SASLprep [RFC4013]
>>>> to improve Unicode version agility while maintaining RFC 4013
>>>> behavior when used with RFC 4013 mandated version of Unicode.
>>>> The outcome of this work will be a Standards Track RFC replacing
>>>> RFC 4013.
>>>>
>>>>
>>> Does that allow for "abandon SASLprep in favour of net-UTF8" ?
>>>
>>>
>> A very good question indeed.
>
> Given that few have implemented RFC 4013 I'm not sure that backwards
> compatibility with it has to be an absolute mandate in the SASL WG
> charter.

My view is that it's not an "absolute mandate".  As I noted in my  
response to Frank's comments, my intent was to keep a narrow focus on  
the work.  I specially don't want to revisit discussions such as  
"Should character X be excluded?".   I want to limit the work to  
replacing stringprep tables with Unicode properties.  SASLprepbis(x)  
== SASLprep(x) for all x (where x is well formed Unicode 3.2 text).


> Given the PR-29 problem (NFKC output has been altered for some code
> points in later Unicode versions), perfect backwards compatibility may
> not be something to strive for anyway.

How about "backwards compatibility for characters used in practice"?
PR-29 issues were limited to characters which do not occur in practice.

> Speaking as implementer of RFC 4013, I'd be happy to obsolete it in
> favor of net-UTF8.
>
>>> Roughly this could mean to replace NFKC-x by NFC-y.  Of course
>>> NFKC-x is a proper subset of NFC-y, what I'm talking about is
>>> to minimize the SASL-specific restrictions x vs. y, and to get
>>> rid of NFKC.
>>>
>>>
>> I am not sure NFC is better than KFKC for usernames/passwords.
>> But the idea of using NET-Unicode as the base seems interesting to  
>> me.
>
> NFKC removes more entropy from passwords than NFC.

Yes.  This issue was discussed when SASLprep was put forth on the  
Standards Track.  If we replace SASLprep, we will potentially revisit  
every decision.  I rather avoid doing so.  I rather we simply address  
the Unicode agility issue and move on.

> Even though NFKC was
> used by StringPrep for domain names, I'm not convinced it is the best
> choice for passwords.

I note that SASLprep is also used for user names.  Decisions need to  
be made not just based on "best choice for passwords" but "best choice  
for user names and passwords".