Subject: Re: Working Group Last call - draft-ietf-cat-kerberos-set-passwd-05.txt

From: Wyllys Ingersoll <[email-masked]>
Date: Tue, 15 May 2001 16:17:56 -0400 (EDT)

I dont have any objections to the data or the protocol itself at
this point.  Whether or how soon it gets implemented here is a 
function of customer demand, time, and resource availability.  In 
principal, I think the proposal has merit and should go forward.  

As for the ASN.1 discussion:

-  Im inclined to agree that the ASN.1 should be kept in the I-D since
   its already used in other parts of Kerberos.  However if someone has a
   strong case for easier-to-implement, non-ASN.1 messages that wouldnt 
   clash horribly with the rest of the Kerberos protocol then I would like 
   to hear it (I guess its getting late for that though).
   
-  If the ASN.1 is kept, then definitely specify the encoding rules
   in the I-D.

-Wyllys Ingersoll
 Sun Microsystems

>
>We still have three more days for the last call. 
>
>The only objections I have heard so far have been to the use of ASN.1.
>
> o Some implementations have been using hand encoded ASN.1 routines and having
>   to hand code more ASN.1 is a hardship. 
>
> o Substantially more ASN.1 was added in this draft then in the informational
>   draft. 
>
> o The addition of the ASN.1 CHOICE is new, and will require more hand coding. 
>
> o The BER/DER encoding rules need to be specified.
>
>The first three objections are all basically, the same. Therefore I would 
>like to ask the Kerberos implementors, if this draft is adapted will they 
>implement it or not? If not, why, is it because of the ASN.1?
>
>I agree that the fourth point needs to be clarified. Can the authors recommend
>the exact wording and location of chages to be added to the draft to specify 
BER/DER?
>
>Are there any other technical issues with the draft?
>
>
>
>"Douglas E. Engert" wrote:
>> 
>> At the Mineapolis IETF meeting the Kerberos WG agreed to start the last call 
on:
>> "Kerberos Set/Change Password: Version 2", John Brezak, J Trostle, Michael 
Swift,
>>  Bill Gossman, 04/25/2001. (29667 bytes)
>> 
>> http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-set-passwd-05.txt
>> 
>> The requested changes from the meeting have been made to this latest draft.
>> At the request of the authors, we will start a two week last call, which 
should
>> end on May 17.
>> 
>> --
>> 
>>  Douglas E. Engert  <[email-masked]>
>>  Argonne National Laboratory
>>  9700 South Cass Avenue
>>  Argonne, Illinois  60439
>>  (630) 252-5444
>
>-- 
>
> Douglas E. Engert  <[email-masked]>
> Argonne National Laboratory
> 9700 South Cass Avenue
> Argonne, Illinois  60439 
> (630) 252-5444

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 May 2001 20:35:46 +0200 (METDST)

>    to hear it (I guess its getting late for that though).

Using the existence of ASN.1 in other parts of Kerberos 5 is
IMHO a very poor excuse for using it here.

rfc1964 didn't add any ASN.1 to Kerberos and for good.

For the complexity of the task at hand and with at least two independent
Kerberos 5 implementations that don't use a commercial ASN.1 compiler
we shouldn't blindly add more ASN.1 to Kerberos just for the sake
of the fun of it. 

What I don't like is not that the proposal uses ASN.1 structures,
but that it does *NOT* include the bits-on-the-wire equivalent
definition.

The clear advantage that the bits-on-the-wire spec would give:

- it would reveal the complexity of the current proposal
  (or the absence thereof, i.e. its elegance), allowing the
  whole community to participate the discussion

- it would facilitate the implemenation of the proposal
  for those implementations that do not use a commercial
  ASN.1 compiler and a much quicker adoption of that
  Kerberos extension.

- it would provide a significantly more reliable
  ground for interoperability among independent implementations

> -  If the ASN.1 is kept, then definitely specify the encoding rules

That the authors forgot to include this "little detail" makes me
really wonder about other hidden features that are non-obvious to
ASN.1 illiterates like me.  I haven't seen any explanation from
the ASN.1 fanciers yet that explain how the CHOICE element
used in this spec can be quickly implemented by the non-ASN.1
guys so that this issue can be simply ignored.

-Martin