Ticket History #1681: Kerberos 1.3 uses wrong encoding of etype-info2

I believe that a solution to this problem forces a more or less
immediate 1.3.1 unless we change the spec.

OUr implementation encodes the salt in etype-info2 as a octetstring not a KerberosString.

Return-Path: <hartmans@MIT.EDU>
Received: from solipsist-nation ([unix socket])
by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Tue, 22 Jul
2003 08:49:56 -0400
X-Sieve: CMU Sieve 2.2
Return-Path: <hartmans@MIT.EDU>
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
[18.7.7.76])
by suchdamage.org (Postfix) with ESMTP id 2034113207
for <hartmans@suchdamage.org>; Tue, 22 Jul 2003 08:49:56 -0400 (EDT)
Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61])
by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h6MCntFT023075;
Tue, 22 Jul 2003 08:49:55 -0400 (EDT)
Received: by luminous.mit.edu (Postfix, from userid 1000)
id 4D73F76614; Tue, 22 Jul 2003 08:51:01 -0400 (EDT)
To: "Liqiang(Larry) Zhu" <lzhu@windows.microsoft.com>
Cc: "Ken Raeburn" <raeburn@mit.edu>, tlyu@mit.edu, hartmans@mit.edu
Subject: Re: aes interop
References: <DAC3FCB50E31C54987CD10797DA511BA044CC2B5@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
From: Sam Hartman <hartmans@MIT.EDU>
Date: Tue, 22 Jul 2003 08:51:00 -0400
In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA044CC2B5@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> (Liqiang
Zhu's message of "Tue, 22 Jul 2003 02:56:15 -0700")
Message-ID: <87smoy7miz.fsf@luminous.mit.edu>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.1 (gnu/linux)
X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
X-Spam-Level:
MIME-Version: 1.0

No, that would be my fault. Apparently etype-info uses an octetstring
and etype-info2 uses a kerberosstring.


Do we want to change the spec or do we want to change our
implementation? The argument for changing the spec is that the two
types should be as parallel as possible.

I think probably our implementation, as it is actually a text string
and I think will have all the internationalization issues of other
strings in extensions.

Our implementation will need to accept the broken encoding, but I
think that if we quickly release a 1.3.1 which produces correct
encoding problems will not be too bad.

I will discuss with the rest of the team.