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

From: Wyllys Ingersoll <[email-masked]>
Date: Wed, 16 May 2001 17:43:08 -0400 (EDT)

Comments below...

>> 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).
>
>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
>

I see your point and would also like to see on-the-wire equivalence.

But, I would also point out that the current password changing protocol
used by MIT and MS (Horowitz protocol) also uses ASN.1.  In fact,
for password changing (not passwd setting), this draft protocol uses the 
same message format as the old Horowitz one (with the exception of the
version number being bumped from 1 to 2).  So there is at least a 
basis for using ASN.1 for this particular operation.

Implementing the basic password change part shouldnt be too difficult,
but implementing all the new features provided by the draft might be 
more challenging for those of us (myself included) with little or no
ASN.1 experience.

Providing an on-the-wire equivalent would certainly remove a stumbling
block for future implementors.

>>    
>> -  If the ASN.1 is kept, then definitely specify the encoding rules
>>    in the I-D.
>
>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.

I agree, Im not clear on the use of the CHOICE element in ASN.1 either.

-wyllys

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 May 2001 17:59:00 -0400

> I agree, Im not clear on the use of the CHOICE element in ASN.1 either.

It's akin to a union. I.e., only one of the members of the CHOICE can be
present in an instance of a CHOICE.

> -wyllys

Nico
--