Subject: RE: Status update for Kerberos Revisions

From: Jeffrey Altman <[email-masked]>
Date: Tue, 20 Nov 2001 23:54:04 EST

> 
> This is what I was saying and arguing for two years ago.  But it does
> not apply here.   ASN/1 GeneralString does not permit any ISO-2022
> escape to be used.  It only permits a restricted subset of ISO-2022 to
> be used.  That restriction limts the allowed character-sets are limited
> to those 94-character sets which can be stored in G0 or C0. This rules
> out all of the ISO-8859 setsass well as all those which can be accessed
> via escapes to non-ISO-2022 character-sets.
> 
> [JBrezak] Wow - how could we have missed this... 
> So we are back to 2 proposals:

John, I am glad we are now all on the same page.
 
> 1) Your I-D with CHOICE:
>
> KerberosString ::= CHOICE {
>                               general GeneralString (VisibleString),
>                               utf8 UTF8String
>          }
> 
> For reference the class identitifiers are 27 for GeneralString and 12
> for UTF8String.
> 
> Does UTF8String need to have constraints - I see that UniversalString
> requires constraints.

This is part of what we have to figure out.  There may also be an
issue with the ordering of the fields.  I came across at least one
reference that implied that the fields must be listed in the CHOICE in
increasing numerical order based upon type.  However, it was unclear
if this applied to the Extensible version of CHOICE or not.

> 2) Paul's proposal to just live with it and step back from formal ASN.1.
> 
> We need to weigh the needs of compatibility vs. strict standards
> conformance. Again this was brought up in Minneapolis with the 5.1 vs.
> 5.2 proposal where just the minimum was to be added to 5.1 for the new
> required features (this would be kerberos-revisions) and a new effort
> with ASN.1 cleanup and such would be termed 5.1, which probably would
> become Kerberos version 6.

I am very reluctant to play a semantic game of we are ASN.1, no we
aren't, yes we are.  Writing ASN.1 parsers is hard enough without
needed to maintain special hacked versions.  

As long as we have a mechanism for determining which version of the
message is being used there is little reason to not go with the CHOICE
implementation.  We simply have to document the possible scenarios as
Paul started to do in another message in this thread.

Everyone have a wonderful Thanksgiving.  I know several are leaving
tonight.  We can pick this up again next week.

- Jeff

 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: Tom Yu <[email-masked]>
Date: 21 Nov 2001 10:59:23 -0500

>>>>> "jaltman" == Jeffrey Altman <[email-masked]> writes:

jaltman> There may also be an issue with the ordering of the fields.
jaltman> I came across at least one reference that implied that the
jaltman> fields must be listed in the CHOICE in increasing numerical
jaltman> order based upon type.  However, it was unclear if this
jaltman> applied to the Extensible version of CHOICE or not.

I've looked at it.  Don't worry about it.  The extensions alternatives
to an extensible CHOICE must have canonical tag order higher than the
preceding alternatives.  This can be satisfied by putting additional
tagging in where necessary, but we need to remember to do so.

---Tom