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

From: Wyllys Ingersoll <[email-masked]>
Date: Thu, 17 May 2001 16:13:51 -0400 (EDT)

RFC 1510 section 5.1 specifies:
"All uses of ASN.1 in Kerberos shall use the Distinguished Encoding
 Representation of the data elements as described in the X.509
 specification, section 8.7 [8]."
 
The RFC1510 revisions draft (08) reinforces this despite the fact
that some implementations have used BER (section 5.1.1).  
 
Will this draft (if it is approved with ASN.1) follow the recommendation
and use DER ?

I am quite interested to see what Martin produces as a counter-proposal
without requiring the use of ASN.1.

-Wyllys

>
>I cannot see why a commercial ASN.1 compiler is required before ASN.1
>can be used in an implementation. Of 4 widely available Kerberos V5
>implementations - Windows 2000, OSF/DCE, MIT Kerberos V5 and Heimdal
>Kerberos V5, only MIT chooses not to use an ASN.1 compiler. So it is
>possible to implement protocols specified in ASN.1 without the aid of a
>commercial compiler.
>
>Speaking as an implementor, use of ASN.1 in a standard has not stopped
>Microsoft from building an implementation of a protocol. Microsoft will
>implement the kerberos-set-password-05 protocol if it is published as an
>RFC in a future version of Windows using ASN.1.
>
>I cannot see how a bits on the wire specification produced from an ASN.1
>description would speed implementations. It does have instructional
>purposes for those who what to understand ASN.1. But that is not the
>purpose of this I-D.
>
>Also I don't see a need to single out this I-D in its use of ASN.1 when
>other I-Ds and standards are also using ASN.1 (including CHOICE) - there
>are even multiple implementations of those protocols.
>
>
>> -----Original Message-----
>> From: Martin Rex [mailto:[email-masked]] 
>> Sent: Wednesday, May 16, 2001 11:36 AM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: Re: Working Group Last call - 
>> draft-ietf-cat-kerberos-set-passwd-05.txt
>> 
>> 
>> 
>> Wyllys Ingersoll wrote:
>> > 
>> > 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).
>> 
>> 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
>> >    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.
>> 
>> -Martin
>>

---

From: Jonathan Trostle <[email-masked]>
Date: Thu, 17 May 2001 15:31:41 -0700

>Will this draft (if it is approved with ASN.1) follow the recommendation

Yes.

Jonathan