Subject: Re: IDNA encoding for Kerberos host names

From: Ienup Sung <[email-masked]>
Date: Thu, 09 Oct 2003 13:01:08 -0700 (PDT)

Sure. One of the examples below.

The SASLprep does not use B.2 or B.3 of the Stringprep. The B.2 and the B.3
are case folding mappings, the former to be used with Normalization and
the latter to be used with no normalization. And yet the SASLprep does
Normalization KC (a.k.a. into NFKC).

In the IDNA/Nameprep, the Normalization with NFKC and the Case Folding B.2
go together as intended, i.e., in the IDNA/Nameprep, the following will be
done for a character 'a':

	b = NormalizeWithKC(Fold(a));
	c = NormalizeWithKC(Fold(b));
	if c is not the same as b, add a mapping for "a to c".

where such 'a' characters exist and are from some Greek characters and many
symbols that contain Latin characters (of the Unicode).

The SASLprep's sans-Fold() wouldn't be yielding the same mapping table.

Hence the domain style names between the IDNA applications and the Kerberos
principal names/realms loose compatibility/interchangeability/transitivity.

With regards,

Ienup

] Date: Thu, 09 Oct 2003 15:35:55 -0400
] From: Sam Hartman <[email-masked]>
] Subject: Re: IDNA encoding for Kerberos host names
] To: Ienup Sung <[email-masked]>
] Cc: [email-masked]
] MIME-version: 1.0
] 
] >>>>> "Ienup" == Ienup Sung <[email-masked]> writes:
] 
]     Ienup> Actually I did a comparison between the SASLprep and the
]     Ienup> Nameprep (a Stringprep profile used in the IDNA as you
]     Ienup> know) a few days ago and found those two are not
]     Ienup> compatible.
] 
] Can you describe some real-world problems we would run into with
] saslprep that we don't already have with case sensitive domain
] components in principals?
] 
]

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 09 Oct 2003 16:09:50 -0400

These differences are necessary because the use of strings in Kerberos 
are case sensitive
and strings in DNS are case insensitive.   Kerberos strings also allow 
the use of ' ' and
'.' which are not permitted in DNS.  There are also differences in the 
use of C0 controls.

These distinctions have absolutely nothing to due with 
internationalization.  It is just
as true in an ASCII-only world as an internationalized world that DNS 
strings and
Kerberos strings cannot be arbitrarily mapped from one to the other. 

It is for exactly this reason that there are restrictions on the types 
of REALM and host
names which can be used within Kerberos if DNS TXT and DNS SRV records 
are to be used
to for distributing Kerberos REALM configuration information.

Jeffrey Altman

---

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Oct 2003 16:22:30 -0400

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

    Ienup> Sure. One of the examples below.  The SASLprep does not use
    Ienup> B.2 or B.3 of the Stringprep. The B.2 and the B.3 are case
    Ienup> folding mappings, the former to be used with Normalization
    Ienup> and the latter to be used with no normalization. And yet
    Ienup> the SASLprep does Normalization KC (a.k.a. into NFKC).

Again, I repeat my question.  Please provide an an example where
things will break with saslprep and they do not break today.  We do
not have case folding today and DNS does.  Thus the example involving
case folding is not appropriate because Kerberos with only ASCII
already has the problem you describe.

Still waiting to see what you believe is wrong with saslprep.