Subject: RE: Status update for Kerberos Revisions

From: "John Brezak" <[email-masked]>
Date: Wed, 14 Nov 2001 09:19:19 -0800

It is not acceptable to call a very large number of existing users
"cheaters". Since there are existing realms using GeneralString with the
UTF-8 Unicode character set, this should be accomodated. There is no
easy way to get these converted without regard to _both_ forward and
backward compatibility.

I'd propose a change that would recognize that implementations prior to
1510bis can represent GeneralStrings encoded as UTF-8 characters in the
unicode character set. If a KDC or server is unable to convert from this
and is restricted to the ASCII character set, then they should return a
KRB-ERR-GENERAL-STRING (or something like that).

Otherwise moving forward with the "CHOICE" proposal seems acceptable as
long as there are no objections to the use of the ASN.1 CHOICE
construct.

-----Original Message-----
From: Clifford Neuman [mailto:[email-masked]] 
Sent: Tuesday, November 13, 2001 11:22 PM
To: [email-masked]
Subject: Status update for Kerberos Revisions

This is an update on the status of remaining tasks on Kerberos
revisions.  In my message of November 5th I listed:

 . Internationalization (specifically  UTF-8)
 . Section 5
 . Section 6
 . Appendices

as the open issues.  Taking these in turn - 

  Internationalization:

    We have seen lots of discussion of UTF-8 off the list, and then
    discussion moved to this list.  See Jeffrey Hutzelman's message of
    November 9th for a summary of the issues.  It looks like most are
    in favor of option (3) from Jeff's message, and I concur.  There
    are several details to be work out regarding this issue and until
    the full UTF issues are worked out, this option might only work
    for those realms using only US-ASCII, but it can provide a way to
    ensure backwards compatability and with appropriate limitations
    can probably provide forward compatability as well (realms
    currently cheating to use other than US-ASCII might have to defer
    on updating to this spec until the rest of the UTF 8 issues are
    addressed - i.e. their cheating while otherwise using the new spec
    would present forward compatibility problems). 

    I propose the group quickly come to consense to go forward with
    option 3, and hopefully Tom can use this consensis as a basis for
    his section 6 revisions.

  Sections 5 and 6

    Tom Yu is working on these.  A few of the pieces of the changes to
    5 relevant to the discussion above has come across the list, but I
    am still waiting for an update.

  Appendices

    I am in the process of going over the existing appendices and I am
    waiting for other appendices from Ken.  I had an offer of
    pseudocode from one vendors validation suite which I have not
    received, and will be following up on that.

Action items for the list:

  Doug, can you take consensus on the UTF 8 issue, and if consensus is
  for 3, then Jeff, can you give us an applicability statement -
  i.e. that this works in which situations, and what limitations must
  be imposed on the use of this option until the full set of UTF-8
  international issues are worked out, and then Tom, can you proceed
  on 5 under these assumptions?

Clifford Neuman

---

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

> easy way to get these converted without regard to _both_ forward and

It is worth noting that these existing users (admittedly through no fault
of their own) are doing something not permitted by RFC1510.  So are the
people who are using unescaped ISO-8859 or other native encodings. 
Nonetheless, the focus here is on interoperability, not on punishing
people who have existing nonstandard installations.  So, we will do the
best we can to support these users.

> KRB-ERR-GENERAL-STRING (or something like that).

On the contrary, while 1510bis should recognize that there are existing
implemenations which encode GeneralStrings containing other than US-ASCII,
it should _not_ describe what these possible encodings are or provide
recommendations on their use.  The Microsoft UTF-8 behaviour is not the
only possible interpretation of non-US-ASCII in a GeneralString, and we
should not assume that it is.  Please also see my original posting in this
thread, in which I relayed specific advice from a IESG member that the
semantics of non-US-ASCII GeneralStrings remain unspecified.

There really is no need for a new error message, either.  New
implemenations should always be using UTF-8 to talk to each other, so one
new implementation will never send your KRB-ERR-GENERAL-STRING to another. 
An old implementation will certainly never send that error, and will be
unable to interpret the error if it receives one.  Not all cases where
this may happen have a clear error path, and even when there is one, it
may not be authenticated. 

New implementations may certainly send UTF-8 or whatever other garbage
they want in a GeneralString in order to interoperate with an old
implementation.  But that will only work if the guess about what the other
side is expecting is correct, just as today.

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