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

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

This document is intended to be published as Informational.  The
document provides scope for the naming issues Kitten is attempting to solve.

The author believes that all responses received during the previous WGLC
have been addressed.  Please perform another review and send feedback to
the list stating that the review has been performed regardless of
whether or not there are comments.

This WGLC ends at 00:00 EST on Thursday May 4, 2006.

Jeffrey Altman

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

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

There was an error in the URL, I have corrected it for the group.

http://www.ietf.org/internet-drafts/draft-ietf-kitten-gss-naming-04.txt

  Happy that I could contribute...

-----Original Message-----
From: Jeffrey Altman [mailto:jaltman <at> columbia.edu]
Sent: Wednesday, April 19, 2006 5:49 PM
To: kitten <at> lists.ietf.org
Subject: Working Group Last Call (Take Two): Desired Enhancements to
GSSAPI Naming

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

This document is intended to be published as Informational.  The
document provides scope for the naming issues Kitten is attempting to solve.

The author believes that all responses received during the previous WGLC
have been addressed.  Please perform another review and send feedback to
the list stating that the review has been performed regardless of
whether or not there are comments.

This WGLC ends at 00:00 EST on Thursday May 4, 2006.

Jeffrey Altman
_______________________________________________________________________

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

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.

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

On Fri, Apr 21, 2006 at 11:23:46PM +0200, Martin Rex wrote:
> 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.

That is orthogonal to the naming extensions work.

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

Typically they use whatever the current locale demands, which is what
RFC2744 should have said all along.

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

This is a mechanism-specific issue.

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

>>>>> "Martin" == Martin Rex <martin.rex <at> sap.com> writes:

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

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

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

Good point.

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

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

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

Sam Hartman wrote:

>     Martin> Has anyone else encountered I18N issues with GSS-API
>     Martin> (C-Bindings) or already devised a solution?  What codepage
>     Martin> does your (gss-api) implementation use or your application
>     Martin> expect/use?
> 
> We have encountered issues but have not managed to solve them.
> 
> I don't think we can propose specific solutions in this draft
> basically because I don't think we have them yet, and I don't want to
> hold up this draft.  I do think we can add a section describing the
> problem and claiming it needs to be solved.  I will post text shortly.
> Assuming there are not other issues I'd prefer to last call that text
> but not re last call the entire document.
> 
> --Sam

Speaking as Chair, I would be happy to consider a separate WGLC on
just a new section of text.

Speaking as an Individual, I wonder whether Internationalization of
GSS-API should be considered part of the Naming draft.  It clearly is
a problem that needs to be solved but it is not in the same category
of scope definition that the rest of this draft attempts to provide.

Jeffrey Altman

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

On Friday, April 21, 2006 05:04:30 PM -0500 Nicolas Williams 
<Nicolas.Williams <at> sun.com> wrote:

> Typically they use whatever the current locale demands, which is what
> RFC2744 should have said all along.

Agree, to a point.

> I believe applications and the GSS-API functions that receive text
> inputs or which produce text outputs should use the current locale and
> nothing but.

For the exsting API functions, I agree.
However, I would not be opposed to defining an alternate set of interfaces 
which use UTF-8 for all text, allowing the application to fully take charge 
of locale issues.  If the only API available is one that depends on the 
current locale, then it is impossible for an application to receive names 
from the GSSAPI which contain characters not in the local character set, 
even if both the application and the underlying mechanism support such 
names.  Since in the IETF we have for some time been encouraging 
(requiring) application protocols to use UTF-8, it would seem to maek sense 
to make it possible for implementations of GSSAPI-using protocols to do so 
in a portable way.

> Mechanisms should do, in their tokens and protocols, whatever their
> specifications say, converting to/from the application locale as
> necessary.

... or to/from UTF-8, if that is the API in use.

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

On Mon, Apr 24, 2006 at 12:18:43PM -0400, Jeffrey Hutzelman wrote:
> On Friday, April 21, 2006 05:04:30 PM -0500 Nicolas Williams 
> <Nicolas.Williams <at> sun.com> wrote:
> 
> >Typically they use whatever the current locale demands, which is what
> >RFC2744 should have said all along.
> 
> Agree, to a point.
> 
> >I believe applications and the GSS-API functions that receive text
> >inputs or which produce text outputs should use the current locale and
> >nothing but.
> 
> For the exsting API functions, I agree.
> However, I would not be opposed to defining an alternate set of interfaces 
> which use UTF-8 for all text, allowing the application to fully take charge 
> of locale issues.  If the only API available is one that depends on the 
> current locale, then it is impossible for an application to receive names 
> from the GSSAPI which contain characters not in the local character set, 
> even if both the application and the underlying mechanism support such 
> names.  Since in the IETF we have for some time been encouraging 
> (requiring) application protocols to use UTF-8, it would seem to maek sense 
> to make it possible for implementations of GSSAPI-using protocols to do so 
> in a portable way.

Sure.

> >Mechanisms should do, in their tokens and protocols, whatever their
> >specifications say, converting to/from the application locale as
> >necessary.

Internationalization

>>>>> "Jeffrey" == Jeffrey Hutzelman <jhutz <at> cmu.edu> writes:

    Jeffrey> On Friday, April 21, 2006 05:04:30 PM -0500 Nicolas
    Jeffrey> Williams
    Jeffrey> <Nicolas.Williams <at> sun.com> wrote:

    >> Typically they use whatever the current locale demands, which
    >> is what RFC2744 should have said all along.

    Jeffrey> Agree, to a point.

    >> I believe applications and the GSS-API functions that receive
    >> text inputs or which produce text outputs should use the
    >> current locale and nothing but.

    Jeffrey> For the exsting API functions, I agree.  However, I would
    Jeffrey> not be opposed to defining an alternate set of interfaces
    Jeffrey> which use UTF-8 for all text, allowing the application to
    Jeffrey> fully take charge of locale issues.  If the only API
    Jeffrey> available is one that depends on the current locale, then
    Jeffrey> it is impossible for an application to receive names from
    Jeffrey> the GSSAPI which contain characters not in the local
    Jeffrey> character set, even if both the application and the
    Jeffrey> underlying mechanism support such names.  Since in the
    Jeffrey> IETF we have for some time been encouraging (requiring)
    Jeffrey> application protocols to use UTF-8, it would seem to maek
    Jeffrey> sense to make it possible for implementations of
    Jeffrey> GSSAPI-using protocols to do so in a portable way.

I wonder if the right way to do this is to create new OIDs for UTF8

Re: Internationalization

On Mon, 24 Apr 2006, Sam Hartman wrote:

> I wonder if the right way to do this is to create new OIDs for UTF8
> variants of name types?

I don't think so, because I think there are cases where you'll expect a
name to retain the same type end-to-end, and I think the question of
whether to use a locale-based API or a UTF-8-based one is at least partly
a matter for the application implementation.

But I could be wrong; I haven't thought about this idea more than you
have.

-- Jeff