KerberosTime

[Sam Hartman]

In your quest to understand KerberosTime, you seem to be missing the
critical factor in standardization decisions.  The important thing in
most cases is to have a decision made and to agree to that decisions.
Representations of data don't matter all that much; we'd be OK with
integer time, we seem to be OK with KerberosTime.

we're certainly better off having all the Kerberos implementations and
specifications use a single format for time.  We're certainly better
off keeping things that way rather than paying the cost to change our
time representation.

When decisions are made, factors like representation size,
implementation complexity and handling corner cases like time beyond
the year 2038 are worth discussing.  When we are aware of these
factors, we try to account for them.  But once the decision is made,
the reasoning is often no longer important.  It might have been an
arbitrary decision made by someone who didn't really thing things
through and needed some way to represent time.  It might have been
something the working group spent hours arguing over.  But the
decision will remain because we wish to continue being interoperable
and the cost of change is too high.

Sometimes we need to pay the price of change; if we had used integer
time, we would need to make sure eventually that all the
implementations could deal with integers longer than 32-bits.  We're
having a long drawn-out discussion of how to handle making Kerberos
extensible withing the Kerberos working group.  We believe it has
finally gotten to a point where we need to pay that price.

But questioning decisions of the early Kerberos ASN.1 rarely leads to
enlightenment.  RFc 1510 does not use ASN.1 particularly well.  Many
of the decisions in RFC 1510 are fairly arbitrary.  Feel free to ask
the questions; you may find out something new or draw our attention to
some problem.  Just don't be surprised to learn that an arbitrary
decision was made years ago and no one knows why or questioned the
decision.

--Sam