Subject: RE: UTF-8, ASN.1, and our past sins

From: "Paul Leach" <[email-masked]>
Date: Mon, 19 Nov 2001 19:23:48 -0800

The biggest advantage is that it gets us off the hook about misusing
ASN.1 -- we would not be using it any more, we would be using KSN.1. It
appears there are lots of ways (see section 5) where we misuse ASN.1,
not just the GeneralString problem, where UTF8 and "just-send-8" are
probably equally evil.

I intended my comment in that regard to be independent of the solution
to the character set problem -- that's why I said up front that I
expected that not everything I said was correct.

With respect to the current state of the protocol, its pretty clear that
clients and servers that don't agree on the character set encoding won't
interoperate, and there is nothing we can do about that -- the existing
code is what it is. That means that no matter what we do, someone gets
screwed -- the most we can do is try for the greatest good for the
greatest number.

If people are going to change their code, then it seems to me like the
cleanest solution is that everyone code as UTF8. That has the advantage
that all the people who currently use 7 bit ASCII don't have to change.

Then there's the migration issue: how can new clients can coexist with
old KDCs and vice versa coexist.
That seems largely independent of what we choose as "the new way". I'll
address that in another message -- I'm late for a meeting right now.

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Monday, November 19, 2001 6:57 PM
> To: Paul Leach
> Cc: Nicolas Williams; Jeffrey Hutzelman; Johan Danielsson; 
> [email-masked]
> Subject: Re: UTF-8, ASN.1, and our past sins
> 
> 
> >>>>> "Paul" == Paul Leach <[email-masked]> writes:
> 
>     Paul> So, I'm going to propose something maybe a bit radical.  No
>     Paul> one can tell us (an IETF WG) what metalanguage to use to
>     Paul> describe our protocol. They can legitimately gripe if we use
>     Paul> an existing one incorrectly ("perversion" comes to mind as
>     Paul> an adjective).
> 
> So, when you are proposing something this radical it helps if 
> you explain what advantage your proposal has.  It's not clear 
> to me what we gain by adopting this proposal (other than 
> saying general string is
> UTF8) in simplifying getting Kerberos revisions to proposed 
> standard.  I'd be much more likely to agree with such a 
> change if I understand how it helps us.
> 
> Note that we discussed tagging UTF8 strings as general 
> strings in London.  There are several problems.  First, we 
> apparently have a customer base in the DCE community that 
> needs a way to know whether the KDC/clients support UTF8 or 
> whether they use just-send-8.  Your proposal does not provide 
> a solution for that community and  they seem likely to block 
> consensus if we do not meet their needs.
> 
> Second the IESG chair stood up at the London meeting and 
> indicated that misusing ASN.1 (in particular tagging UTF8 
> strings as general
> strings) would create significant political friction between 
> the ITU and IETF.  I don't think he said we definitely 
> couldn't do this tagging, but he seemed unlikely to accept a 
> solution that violated ASN.1 while viable other solutions 
> were on the table.
> 
> 
>

---

From: Sam Hartman <[email-masked]>
Date: 20 Nov 2001 10:36:04 -0500

>>>>> "Paul" == Paul Leach <[email-masked]> writes:

    Paul> The biggest advantage is that it gets us off the hook about
    Paul> misusing ASN.1 -- we would not be using it any more, we
    Paul> would be using KSN.1. It appears there are lots of ways (see
    Paul> section 5) where we misuse ASN.1, not just the GeneralString
    Paul> problem, where UTF8 and "just-send-8" are probably equally
    Paul> evil.

Ah, in that case I agree.  I don't see that we should go out of our
way to officially separate ourselves from ASN.1 but if doing so allows
us to solve one of the problems that separates us from having a last
call on the document, we should do so.

---

From: Matt Crawford <[email-masked]>
Date: Tue, 20 Nov 2001 11:04:28 -0600

I do not think that claiming that Kerberos does not actually use
ASN.1, but rather a near relative "KSN.1" will make the IESG happy.
But if the wg wants to try, there is a sort of a precedent: The IPv6
address architecture uses for the endpoint identifiers, not an IEEE
EUI-64 identifier, but that with the sense of one bit reversed.

---

From: Martin Rex <[email-masked]>
Date: Tue, 20 Nov 2001 18:25:43 +0100 (MET)

Hi Paul,

Well, for the backwards compatibility issue, my preference would
be the CHOICE construct  -- since it is claimed to be invisible
at the DER encoding level.

One possibility to gain the largest interoperability (actually full
interoperability for the installed base where only US-ASCII is used)
would be an additional constraint in that a Kerberos name that does
contain only ASCII chars must be encoded as GeneralString.
That should be fairly easy to implement, I suppose.

Btw. why did no-one from the ASN.1 guru's pushing the Kerberos password
change protocol indicate that the CHOICE would disappear in the
DER-encoding?  We had a lengthy fight over the use of CHOICE in that
proposal, didn't we? 

> not just the GeneralString problem, where UTF8 and "just-send-8" are

I can't believe what I read here...

When I complained about the extensive and unnecessary use of ASN.1
in Microsofts various protocol proposals (password change, IAKERB,
requiring SPNEGO for HTTP-with GSS-API authentication) you always
pointed to commercially available ASN.1 parsers.

Now you suggest to use custom ASN.1 just to legalize your own
abuse of ASN.1...

-Martin

---

From: [email-masked] (Johan Danielsson)
Date: 20 Nov 2001 20:38:47 +0100

Martin Rex <[email-masked]> writes:

> Btw. why did no-one from the ASN.1 guru's pushing the Kerberos
> password change protocol indicate that the CHOICE would disappear in
> the DER-encoding?  We had a lengthy fight over the use of CHOICE in
> that proposal, didn't we?

My reluctance to CHOICE is not because of the encoding itself[*], but
that it's different from anything else in ASN.1.

/Johan

[*] It's strange to me that they decided that CHOICE's shouldn't use
any extra prefix when everything else is wrapped up tightly in wet
blankets.