Subject: Re: Differences between Kerbeors revisions and PKINIT

From: Jeffrey Altman <[email-masked]>
Date: Mon, 31 Jul 2000 17:01:18 EDT

> >>>>> "deengert" == Douglas E Engert <[email-masked]> writes:
> 
> deengert> I have a question: PKINIT defines CertPrincipalName using
> deengert> UTF8String when the Revisions and 1510 defines PrincipalName
> deengert> using GeneralString. Both of these contian the same
> deengert> information. This looks like it was done on purpose, can
> deengert> someone explain why?
> 
> GeneralString is a mistake.  It should never have been in the base
> Kerberos spec but there was no UTF8String defined in ASN.1 originally.
> GeneralString is seven or eight bit characters with shift encodings as
> per ISO 2022 I believe, which is really hideous to handle properly.
> There's been a sort of agreement to treat everything that's tagged
> GeneralString in Kerberos as actually being UTFString.  I don't know
> offhand whether this causes problems with any ASN.1 compilers though.

FYI:

Following ISO2022 rules, to switch to UTF8 encoding insert the control
string

  <ESC> % G

This is UTF8 encoding with standard return.  To return to ISO2022
rules insert the control string

  <ESC> % @

                  Jeffrey Altman * Sr.Software Designer
                 The Kermit Project * Columbia University
               612 West 115th St * New York, NY * 10025 * USA
     http://www.kermit-project.org/ * [email-masked]

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 31 Jul 2000 16:06:44 -0500

So should the Kerberos revisions be changed, to accept either GeneralString
but define UTF8String? Does PKINIT need to define a separate CertPrincipalName
just to get around this problem? 

If not, the "agreement" should at least be documented. 

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Tom Yu <[email-masked]>
Date: 02 Aug 2000 13:29:27 -0400

>>>>> "tlyu" == Tom Yu <[email-masked]> writes:

tlyu> Yet another possibility is Jeffrey Altman's suggestion of using
tlyu> the ISO2022 escape sequence to change to UTF-8 encoding while
tlyu> using GeneralString.  This has the advantage that it conforms to
tlyu> ASN.1 fully, as far as I can tell.

Upon further reflection, this may not actually work out, since
GeneralString is supposed to accomodate "All G and all C sets + SPACE
+ DELETE", and it's not clear that a non-ISO2022 encoding counts as a
G set.  This is not really made clear in the ASN.1 spec or in ISO
2022.

---Tom

---

From: "Theodore Ts'o" <[email-masked]>
Date: Wed, 2 Aug 2000 14:27:37 -0400

From: Tom Yu <[email-masked]>
   Date: 02 Aug 2000 13:29:27 -0400

The problem with using the ISO2022 escape sequence is that we have to
worry about all of the headaches associated with someone who has a
principal name which might include an escape character; this brings up
interesting canonicalization and comparison headaches.  So we either
need to escape the escape the escape sequence, or prohibit the escape
character altogether, etc. 

I would strongly suggest that we just state that we use the ASN.1
General String type, but that the encoding is just treated as an UTF-8
string.  I wouldn't be surprised if ISO lawyers will rise in protest and
perhaps write flaming letters to the IAB/IETF, but I really think it's
the best way to go.  My perspective on this is basically that the ASN.1
encoding should serve(*) Kerberos, and that Kerberos doesn't exist to
worship the ASN.1 spec.

(*) And when I use "serve", I don't mean in the farm animal sense.

						- Ted

---

From: "Douglas E. Engert" <[email-masked]>
Date: Wed, 02 Aug 2000 13:32:05 -0500

I agree, state that the use of GeneralString was in error, is left
for compatablity, and it should be treated as a UTF-8. 

--

---

From: Tom Yu <[email-masked]>
Date: 02 Aug 2000 14:41:44 -0400

>>>>> "tytso" == Theodore Ts'o <[email-masked]> writes:

tytso> The problem with using the ISO2022 escape sequence is that we
tytso> have to worry about all of the headaches associated with
tytso> someone who has a principal name which might include an escape
tytso> character; this brings up interesting canonicalization and
tytso> comparison headaches.  So we either need to escape the escape
tytso> the escape sequence, or prohibit the escape character
tytso> altogether, etc.

The C0 and C1 parts of a character encoding aren't supposed to be used
by applications.  Certainly the ESCAPE character is not generally
supposed to be used except in well-defined ways either.  What
situations can you come up with where someone has an escape sequence
in their principal name?  Or control characters for that matter?

tytso> I would strongly suggest that we just state that we use the
tytso> ASN.1 General String type, but that the encoding is just
tytso> treated as an UTF-8 string.  I wouldn't be surprised if ISO
tytso> lawyers will rise in protest and perhaps write flaming letters
tytso> to the IAB/IETF, but I really think it's the best way to go.

The main issue here is really how do existing ASN.1 tools handle this,
and whether they will accomodate egregious lying of this sort.

And if the ISO and ITU flame at the IAB/IETF about this, we can turn
around and say that it would have been far less likely to happen if
the relevant documents were available on the net free of charge. :-)

---Tom

---

From: Tom Yu <[email-masked]>
Date: 01 Aug 2000 22:45:59 -0400

>>>>> "deengert" == Douglas E Engert <[email-masked]> writes:

deengert> So should the Kerberos revisions be changed, to accept
deengert> either GeneralString but define UTF8String? Does PKINIT need
deengert> to define a separate CertPrincipalName just to get around
deengert> this problem?

I don't know what PKINIT uses... I vaguely recall it's UTF8String
everywhere though.

It's not too clear what the optimal solution would be.  We should
probably define a KerberosString ASN.1 type that will be used for
everywhere a GeneralString is used currently.  What it actually ends
up being is an interesting question of course.

"Lying" by use of a kludge such as

	KerberosString ::= [UNIVERSAL 27] IMPLICIT UTF8String

is one possibility, except that it is illegal to use a tag of class
universal outside of the ASN.1 specification itself.  (Universal class
tag number 27 is the tag for GeneralString.)

Another possibility is to use

	KerberosString ::= CHOICE {
		ascii	GeneralString,
		utf8	UTF8String
	}

but that is somewhat uglier.  It *does* have the advantage of
potentially being easier to parse with a real ASN.1 parser, if we
don't generate a UTF8String for anything that isn't ASCII, and we
require that non-ASCII characters be encoded in UTF-8 rather than
ISO2022 shift encodings.  It is, however, going to change the abstract
syntax, but will usually not change the on-the-wire encoding if the
GeneralString fork is taken.

Yet another possibility is Jeffrey Altman's suggestion of using the
ISO2022 escape sequence to change to UTF-8 encoding while using
GeneralString.  This has the advantage that it conforms to ASN.1
fully, as far as I can tell.

deengert> If not, the "agreement" should at least be documented.

I do not recall too much about the "agreement"... we should have
documented it at the time but didn't.

Additionally, does *anyone* recall why we use GeneralString rather
than GraphicString?  The additional hair of having to deal with
potential control characters (including NUL) seems questionable.

---Tom