Re: request for agenda items

[Nicolas Williams <Nicolas.Williams at sun.com>]

On Fri, Jul 01, 2005 at 07:11:48PM +0200, Martin Rex wrote:
> The things that may need to be removed because of a lack of
> interoperability are according to *MY* experience:
>  - channel bindings

There are interoperable implementations of channel bindings.

For years MIT's FTP w/ GSS-API implementation used channel bindings.

>  - hostbased service names

There are interoperable implementations of hostbased service names.

A number of NFS implementors interoperate using the Kerberos V mechanism
and hostbased service names.

Demonstrations can be arranged.

> Another difficult area is the use of (printable) names
> with GSS-API.  The seriously underspecified RFC-2025
> (The Simple Public Key GSS-API mechanism) does not
> define a mechanism specific name format, which significantly
> impairs interoperability in a heterogeneous environment
> and may outright prevent interoperability in a heterogeneous
> distributed environment.

I'd like SPKM to be moved to Historic.

> The definition of the name format in the Kerberos gssapi mechanism spec
> rfc-1964 has saved Kerberos from the most serious troubles, but
> the transition from just-send-8 to Unicode/UTF-8 characters exists.
> 
> 
> This is an area where GSS-API v2 can be considered underspecified.
> 
> The data type when passing a printable name through a gssapi function
> is "octet string" with an accompanying nametype OID, and the most
> common implementation tradition is to use whatever 8-bit character
> set is the default on the platform.

RFC2744 speaks of Latin-1 -- a really poor choice.  Instead the
character encoding and any language settings (for localization in
gss_display_status(), say) should be platform-specific, with conversions
to/from UTF-8 or any other character set/encoding left to mechanisms
where they require it.

Most platforms nowadays have a concept of locale.

POSIX should have a thread-safe notion of locale, and one could be
grafted on to it, and really should be, but it's not there yet.

> When printable names are the input to gssapi calls, it should be
> possible to add a nametype-OID for every existing with the
> same inpretation, just indicating that the encoding is UTF-8
> rather than the default local 8-bit charset.

Or the application could communicate this to the GSS implemantation
using locales, letting the mechanisms convert as necessary.

This is not a perfect solution, to be sure, as it's not possible to
enter all Unicode characters or equivalents in most non-Unicode locales.

But then, if users are running in non-Unicode locales and need to enter
or display Unicode characters that their non-Unicode locales don't allow
for, well, then they should start using Unicode locales.

I.e., I see the GSS-API I18N issues as mostly, or entirely, even, a
platform- and mechanism-specific issue.

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten