[31303] in Kerberos
Re: Does Kerberos version 5 support i18n specifications?
daemon@ATHENA.MIT.EDU (Tom Yu)
Thu Jul 16 11:47:01 2009
To: suma <suma.s.gururaj@gmail.com>
From: Tom Yu <tlyu@MIT.EDU>
Date: Thu, 16 Jul 2009 11:46:29 -0400
In-Reply-To: <f917b9e7-9b25-47f5-9c1c-badac27739e9@h2g2000yqg.googlegroups.com>
(suma.s.gururaj@gmail.com's message of "Wed,
15 Jul 2009 21:44:22 -0700 (PDT)")
Message-ID: <ldv63dsaawa.fsf@cathode-dark-space.mit.edu>
MIME-Version: 1.0
Cc: kerberos@MIT.EDU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@MIT.EDU
suma <suma.s.gururaj@gmail.com> writes:
> I was told by some folks that some of the organizations such as
> Microsoft, Oracle etc., have implemented a kerberos solution to
> authenticate users with multibyte characters. Is anyone aware of it?
> If I were to provide support to authenticate multibyte characters; do
> I need to not use MIT kerberos libraries. Please advice how do I go
> about?
The Kerberos protocol (RFC 4120) allows only ASCII strings in
principal names. The earlier specification, RFC 1510, had an
unconstrained GeneralString type for principal names; this ASN.1 type
has a specific meaning (a certain subset of the ISO 2022 "shift"
encoding schemes), but early implementors misinterpreted the meaning
of this type.
In practice, this meant that implementors, including MIT Kerberos,
used whatever character encoding was in effect in the operating
environment, whether that was UTF-8, ISO 8859-1, etc., thus creating
an interoperability problem. There is no easy resolution to this
interoperability problem. If you have suggestions on how to improve
this character encoding situation, we will be pleased to consider
them.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
