Re: New drafts

[nisse%lysator.liu.se@localhost (Niels Möller)]

der Mouse <mouse%Rodents.Montreal.QC.CA@localhost> writes:

> >   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).

I admit I haven't actually read the iso-8859-1 standard. I was
thinking about the 0x80 - 0xff range as defined by the "C1 controls
and latin1" page of the unicode book, which defines 0x80-0x9f.

> ...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"

Under the assumption that the server will convert the utf-8 it
receives to iso-8859-1 (including control characters, i.e. the range
0x00 - 0xff of unicode, and equvivalents), for each octet x there
exists one (sometimes more than one) sequence of utf-8 octets that
server will convert back into the octet x you started with.

> 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.

I'm not sure which alternative you are comparing utf-8 passwords to
here. I just want to add that unix systems also have the choice of
supporting only ascii-passwords.

In practice, I'd expect the majority of unix systems to

  * use ascii-only passwords, or

  * use a single eight-bit character set for (almost) all user's
    passwords, or

  * use utf-8 passwords. And then we have to pray to $DEITY that
    passwords are normalized in some consistent way before being
    passed to crypt(3).

About the same applies to user names.

Regards,
/Niels