Re: New drafts

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>>    Note that the 'plaintext password' value is encoded in ISO-10646
>>    UTF-8.  [...]
> I strongly prefer that we don't change that.  [...]

Me too - as you may have gathered. :-)

> I have one suggestion that may or may not satisfy der Mouse:

>   If a server really has no clue about what character set is used in
>   its password database, it SHOULD default to iso-8859-1.

Better than the proposed silence, but not entirely satisfactory, since
it leaves nothing for a server to do for octets in the 0x80-0x9f range
(which do not correspond to 8859-1 characters, as I understand 8859-1).

> Motivation: If you really need to pass an arbitrary octet string as a
> password, you can do that by encoding the octet string into utf8.

...hmm?  UTF-8 is a way of encoding 10646 codepoints as an octet
stream; it's not clear how you're proposing to get from "an arbitrary
octet string" to a string of 10646 codepoints to apply the UTF-8
algorithm to.  The closest thing to a sane method I can think of is to
zero-pad each octet to 16 bits and treat the resulting numbers as 10646
codepoints.  If this is what you're proposing, fine, but I think it
should be spelled out explicitly.

> The user's password is the octet string 0x72 0xc3 0xeb.  The user
> likes 8859-7, and thinks about the password as r, capital gamma,
> lowercase lambda, but the sysadmin and the ssh server have no clue
> about that.

> Now, the user sits at an utf8-only system (say, the windows-ce
> client), and wants to login.  Typing r, capital gamma, lowercase
> lambda won't work ([...]).  However, if the server interprets the
> utf8 it receives as latin 1, the user can login if he types "rÃë".

Yes...though if the server interprets received UTF-8 as Latin-1, it's
not clear what the server should do with that gamma and lambda, or any
other received 10646 not present in Latin-1.

> To really support arbitrary character sets in passwords, different
> for each user, the ssh server somehow needs to figure out the user's
> preferred locale before trying to verify the password [...].

Yes.  The difficulty of implementation and ugliness of that are why I
think passwords shouldn't be character strings, but octet strings, with
character sets brought in only when it's time to type a password.  (Or
display them, if that's ever done, though I'd hope it wouldn't be.)

This would mean that an ssh client system needs a way for the user to
enter an arbitrary octet sequence when prompted for a password.  I
consider that a less serious problem than requiring every Unix
derivative supporting ssh to either (a) redesign their password systems
so that passwords become character strings or (b) not support password
authentication.  If it came down to that choice, I'd unhesitatingly
pick (b), though more likely I'd implement passwords as arbitrary octet
strings and ignore the conformance issue.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B