Re: UTF8

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

Sam Hartman wrote:
> > > > > > "Joseph" == Joseph Galbraith <galb-list%vandyke.com@localhost> writes:
>
>
>     Joseph> I suppose if we really want to solve this problem, we do
>     Joseph> the following, we could introduce a new set of
>     Joseph> authentication messages where the client sends BOTH the
>     Joseph> UTF-8 and the raw data entered by the user.  Then the
>     Joseph> server can pick which to use.  The client knows the users
>     Joseph> LC_TYPE, and can therefore safely translate to UTF-8.
>
>     Joseph> I don't think we should do this, but if we want to do
>     Joseph> anything in the space, I think this is what we have to do.
>
> Speaking as an individual, I would not support delaying the core
> drafts for this change.

Definitely not.  To be honest, I don't really like the proposal
that much-- I was just tired of repeating the same debate over
and over again, so I figured we could move on to debating a
solution rather than the problem :-)

I also tend to be the type that figures if we've analyzed two
or three different solutions we are more likely to have found
the correct one than if we only considered one.

So, given the fact that I'm unwilling to hold up the core
drafts, think it terribly ugly that the entire auth draft
would have to be duplicated with multiple username and
password fields for each userauth-request message, there
are ambiguities and potential security issues in terms of
which username/password fields should be used by the server,
and reluctance from the AD, I'll withdraw my proposal.

For our unix implementations I believe that 'imposing' a
character set is a fine solution.

In fact, since all input systems, either local or remote,
connected to a 'octet' based system, MUST use the same
encoding system to provide passwords, I am quite confident
that allowing the administrator to specify a single charset
to translate usernames and passwords to will be sufficient
to produce interoperability superior to what would be
available on a locally attached terminal.

For example, if a user sits down at a X-Station and logs
on via XDM, the characters he types on the keyboard are
encoded in a certain way.  (This is irregardless of whether
the passwd database is storing octets or not.)

If the user then walks over to a VT320 terminal that is encoding
the keystrokes in a different way, he will not be able to log
in.  All the input devices capable of taking username/password
input MUST encode input characters identically.

So, from a certain viewpoint, in such an 'octet' system, the
passwd database is not really encoded in 'octets', it is simply
the charset used to encode input by the login devices in use.

I've felt all along that the current wording in the drafts
is fine, but now, over the course of this discussion and
and analysis of the problem, I've realized the limitations
of such an 'octet' based system, even to locally attached
terminals, so my brain now agrees with my gut.

I'm confident that a properly implemented SSH server that is
conformant to the drafts as currently written can produce
better interoperability than is available at the locally
attached terminal.

Equal interoperability could be obtained locally by having
the login, XDM, and passwd programs translate from the device's
input encoding to a common charset encoding... but that is a
discussion for a different mailing list :-)

So my vote is no change to the drafts.

Thanks,

Joseph