Re: UTF8

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

Derek Fawcus wrote:
> On Wed, Jan 19, 2005 at 07:39:23PM +0100, Simon Josefsson wrote:
>
> > Perhaps it would be useful to consider what problems you would have
> > interacting with EBCDIC systems, to imagine what the situation is for
> > Latin-1 or Unicode users.  ASCII isn't the only 7-bit encoding.
>
>
> That is part of the point.  My local machine is using UTF-8,  the Unix
> machines I ssh into are in 8859-1,  and I do use a couple of 8 bit
> characters.  However simply not in my username or password.  Hence the
> local unicode characters (when UTF-8 encoded) are valid ASCII,  and
> hence I can log in.  Once logged in,  I can use those 8859-1 characters
> (i.e. The pounds sterling symbol).
>
> You point wrt EBCDIC is valid,  but I don't now the appropriate answer.
> Also,  do their authentication systems work with a charset,  or octets?

I don't know, but someone implementing a server on such a
system would!  And they could then convert the UTF-8
correctly to either EBCDIC if that is what is needed
(one presumes that if the authentication is not charset
aware the authentication devices attached to such a
system a probably producing EBCDIC), or to some other
charset if specified by the authentication system.

See that is the thing.  I don't know squat about EBCDIC,
and my OS doesn't know squat about EBCDIC and can't convert
to or from it.  So even if the server told me, please send
me EBCDIC, I just can't do it.

On the other hand, such a server implementation running
on an EBCDIC machine _does_ know about EBCDIC.  Hence,
the correct place for charset conversion is on the server.

Thanks,

Joseph

PS. If your 8859-1 systems had a comforming SSH implementation,
you would be able to use 8859-1 character in you password, which
would potentially double the security of your password.

A password guessor is probably going to stick to 7-bit characters;
he'll get most passwords there.  (And if you force him to include 8-bit 
characters, he has got a bigger space to cover-- not really double,
but significantly larger.)