Subject: Re: UTF-8

From: Jeffrey Altman <[email-masked]>
Date: Sat, 10 Nov 2001 10:50:51 EST

>    Date: Fri, 9 Nov 2001 20:05:46 -0500 (EST)
>    From: Jeffrey Hutzelman <[email-masked]>
>    [...]
>    Soon, yes, definitely.  But not now.  As I said in a previous message,
>    attempting to get UTF-8 into kerberos revisions will delay the document
>    for quite some time -- while it looks easy on the surface, there are lots
>    of issues that need to be nailed down, and IMHO we simply cannot make
>    kerberos-revisions wait longer while we get it right.
> 
> You've said this several times; can you list out the issues so we can
> make our own judgement on how long they'll take?
> 
> It's fairly worthless to application protocols to accept UTF-8
> usernames if the authentication system can't prove the identity of any
> such users, therefore this is an important aspect.
> 
> Larry
> 
> 

Larry:

Jeff listed the issues in his summary e-mail to the list.  In
addition to defining the messaging requirements in ASN.1 the most
difficult issue is going to be defining the canonicalization rules
which Kerberos is going to use for Unicode and the subset of Unicode
which will be deemed acceptable.

For those who are not familiar with the details behind the creation of
Unicode, unlike other ISO character sets or OEM Code Pages, Unicode is
not simply a large table of characters.  In order to reduce the number
of code points that would be needed, Unicode allows characters to be
described as a base character and set of modifiers.  Of course, a
character that has more then one modifier can be represented in
2^(n-1) ways where 'n' is the number of modifiers.  But that is not
the worst part.  Due to socio-political concerns many characters which
could be represented as a base character plus modifier are also
present as a combined character.  Not to mention all of the characters
are visibly alike but are semanticly different.

 . is a Greek delta a character or a mathematical sign?
   In Unicode, it is both each meaning has a different code point.

 . there is both a circled-C and a copyright sign

 . latin capital A with diaeresis is 00C4; but it is also 212B
   and the combined character 0041 + 030A

Then you can throw in the fact that Unicode 1.0, 1.1, and 2.0 are not
upwardly compatible.  The sorting rules have changed with each Unicode
release.  You can begin to see why there might be some issues.

In order for Unicode to become the standard character set of Kerberos
we need to decide how we are going to reduce the many varied
representations of characters to a common canonical form such that
every client, KDC, and service will agree.  You do not want users to
be able to login from Windows but not be able to login using their
Java client simply because both Windows and Java have different ideas
on how to keyboard events into Unicode characters.

These issues appear extremely manageable when dealing with American
English and Western European languages.  However, once you start with
the Eastern languages the problem do not scale well to a small
ruleset.  Instead, what is needed is for all Unicode character strings
to be processed through a database of canonicalization rules.  Our
standard must agree upon a specific database and a specific version of
Unicode.  

The issues are not simply technical ones.  There are some major
socio-political issues here as well.  Unicode is a 16-bit
character-set.  ISO-10646 is the superset of Unicode which is a 32-bit
space.  It is well known that all the characters that need to go into
Unicode will not fit in 16-bits.  The current goal is to keep the
space under 22-bits.  So if we choose Unicode over ISO-10646 there are
going to be languages which will not be usable with Kerberos.

The choice of UTF-8 is also troublesome.  UTF-8 discrimates in favor
of Western European languages and against those of Asia.  This is
because a US-ASCII character takes up one byte in UTF-8 whereas a CJK
character can take four bytes to represent.  Whereas using straight
Unicode requires two bytes for all characters.  (If we decide on
ISO-10646 things get even worse with characters in higher planes
taking up to eight bytes to represent.)

Most operating systems these days do not allow the use of the full
Unicode set.  Instead they restrict the use of Unicode to only those
characters that can be represented without modifiers.  Part of the
reason for this is that Unicode places the base character first
followed by the modifiers.  This was done because the Unicode
committee was made up primarily of representatives of the printing
community.  When you are doing page markup or printing the width of
the base character determines the spacing.  Once it is printed, you
can simply overlay the modifiers on top.  Obviously, when you are
using a streaming input where you do not simply care about output but
actually care about the semantic differences between the combined
characters it would be preferable to have the modifiers come first
followed by the base character.  That way you would know when the
character sequence has ended.  Can you imagine the difficulties that
are to be dealt with if a user is entering their username or password
by hand with a list of modifiers?  

Of course, if you choose to restrict the use of Unicode so that
modifiers cannot be used you are going to alienate a large part of the
Earth's population.  Any decision we make is going to be the recipient
of a large amount of criticism.  We can not simply push something
through the process even if we new the answers to the technical
questions.  The socio-political forces just will not allow it.

Therefore, I agree with Jeff 100%.  Revisions must go ahead without
the definition of how Unicode will be used.  However, revisions must
indicate how Unicode will plug into the messaging framework once it is
decided. 

In the meantime, I am going to write based upon my comments above,
Tom's comments in revisions, and Jeff's summary of a few days ago to
this list an Informational I-D describing why we as a Working Group
strongly recommend that all current implementations and deployments of
Kerberos 5 restrict themselves to US-ASCII.

 Jeffrey Altman * Sr.Software Designer      C-Kermit 8.0 Beta available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to follow.

---

From: Russ Allbery <[email-masked]>
Date: 10 Nov 2001 15:44:22 -0800

Jeffrey Altman <[email-masked]> writes:

> character that has more then one modifier can be represented in 2^(n-1)
> ways where 'n' is the number of modifiers.  But that is not the worst
> part.  Due to socio-political concerns many characters which could be
> represented as a base character plus modifier are also present as a
> combined character.

Unicode however also defines a set of normalization rules that are
intended to deal with this situation.  For the purposes of Kerberos, I
expect one would want to use the most aggressive canonicalization rule
(compatibility decomposition).  The choice of NFKD or NFKC is largely
dependent on the needs of the application; I'm not sure which would be
more appropriate for Kerberos.  (The difference lies in whether characters
are left in a fully decomposed state or not.)

See <http://www.unicode.org/unicode/reports/tr15/> for the specifications
of Unicode normalization.  There are available libraries for doing Unicode
normalization.

> Not to mention all of the characters are visibly alike but are
> semanticly different.

Does this matter?  If people use those characters as part of their
identity, they may need to deal with that issue, but I don't see why the
protocol needs to beyond using Unicode normalization.  Note that Unicode
compatibility decomposition already deals with some of this, as I recall.

If Kerberos *really* needs more than that, the DNS working group is
working on more aggressive canonicalization methods to deal with the fact
that hostnames are frequently mentioned in print and then retyped.  But
Kerberos strikes me as a much simpler case that doesn't have to be as
robust against mis-entered names.

> release.

I'm not sure why Kerberos would care about sorting rules, but I may be
missing something important.

The normalization rules are guaranteed to be upwardly compatible to all
future versions of Unicode.

> socio-political issues here as well.  Unicode is a 16-bit character-set.

No, it's not, and hasn't been since Unicode 3.0.  See, for example,
<http://www.unicode.org/unicode/faq/basic_q.html#19>.  Unicode defines a
32-bit character standard.

> ISO-10646 is the superset of Unicode which is a 32-bit space.

No, it's not.  See <http://www.unicode.org/unicode/faq/unicode_iso.html>
for an explanation of the relationship between ISO 10646 and Unicode.
Unicode is actually a superset of ISO 10646, sharing the same character
encoding and adding a great deal of additional useful information and
standardization to make it easier to use the character set.

There is no need to choose one or the other; they define precisely the
same set of characters, although Unicode releases standards faster (so
there are characters that have been agreed upon by both the ISO working
group and the Unicode Consortium which are in Unicode 3.1 but which have
not yet been released as an ISO standard, although they will be).

> The choice of UTF-8 is also troublesome.  UTF-8 discrimates in favor of
> Western European languages and against those of Asia.  This is because a
> US-ASCII character takes up one byte in UTF-8 whereas a CJK character
> can take four bytes to represent.  Whereas using straight Unicode
> requires two bytes for all characters.

There is no such thing as "straight Unicode" in the context in which
you're using it, as Unicode is not a character encoding.  Unicode is a set
of characters, and you have to pick an encoding.

It sounds like you're talking about UTF-16 without surrogates in the last
sentence above, which is obviously a bad encoding to choose for any new
application for the reasons that you state.  The IETF is standardizing on
UTF-8; the other reasonable alternative is UTF-32.  UTF-16 even with
surrogates should be avoided since it combines all of the problems of both
UTF-8 and UTF-32 for no real gains.

When evaluating whether UTF-8 "discriminates" (which I think is a very
poor way of phrasing the problem, although a common one -- the problem
isn't that the creators of Unicode didn't care as much about Asian
languages, but that Asian languages have a *lot* of characters and
therefore by necessity require more bytes to encode), it's worth bearing
in mind that most *native* Asian encodings use at least two bytes per
character.  The UTF-8 expansion over the native encodings is not actually
that bad (and I don't think that we need to be so parsiminous with bytes
at this level; in fact, using UTF-32 may well be the best choice).

> (If we decide on ISO-10646 things get even worse with characters in
> higher planes taking up to eight bytes to represent.)

Those are incredibly rare characters that are very unlikely to be seen
within a Kerberos application; in fact, such characters are currently all
reserved for future assignment.  I don't think this is a problem.

> In the meantime, I am going to write based upon my comments above, Tom's
> comments in revisions, and Jeff's summary of a few days ago to this list
> an Informational I-D describing why we as a Working Group strongly
> recommend that all current implementations and deployments of Kerberos 5
> restrict themselves to US-ASCII.

<http://www.unicode.org/> has a lot of good information that you may want
to review before writing that I-D.  Quite a lot has changed since Unicode
2.0.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 12 Nov 2001 07:35:51 -0500

> are left in a fully decomposed state or not.)

And encoding normalization should be left to the clients, I think. That
way the KDCs and services can treat principal names pretty much as
strings of bytes that either match names in the KDB or in ACLs, or they
don't. And yes, if pattern matching is done, then there must be some
knowledge of UTF-8 in the pattern matching engine. And when logging and
so on the the names may need to be converting to a local locale...

As to the difference between NFKD and NFKC -- it probably makes little
difference from the point of view of the KDC or application services...
Could it be as simple as a coin-toss? :)

[...]

> robust against mis-entered names.

Whatever names can be represented in the various naming services should
be possible to represent in Kerberos. No?

[...]

> Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

---

From: Derek Atkins <[email-masked]>
Date: 12 Nov 2001 14:33:19 -0500

> so on the the names may need to be converting to a local locale...

This implies that the Kerberos Protocol must define the canoncial
format so that all clients and convert from the local format to
the Kerberos Canonical format before it creates a request or sends
it on the wire.  It doesn't reduce the amount of work that we
need to do; it just defines where the canonicalization is done.

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Russ Allbery <[email-masked]>
Date: 12 Nov 2001 13:15:11 -0800

Derek Atkins <[email-masked]> writes:

> This implies that the Kerberos Protocol must define the canoncial format
> so that all clients and convert from the local format to the Kerberos
> Canonical format before it creates a request or sends it on the wire.
> It doesn't reduce the amount of work that we need to do; it just defines
> where the canonicalization is done.

*nod*

This is also why, if at all possible, one doesn't want to get into the
business of defining one's own canonicalization.  DNS has to because DNS
is case-insensitive, and has extremely stringent demands from the
commercial sector for the reproducibility of hostnames (in other words,
someone has to be able to see a URL on the side of a bus, go type it into
their computer, and have it work).

For most other applications, the canonicalizations already defined by
Unicode should generally be sufficient.  The advantage of just using them
is that because they *are* part of Unicode, they're already widely
implemented in Unicode libraries and one doesn't have to write new
canonicalization code specifically for the application.

---

From: Derek Atkins <[email-masked]>
Date: 12 Nov 2001 17:07:46 -0500

Except that Kerberos has the same issues that DNS does -- when you
contact a host (by some name) you need to convert that to a canonical
name in order to authenticate to it...  Similarly for checking ACLs
or other uses; you need to be able to convert to a canonical format.

So I don't think we can just wash our hands of the problem.

-derek

---

From: Russ Allbery <[email-masked]>
Date: 12 Nov 2001 14:34:42 -0800

Derek Atkins <[email-masked]> writes:

> name in order to authenticate to it...  Similarly for checking ACLs or
> other uses; you need to be able to convert to a canonical format.

> So I don't think we can just wash our hands of the problem.

For hostnames, I think it's reasonably obvious that Kerberos should use
the same canonicalization methods as DNS, whatever they may be.  That
means that that part of the problem probably cannot be solved yet, as the
DNS canonicalization systems have not yet been finalized.  But using the
same method as DNS is probably necessary for hostnames and has obvious
advantages for realm names (although realm names are case-sensitive, which
complicates matters there).

For other, non-DNS data (like principals and passwords), unless I'm
missing some other significant issue, it seems to me that the choice is
between NFKD/NFKC (which seems to suit the application area the best) or
DNS (to avoid having to deal with more than one canonicalization system),
and the former makes the most sense to me (the DNS canonicalization system
seems likely to end up buried in the system resolver libraries anyway).

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 Nov 2001 09:58:28 -0500

> need to do; it just defines where the canonicalization is done.

Yes.

But it changes fewer assumptions about naming in the protocol (e.g.,
currently, unless the MS extension name canonicalization flag is given
the clients check to make sure the names in the responses match the
names in the requests).

And app servers also may want to convert from the canonical UTF-8 form
to a local form, even if the local form is UTF-8 (as in NFKD vs. NFKC).

And having the clients be responsible for name encoding
canonicalization should help produce new KDCs sooner.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 Nov 2001 10:06:15 -0500

Yes, but clients contacting services have usually already passwed the
service's hostname through the resolver. So we can get some of the
benefits of what the DNS folks are doing and stick to simple encoding
canonicalization.

There's still the MS name canonicalization stuff as well.

Great, now we'll have the term canonicalization refer to several
different things:

 - namespace normalization, as in the princ name canonicalization extension
 - character set encoding normalization
 - GSS-API gss_name_t canonicalization (a misnomer -- that function
   simply reduces the mech-specific names in a gss_name_t to 1)

:)

You seem to be advocating piggy-backing character set encoding
normalization on princ name canonicalization... Yes?

Nico

---

From: Martin Rex <[email-masked]>
Date: Tue, 13 Nov 2001 21:04:50 +0100 (MET)

> So I don't think we can just wash our hands of the problem.

Correct.

The API-side of the issues is much worse than the on-the-wire format
for Kerberos revisions.  Besides the native Kerberos API and
backwards compatiblity issues of new Kerberos implementations with
existing kerberized applications there is also the GSS-API.

Currently GSS-API is equally underspecified for non-ASCII as
regular Kerberos.  The API only knows "printable octet strings",
which is more likely a locale-specific 8-bit extension of ASCII
than any variant of Unicode.  My application codes uses
the local default 8-bit character set and my GSS-API v2 wrapper
for Microsoft's W2K Kerberos does the same (which AFAIK is
the MIT Kerberos tradition).

Now even when you get the interpretation of the Kerberos client,
server and KDCs in sync, what do you do about the application(s)?

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 13 Nov 2001 21:39:25 +0100 (MET)

> normalization on princ name canonicalization... Yes?

Your notion about GSS-API name canonicalization is (still) incorrect.

You're confusing a particular implementation of gss_canonicalize_name()
(probably the one in MIT Kerberos) with the actual abstraction of GSS-API
canonical names as defined by the GSS-API spec.

For the purposes of creating and efficiently checking ACLs by
applications that use the GSS-API the calls gss_canonicalize_name()
and gss_export_name() were added to the GSS-API v2 spec.

The requirement on gss_canonicalize_name() is to remove any
ambiguity from a gss_name_t that may be caused by a multi-component
name of a multi-mechanism with independent name-spaces.

The result of gss_export_name() is the creation of a binary blob
representing that canonical name so that it can be used to populate
an ACL.  (So that this ACL can later be efficiently searched with
the resulting src_name from a successful gss_accept_sec_context()).

Most (if not all) of the generic nametypes defined in rfc2743
(usernames, user-ids, hostbased service names) are not going
to be canonical for the majority of gssapi mechanisms (if they're
supported at all).  It is completely up to the gssapi mechanism
implementation at which point it maps any of these generic nametypes
(and any other nametypes created for user convenience) into
canonical representation -- i.e. into the mechanism-specific
namespace.  A gssapi mechanism implementation can do this
during either (or each) of the calls
gss_import_name(), gss_canonicalize_name(), gss_export_name().

MIT Kerberos gssapi used to (and probably still does) perform
canonicalization during gss_import_name(), but this is an
implementation detail.  The GSS-API v2 wrapper that I wrote for
Microsoft's W2K Kerberos does it during gss_canonicalize_name().

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 Nov 2001 16:56:22 -0500

> Your notion about GSS-API name canonicalization is (still) incorrect.

Well, RFC2744 is clear and in favor of your interpretation.

Whereas RFC2743 is less clear and says this:

"
   This routine reduces a GSS-API internal name input_name, which may
   in general contain elements corresponding to multiple mechanisms, to
   a mechanism-specific Mechanism Name (MN) output_name by applying the
   translations corresponding to the mechanism identified by
   mech_type.  The contents of input_name are unaffected by the
   GSS_Canonicalize_name() operation.  References to output_name will
   remain valid until output_name is released, independent of whether
   or not input_name is subsequently released.
"

I suppose the keyword here is "may" and so you're probably right that
this is implementation specific. *shrug*

> and gss_export_name() were added to the GSS-API v2 spec.

They also call gss_import_name().

> name of a multi-mechanism with independent name-spaces.

This makes that call a misnomer.

> gss_import_name(), gss_canonicalize_name(), gss_export_name().

Yes. I see that now. And you can see then that gss_canonicalize_name()
is misnamed.

> Microsoft's W2K Kerberos does it during gss_canonicalize_name().

Hmmm. Ok.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 Nov 2001 17:06:27 -0500

> existing kerberized applications there is also the GSS-API.

APIs will need to be revised, yes, at least where name inputs aren't
expected to be UTF-8 or some other Unicode form today.

> server and KDCs in sync, what do you do about the application(s)?

Well, given the CHOICE approach, not only will the Kerberos APIs need
revision but also old clients will not be able to reference Kerberos
principals whose names contain non-ASCII(*). So using the old APIs, one
would hope, would be akin to using a Kerberos implementation that cannot
cope with the new KerberosString and UTF-8String.

So, as long as you refrain from using non-ASCII names GSS-API is covered
and it continues to work fine :)

I wonder though, should there be a new OID for a new Kerberos GSS mech
for use with a UTF-8 capable Kerberos implementation? Probably not, no,
particularly if the Kerberos version itself is not revved.

But the GSS-API bindings will definitely need updating, as will the MIT
and Heimdal krb5 APIs. But only if you wish to use the new UTF-8
support in Kerberos (or some other GSS mech). RFC2744 specifically
references only one character encoding: Latin-1. So there's a
discrepancy between GSS and Kerberos V *now* anyways.

(*) again, except where old clients are doing the wrong thing wrt
GeneralString).

How does your GSS-APIv2 library for Win2k handle character set encoding?
Does it work with UTF-8? Is that not in violation of RFC2744?

> -Martin

Cheers,

Nico

---

From: Martin Rex <[email-masked]>
Date: Tue, 13 Nov 2001 23:57:29 +0100 (MET)

> cope with the new KerberosString and UTF-8String.

So you would propose to add new (native Kerberos) API calls that
support UTF8.  This would *not* break old code.  Good idea; I like it!

> and it continues to work fine :)

Which is the current situation.

> (*) again, except where old clients are doing the wrong thing wrt

It's funny -- now that you mention the OIDs: it should be possible
to extend GSS-API to Unicode by adding seperate nametype OIDs that
indicate UTF-8 encoding.

This change would still require update to the representation of
exported names and make these non-interchangeable with existing
implementations of rfc1964.  New kerberos gssapi mechanisms
returning GSS_C_NT_KRB5_PRINCIPAL_NAME_UTF8 from gss_display_name()
might also be confusing existing applications (it would certainly
cause our application to reject such a Kerberos mechanism).

> Does it work with UTF-8? Is that not in violation of RFC2744?

As I said, it doesn't.  It uses the ASCII-calls of SSPI, not the
Unicode calls -- so all translation is actually a local matter
of W2K... (I've never tested how/whether that works and I don't have
high hopes -- Microsoft has reliably broken support for non-ASCII
chars in the ASCII-variants of the calls when passing Names
to and from the NTLM SSP).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 14 Nov 2001 00:31:43 +0100 (MET)

> Yes. I see that now. And you can see then that gss_canonicalize_name()

I don't think so.

The name of the call is *not* meant to specify the exact operation that
a gssapi mechanism implementation will have to perform.  The names of the
GSS-API calls are primarily for use by applications.  And for the purpose
of the application it is the canonicalization of a name for a
particular mechanism that is **requested**.

When an application wants to populate a binary ACL and starts off
with user/admin-supplied printable names, then the app must call
gss_canonicalize_name() with a specific mechanism OID after
gss_import_name() and prior to gss_export_name() or else this will
not work portably across gssapi mechanisms.

Authenticated names returned as src_name from successful
gss_accept_sec_context() do *not* need to be passed to
gss_canonicalize_name() prior to gss_export_name().
Depending on the nature of the mechanism-specific canonicalization
operation (e.g. lookup/translation in a central directory), not
having to go through a repeated canonicalization might have
a significant performance impact on a server process!

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 14 Nov 2001 09:42:40 -0500

Yes.

[...]

> to extend GSS-API to Unicode by adding seperate nametype OIDs that

No, I don't think new OIDs are needed for the Kerberos mech unless the
Kerberos version is revved. Since GSS-API would need a revision to
handle UTF-8 names the thing that would determine whether an app uses
the Kerberos-with-ASCII-only mech or the Kerberos-with-UTF-8 mech would
be the GSS API used by the app.

Consider what might happen if the competing proposal of adding elements
to the various SEQUENCEs as needed to send ASCII and UTF-8 names in
parallel is adopted over the CHOICE proposal. Then there'd be no need to
rev the Kerberos protocol version number, and that might not be done
even if the CHOICE approach is taken. But could such a change justify a
new Kerberos mech OID? even though GSS would know whether the app can
handle UTF-8?

No, no new OID, methinks.

> cause our application to reject such a Kerberos mechanism).

Yes, the APIs need revision, or their documentation does, for, wherever
(unsigned char *) is used you can easily change the docs to say the
encoding must be UTF-8 :)   ... a way would still be necessary to
indicate to the library that you mean to use UTF-8 though, and that
would leave all cahracter set conversions to the caller.

New APIs, otoh, could have forms that take local locale encoded char
and/or wchar strings, and forms that take ASCII only and forms that take
UTF-8 char strings. I think that would be preferable.

[...]

Cheers,

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 14 Nov 2001 11:39:10 -0500 (EST)

> regular Kerberos.  The API only knows "printable octet strings",

Yes, the GSSAPI C language bindings are underspecified in this respect.
This is an example of why the IETF should really stay out of the business
of defining API's, and stick to wire protocols.

> the MIT Kerberos tradition).

The interface exported by your GSSAPI library doesn't have to change.  The
Kerberos V5 mechanism code simply has to perform the appropriate
conversion.  A similar situation holds for applications that use Kerberos
directly -- the Kerberos library API must specify the encoding to be used
for strings, and convert to/from that as needed. 

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA