Subject: RE: Status update for Kerberos Revisions

From: "John Brezak" <[email-masked]>
Date: Tue, 20 Nov 2001 10:58:08 -0800

below - [JBrezak]

-----Original Message-----
From: Tom Yu [mailto:[email-masked]] 
Sent: Tuesday, November 20, 2001 10:49 AM
To: John Brezak
Cc: [email-masked]; [email-masked]
Subject: Re: Status update for Kerberos Revisions

>>>>> "John" == John Brezak <[email-masked]> writes:

John> [JBrezak] GeneralString can contain any character set as long as 
John> it is properly escaped. The "properly escaped" is the part that 
John> many people have missed in many places even outside of Kerberos. 
John> In fact many protocols have stayed away from GeneralString just 
John> because of this.  GeneralString can contain UTF-8 characters as 
John> long as they are prefixed with the correct escape sequence.

It may not.  The definition of GeneralString in Clause 36, Table 3 of
X.680(1997) defines GeneralString to include "All G and C sets + SPACE
+ DELETE".  Nowhere does it say anything about encoding outside of ISO
2022.  UTF-8 isn't a G set or a C set.  It is a completely different
encoding.  Furthermore Clause 8.20.5.1 of X.690(1997) specifies that "An
escape sequence shall not be used unless it is one of those specified by
the registrations numbers used to define the character string type in
ITU-T Rec. X.680|ISO/IEC 8824-1".  I interpret this to exclude escapes
to other encoding schemes.  UTF-8 isn't an ISO 2022 character set; it is
a completely different encoding from ISO 2022.

[JBrezak] There is a registered UTF-8 escape sequence at
http://www.itscj.ipsj.or.jp/ISO-IR/196.pdf . ISO 10646 is the equiv to
ISO 2022 for Unicode.

John> But these escaping rules require you to sift through many 
John> different specs between many different standards bodies. The 
John> escaping of GeneralStrings doesn't seem to be an issue with the 
John> ASN.1 package we are using, it doesn't deal with it. You need to 
John> present to it the correct string and it tags and packs it. However

John> that is an implementation detail.

There is a registry of character sets that is centrally maintained,
along with the escape sequences.  The framework for the escape sequences
is specified in ISO 2022.

It seems that your ASN.1 package has the same problem as the MIT
implementation does, which is that it will believe your assertion that
the string you feed it is correct for it to encode bit-for-bit as the
selected type.

[JBrezak] Correct.

John> [JBrezak] Unicode is used in the string2key function for RC4-HMAC 
John> only.  For DES, the input form is not specified in 1510.

I seem to recall that the encoding of the Unicode isn't specified.  Is
it UTF-8?

[JBrezak] Unicode with 16-bit characters is specified in the RC4-HMAC
I-D.

---Tom

---

From: Tom Yu <[email-masked]>
Date: 20 Nov 2001 14:17:48 -0500

>>>>> "John" == John Brezak <[email-masked]> writes:

John> [JBrezak] There is a registered UTF-8 escape sequence at
John> http://www.itscj.ipsj.or.jp/ISO-IR/196.pdf . ISO 10646 is the equiv to
John> ISO 2022 for Unicode.

Nowhere in the registry does it say that UTF-8 is a "G" set -- a
graphic character set.  It is a coding system that is *not* ISO 2022,
and by my reading of the ASN.1 standard, is not permitted to be
present in GeneralString.

John> [JBrezak] Unicode with 16-bit characters is specified in the RC4-HMAC
John> I-D.

Hm... I was thinking of a previous iteration of the I-D that didn't
specify it, then.

---Tom