From: [email-masked]
Date: Mon, 28 Oct 2002 08:58:03 -0600 (CST)

2.1) with ESMTP id PAA13345 for <[email-masked]>; Fri, 25 Oct 2002 15:17:47 -0700
(MST)]
Received: [from ca25exm01.GI.COM (ca25exm01.gi.com [168.84.84.121]) by pobox3.mot.com
(MOT-pobox3 2.0) with ESMTP id PAA20257 for <[email-masked]>; Fri, 25 Oct 2002 15:14:11
-0700 (MST)]
From: Medvinsky Alexander-MGI1174 <[email-masked]>
To: "'Sam Hartman'" <[email-masked]>, Matt Hur <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: pkinit and internationalization
Date: Fri, 25 Oct 2002 15:17:37 -0700
Sender: [email-masked]

Sam,

My replies are in-line below.

Regards,

Sasha.

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]]
Sent: Friday, October 11, 2002 8:55 PM
To: Matt Hur
Cc: Alexander Medvinsky; [email-masked]; [email-masked]; [email-masked]
Subject: pkinit and internationalization

It would be useful if pkinit authors could read both of Jeff Altman's
internationalization drafts (the stringprep profile and
info-gen-ascii) and be prepared to discuss the following issues:

1) Are there  any strings we cannot normalize?  An example of this
   would be a hash of a string provided in some cert or other object
   that did not also provide the string.  This issue would mostly come
   up with keys entered directly by users.  I believe the answer is
   that there are no such strings in pkinit but it's important to make
   sure  because we have a lot of work if there are.

[sasha] I believe not.

2)  Are there cases where we're going to have to give
    explicit instructions   about normalization?  For example are
    there any strings  from non-Kerberos entities that cannot be
    normalized because they are in signed data, but instead must be
    normalized both by the client and KDC?  I suspect yes there are
    several of these in certs.

[sasha] Yes.  The one case is the method of conversion of an X.500 name into a Kerberos
principal name (or realm) defined by PKINIT.  This references RFC 2253, where RFC 2253
converts an X.500 string into a UTF8 string.  RFC 2253 says:

	"If the UTF-8 string does not have any of the following characters
   	which need escaping, then that string can be used as the string
   	representation of the value.

    	o   a space or "#" character occurring at the beginning of the
          string
    	o   a space character occurring at the end of the string
    	o   one of the characters ",", "+", """, "\", "<", ">" or ";"

   	Implementations MAY escape other characters.

   	If a character to be escaped is one of the list shown above, then it
   	is prefixed by a backslash ('\' ASCII 92).  

	Otherwise the character to be escaped is replaced by a backslash and
   	two hex digits, which form a single byte in the code of the
   	character."

This looks to be a problem because the statement "implementations MAY escape other
characters" makes this conversion non-unique (may result in many possible principal names). 
I believe that we should add to the PKINIT draft that all non-printable characters that
cannot be used directly within GeneralString (without an escape sequence) must be escaped as
defined by RFC 2253 (as part of the conversion to a principal name).  Special characters
identified by RFC 2253 must also be escaped.  All other characters must not be escaped. 
This would make the conversion result in a unique principal name that can be directly
converted into a GeneralString.

3) Are there any strings that should not be normalized?  I can't think
   of any such  but there might be copies of items from certs where
   having the string be bit-for-bit identical is more important than
   normalization.

[sasha] I believe not.

4)  Are there any strings that are stored in the database?
    Identifying these strings will matter because the handling of
    unspecified codepoints is different for stored strings than for
    query strings.

[sasha] X.500 names, after they are converted to a principal name, could be stored in a
database or an ACL.  But once they are converted to a principal name, their representation
in the database or ACL would follow the same rules as for all principal names - so I don't
think that anything needs to be added to the PKINIT draft on this point.

Sasha.