Re: UTF8

[Sam Hartman <hartmans-ietf%mit.edu@localhost>]

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

Speaking as an AD, I'm concerned about this proposal but perhaps not
sufficiently concerned to file a discuss.  We discussed a similar
proposal for Kerberos over in krb-wg and realized that we had
significant problems deciding what to do if the two strings were not
transforms of each other.  In some sense, the client is being given an
opportunity to try two usernames and passwords.

Are servers required to try both strings or just the one that is most
convenient to the server.  The obvious answer is that the server tries
the most convenient string.  But what happens when a client that
doesn't really know what its character set is talks to a unicode
server?  Again we find ourselves back in a situation where at least
one party needs to know what character set it speaks.


I'd like to draw the working group's attention to RFC 2277, the IETF's
character set policy.  Quoting section 3.1 of that document:

  3.1.  What charset to use

     All protocols MUST identify, for all character data, which charset
     is
        in use.

You would need to present a strong argument to the IESG why that
doesn't apply to you.

And as I said above, I'm concerned about the security implications of
sending two versions of the same string.

So if the working group decides to follow this approach, here is what
you must do.  First, you must describe RFC 2277 concerns and explain
why the charset policy does not apply or why you are violating a MUST
from that policy.  Second, you must explore the security implications
of your proposal and include them in the document you submit.  The
IESG will evaluate the proposal; I know my evaluation will focus on
these two issues.  It's reasonably lykely that the IESG will decide
not to publish such a proposal.


--Sam