Subject: Re: [Fwd: Re: Kerberos Revisions and UTF8]

From: Jeffrey Altman <[email-masked]>
Date: Wed, 8 Aug 2001 9:52:13 EDT

Harald's comments bring us right back to the discussion we had in
Pittsburgh.  All implementations use GeneralString as a series of
Octets and not ISO-2022 encoded strings.  This means that for all
implementations other than Microsoft's we can claim that they adhere
to the standard when only ASCII strings are used.

The problem that raised the issue in the first place was the fact that
Microsoft uses unescaped UTF-8 strings.  The escape sequence which
Harald refers to is  "UTF-8 with standard return"

  ESC % G

This is a non-trivial matter because regardless of what we do to
remain standards compliant we are going to be in a situation where 
Microsoft's implementation breaks the rules.  That is why we discussed
doing one of two things in Pittsburgh.  

 . Stick with GeneralString but break the rules for its use and
   require unescaped UTF8

 . Stick with GeneralString but break the rules for its use by
   treating it as an OctetString.  This requires we punt on the
   character set issue and come up with some other means for
   specifying what character set is used by various parties to 
   the message exchanges.

As things stand now I would place the requirement in Revisions that
the GeneralString be used without escapes and that its use be
restricted to ASCII.  That is the only thing that we know is currently
compatible.  This still leaves Microsoft in non-compliance.  But I
don't see how we are going to maintain compatibility.

> Directions on the use of UTF8
> 
> -------- Original Message --------
> Subject: Re: Kerberos Revisions and UTF8
> Date: Wed, 08 Aug 2001 13:53:49 +0100
> From: Harald Tveit Alvestrand <[email-masked]>
> To: "Douglas E. Engert" <[email-masked]>
> References: <[email-masked]>
> 
> 
> 
> --On 8. august 2001 04:02 -0500 "Douglas E. Engert" <[email-masked]> 
> wrote:
> 
> > RFC 1510 used GeneralString, but all of the implementations in effect
> > treat this  as a ASCI string, or a locale string type. We have been
> > looking at the problems which would arise if this was changed to UTF8,
> > and there are many. (If need be I can get you  a list from those who
> > understand the issues better then I) We know that this must be
> > addressed, but would like to address this as a separated document from
> > the revisions as listed above.
> 
> The GeneralString is a troublesome ASN.1 type in many ways, most of all 
> because it can be used to represent ANY string that can be encoded using 
> ISO 2022 code page switching.
> And, as you say, it has been abused in many different ways; RFC 1502 gives 
> a brief guide to how one should abuse it in a standards conformant manner.
> 
> I think you can take it as given that if the revised document does NOT 
> outlaw totally the use of national character sets without the appropriate 
> escape sequences, this will cause the IESG to object severely to the 
> specification; this is a violation of RFC 2277, ASN.1 and common sense, and 
> can never be made to function interoperably on a global scale.
> (feel free to quote me on that, BTW!)
> 
> For a permanent solution: If the working group takes either of the paths of
> 
> - Switching to ASN.1(92?) and using a CHOICE(UTF8STRING), with a clear 
> preference for using it, just like PKIX did
> - Continuing to use GeneralString, but insist that the only permitted (or 
> at least strongly preferred) escape sequence is the one for UTF-8
> 
> there is reasonable hope to go forward.
> 
> Note that the use of wide character sets in identifiers has LOTS of funny 
> issues, many of which have been hashed over ad nauseam in the IDN group; 
> you will want to consult the IDN group's requirements and NAMEPREP 
> documents before locking yourself to an approach.
> 
> Good luck!
> 
>                   Harald
> 

 Jeffrey Altman * Sr.Software Designer      C-Kermit 8.0 Beta available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to follow.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 8 Aug 2001 10:35:28 -0400

Can't UTF-8 and ASCII co-exist?

I.e., if a string contains only ASCII characters then it should be
interpreted as being ASCII, whereas if a string contains any octets
with the high bit set then it should be interpreted as being UTF-8.

Isn't a UTF-8 string containing no octects with the high bit set the
same as an ASCII string consisting of the same octects?

Pardon my ignorance of UTF-8...

Nico
--
. 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.