Subject: Re: IDNA encoding for Kerberos host names

From: Ienup Sung <[email-masked]>
Date: Wed, 08 Oct 2003 12:46:44 -0700 (PDT)

Hello everyone,

I quite recently joined the working group and I'm concerning about
the IDNA RFCs and the upcoming(?) extensions to the Kerberos, esp., on
the compatibility.

I'm still reading the email archives and it will take some more time for
me to finish reading and at leat have some background idea on what has been
discussed and also what are the general agreements on the issues but
if it has not been completed (it looks that way), I would like to propose to
work on IDNA compatibility issues, e.g., IDNA's ACE names and principals/realms,
proper Stringpreps.

I also would like to point out that the most important thing in my opinion
is the compatibility with the IDNA and not on how should the IDNA be implemented
since putting IDN with 8-bit characters <-> IDN ASCII Compatible Encoding (ACE)
at the resolver isn't the 100% all of the story since there are many
applications that need to deal with files and other entities that wouldn't be
ready for IDN with 8-bit characters (or, UTF-8 for that matter) in addition to
the backward compatibility with existing protocols and infrastructures.

With regards,

Ienup

---

From: Sam Hartman <[email-masked]>
Date: Wed, 08 Oct 2003 21:11:03 -0400

>>>>> "Ienup" == Ienup Sung <[email-masked]> writes:

    Ienup> Hello everyone, I quite recently joined the working group
    Ienup> and I'm concerning about the IDNA RFCs and the upcoming(?)
    Ienup> extensions to the Kerberos, esp., on the compatibility.

    Ienup> I'm still reading the email archives and it will take some
    Ienup> more time for me to finish reading and at leat have some
    Ienup> background idea on what has been discussed and also what
    Ienup> are the general agreements on the issues but if it has not
    Ienup> been completed (it looks that way), I would like to propose
    Ienup> to work on IDNA compatibility issues, e.g., IDNA's ACE
    Ienup> names and principals/realms, proper Stringpreps.

Hi.  To avoid opening a can of worms I'll try and summarize things
that we seemed to have already decided for you.  You can attempt to
reopen some of these discussions but you will need a strong reason for
doing so and will probably face significant opposition.  My summary of
what decisions have been made is not authoritative; the working group
chair judges consensus.  Hopefully Doug will chime in if he thinks
I've gotten something wrong.

We've decided that we will use the saslprep stringprep profile.  That
profile can be found in draft-ietf-sasl-saslprep.  This is not the
same as the nameprep profile.  Examples of why this is necessary
include the fact that Kerberos principals are case sensitive and that
Kerberos principals can contain the ascii dot character, which is
excluded by nameprep.  Remember domain names are split up intolabels;
Kerberos principals are not.

We've decided that Kerberos clarifications will only officially
support US ASCII.  Several implementations support other character
sets in proprietary manners.  For example Microsoft just sends UTF8.
If I had to do internationalization with Kerberos today, I'd send UTF8
using the saslprep profile.  The IETF will not standardize this
solution.

We've decided that Kerberos extensions will send UTF8 using the
saslprep profile for strings that are queries or stored in databases
and will send unnormalized UTF8 for error messages and other text
strings intended for display.

We are in the middle of a discussion that seems to be reaffirming the
consensus that we will not use IDNA's encoding anywhere in the
Kerberos protocol.  Several of us seemed to believe that we had
already made this decision a while back, but reaffirming the consensus
seemed easier than finding the appropriate minutes.  You can look at
the archives for the last week to see the reasoning why we believe
this is the right decision.  This issue is probably still technically
open, but you'd need to come up with responses to the points already
raised that were sufficient to convince people you were right.

Hope this helps you.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 09 Oct 2003 11:29:00 -0500

> I've gotten something wrong.

No, you have it right, The statements below are a good summary of the
consensus.  

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444