Re: Security

["Frank Ellermann" <nobody@xxxxxxxxxxxxxxxxx>]

Kurt Zeilenga wrote:

>> Normally we say "SHOULD" when we mean "old stuff
>> has a good excuse, its old".
 
> There are many reasons to use SHOULD.

Sure, "old" is just one reason commonly accepted as 
"good excuse" without talking about it, because a
protocol or programs written before the SHOULD was
introduced typically could not foresee this.

For other reasons updated specifications with a new
SHOULD ideally mention what might be good excuses,
otherwise folks could claim that "because I say so"
is good enough to violate a SHOULD.

 [i18n] 
> With PLAIN, the client lack of knowledge doesn't
> matter.  It simply provides the UTF-8 encoded
> Unicode password.  The server can sort it out.

Okay, got it, when say SASLprep is used this has
to be done on the side of the client for CRAM-MD5
passwords.  For PLAIN passwords the server can do
it or something else, as long as the client sends
UTF-8 (maybe limited to Unocode 3.2).

Apparently the client "MUST NOT" use SASLprep for 
PLAIN, that could confuse "something else" on the
server side.  Is that correct ?

SASLprep(x) = SASLprep( SASLprep(x)) would help
if both sides try the same preparation for PLAIN.

So we need a MUST for CRAM-MD5 and UTF8-non-ascii
passwords on the side of the client.  

>     Except where the client and server have an a
> priori agreement to utilize a different character
> set, encoding, and/or preparation, the password
> MUST be represented using Unicode, prepared using
> SASLprep, and encoded as UTF-8 prior to input
> to the cryptographic functions.

+1  A different charset is not necessarily an issue,
when it is transformed to SASLprepped UTF-8 in the
preparation step.  That's remotely the same idea as
for IRIs in legacy charsets.

A legacy charset could be even an advantage, almost
all of them are covered by Unicode 3.2, as required
by SASLprep.

 Frank