Subject: RE: Status update for Kerberos Revisions

From: Jeffrey Altman <[email-masked]>
Date: Mon, 19 Nov 2001 13:04:01 EST

> John, the whole point of the draft is that you cannot place Unicode
> characters into GeneralStrings.  GeneralStrings are only allowed to
> store characters from ISO-646 compliant character sets.  There is no 
> method for placing any form of Unicode in these strings.  If there were,
> we would not be in such a bind and I would not need to publish an
> Informational draft stating
> 
>   DO NOT USE ANYTHING OTHER THAN 7-BIT ASCII FOR ANY FORM OF 
>   DATA ENTRY.  NOT NAMES, NOT PASSWORDS, ...
> 
> [JBrezak] Sorry, but that will not work for thousands of existing
> deployed customers. I do not see where Unicode is explicitly prohibited.

Are you looking at RFC 1510 or the ASN.1 specification?
Its not in RFC 1510.  It is in the definition of GeneralString from
ASN.1.  

Tom: can you provide an online reference to the definition of
GeneralString in the ASN.1 specs?

> Which may also be a problem.
> 
> [JBrezak] The RC4-HMAC isn't a problem. However the DES ones are. Can
> you add a section with recommendations on how to properly encode a
> character string for input to the String2Key functions?

Its not appropriate for my draft.  This information is being placed
into Revisions.

> We have already been told by the powers that be that we may not ignore
> the definition of GeneralString as per ASN.1.  The IESG and the ITU will
> now allow it.  Back at Pittsburgh when this problem was first recognized
> that is the path ath Tom, Jeff, Ken and I wanted to pursue.  It was not
> accepted.
> 
> [JBrezak] We need to separate what needs to be done with existing
> implementations and then how to fix the Kerberos standard. There needs
> to be a realization that what is needs to continue to work for all
> customers, anything else will be unacceptable regardless of the
> political implications.

The reason we are going with the proposal to replace the use of 
GeneralString with a KerberosString which defines a CHOICE of
GeneralString or UTF8String is to allow current implementations to
continue to work without change.  The DER encoding of this CHOICE
should be identical to the current abused use of the GeneralString.

Just FYI, Kerberos is not the only protocol which has been bitten by
the GeneralString problem.  The original specification was so
underspecified that GeneralString is now to be avoided at all costs.
UniversalString or BMPString should be used instead.

 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: Martin Rex <[email-masked]>
Date: Tue, 20 Nov 2001 19:09:05 +0100 (MET)

> GeneralString in the ASN.1 specs?

John's lack of understanding of ASN.1 is what *SCARES* me each time
that I see an I-D that he (co-)authored containing loads of ASN.1.

It would probably be a good idea and save us all a lot of headaches
in the IETF if we required an ASN.1 drivers license for document
authors that use ASN.1!

-Martin