Re: Working Group Last Call (Take Two): Desired Enhancements to GSSAPI

[Martin Rex <[e-mail]>]

Jeffrey Altman wrote:
>
> This note announces the start of a two week working group last call
> for the Kitten work item "Desired Enhancements to GSSAPI Naming".
> http://www.ietf.org/internet-drafts/draft-ietf-kitten-gss-naming-04..txt

One thing that hasn't be addressed, but which is probably an
issue (in particular with the IESG...):  I18N.

The C-Bindings document mentions at one place that printable strings
use the ISO Latin 1 codepage, but what actual implementations of
GSS-API mechanism really use (and what applications expect)
varies.

e.g. we do ship our application (and a particular oem library with
a gssapi mechanism) for two native EBCDIC platforms (OS/390 and OS/400),
and both use an EBCDIC codepage for the printables -- which differs
from ISO Latin 1 even for 7-bit ASCII (IA5) characters.

Even for language bindings that natively support Unicode (like Java),
the use of non-ASCII characters in the underlying GSS-API mechanism
may create interoperability problems, i.e. with Kerberos 5 principal
names and rfc1510 communication peers.


It might be a good idea if a gssapi mechanism and an application caller
(of the GSS-API C-Bindings) could agree on (or negotiate) the use of
UTF8-strings for printables instead of the currently defined
ISO-Latin-1 per rfc-2744 and the (de-facto) implementation defined
behaviour of exisiting implementations.


Supporting UTF-8 for printables (and have mechanism and application
negotiate or agree upon this) will usually require code changes
in both.  I may be forced to implement a proprietary extension
for interoperabitity of third-party gssapi libraries with our
application through an additional API call (for "negotiating"
the use of UTF-8 for printables) for our east european and asian
customers.  The use of non-ASCII and non-ISO-Latin-1 characters
within Subject DNames of X.509 certs is quite popular there and
so is the use of SPKM or SPKM-like gssapi mechanisms for Single Sign-On.


printable strings are "names" as input parameter to gss_import_name()
and output parameter from gss_display_name() as well as the
textual representations of minor and major status codes as
returned from gss_display_status().


Thoughts? Experiences?

Has anyone else encountered I18N issues with GSS-API (C-Bindings)
or already devised a solution?
What codepage does your (gss-api) implementation use or your
application expect/use?

AFAIK MIT Kerberos 5 has traditionally use the "just send 8(-bit)"
not just on the network, but also at the (GSS-)API.


-Martin

_______________________________________________
Kitten mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/kitten