"Jeffrey Altman" <[EMAIL PROTECTED]> wrote:
> >My point is where did you get the value 129, and who
> >authorized you to use it?
"Salil Dangi" <[EMAIL PROTECTED]> wrote:
> This is just a number which we are using for the time being. Our Telnet
> Server and Telnet Clients which have implemented this type are configurable
> to use any other number for this type. This will allow us to use any IETF
> assigned number in future.
While I can't answer for sure what Salil was thinking, I see that RFC
2946 makes no provisions whatsoever for "experimental" or "local"
numbers of any sort. All it defines is one byte of address space, and
claims there is plenty of unallocated space left. That doesn't really
leave Salil with much of an alternative to "just picking one". I
presume Salil was looking for a number for "experimental" use, and
wanted to pick a number that was not likely to be confused with
anything else. 129 stored in a signed byte becomes negative, so
perhaps Salil thought of this as being most consistent with K5's
experimental range. Of course, if he intends to use it for wide-spread
production use, it would be a very good thing for him to pursue getting
an "official" number. Writing up a description, and circulating code
would be good too. Salil picked a number that is right where the
defined number allocation scheme presumably changes; I don't know if that was
on purpose or not.
Many standards make provisions for local or experimental usage. The K5
standard specifies negative numbers. When I started putting cast5 into
K5, the first two problems I ran into are:
negative numbers make ugly array indexes,
as K5 1.0 used an array of encryption systems,
-1 was already in use.
I worked out solutions for both of these. My source uses KRB5_WILD
instead of -1 (though I made it -1 in the end anyways). There were
also a bunch of places where MIT tested for KRB5_WILD by saying "< 0",
which I had to fix, in order to make negative types work. It would be
nice to see the MIT k5 source pick up on both these ideas. The array
stuff was, well, ugly. 1.1+ handles this much better. I think
there may have also been something ugly about ASN.1 basic encoding
rules, but it's been long enough that I've forgotten. All in all,
using negative numbers with MIT k5 was unexpected annoying.
I don't remember GSSAPI making any provisions for experimental numbers.
I ended up picking 0x0072, 0x0073, and 0x0063 for my sgn_alg and
seal_alg types, because these seemed least likely to break what
was already obviously very fragile code. Of course, I regard these as
"disposable" numbers -- I have no interest in deploying any
production use of cast5 or rc6 today.
-Marcus Watts
UM ITCS Umich Systems Group
