Subject: do we care about deterministic encodings?

From: Tom Yu <[email-masked]>
Date: 01 Dec 2000 20:20:28 -0500

How important do we think it is that a given encoding of a Kerberos
message be preserved upon decoding and reencoding?  This is a separate
issue from BER versus DER, since even a DER encoding may be
nondeterministic if there are indistinguishable semantics between
lacking a value and encoding a specific value.

For example, in the case of an optional "microseconds" field, some
implementations cannot distinguish between a value of zero and the
lack of an encoded value.  Decoding and reencoding of a message may
therefore not produce the exact same encoding as received.  We can
make the *specification* of the protocol deterministic by judicious
use of the DEFAULT keyword, which requires that the implementation not
encode the "default" value listed in the ASN.1 syntax.

Optional microseconds fields almost always appear in conjunction
KerberosTime fields.  When an optional microseconds field appears in
conjunction with a required KerberosTime field, it is apparent that an
implementation is very likely to "encode" a value of zero microseconds
by omitting the field altogether.  However, when a microseconds field
appears in conjunction with an optional KerberosTime field, is is not
obvious whether a value of zero microseconds should be encoded or not
when the associated KerberosTime is encoded.  At least the MIT
implementation does appear to encode an actual zero value for a
microseconds field associated with an optional KerberosTime field in
the case where the KerberosTime field is actually encoded.  It would
be dubious utility to encode the microseconds without encoding the
associated KerberosTime, though. :-)

    Q: Does anyone think that the ambiguity relating to microseconds
    encoding is worth the trouble of resolving, given that (in my
    opinion) there are somewhat inadequate data regarding the
    behaviors of existing implementations?

Additional related questions are:

    Q: Given that the MIT implementation seems to always encode
    microseconds (even zero values) that are associated with an
    optional KerberosTime, and omit microseconds that are associated
    with a non-optional KerberosTime, should we impose this behavior
    on all implementations?  How are non-MIT implemenations behaving?

Likewise, there is a lack of semantic distinction between an omitted
optional sequence-of and an encoded zero-element sequence-of.  In
contrast to the microseconds case, the behavior of an implementation
is likely to be less ambiguos.  In a C-language implementation, where
the in-program representation of an empty sequence-of is likely to be
merely a NULL pointer, the encoders would likely omit the encoding
altogether.  The one case that Ken Raeburn pointed out in terms of
address lists needs to be considered, though, and we would need to
evaluate instances where there actually can be a useful semantic
distinction.

    Q: Does anyone feel that there needs to be a semantic distinction
    between a zero-length list and an omitted list for any types other
    than HostAddresses?

---Tom

---

From: [email-masked] (Johan Danielsson)
Date: 02 Dec 2000 20:06:43 +0100

>     behaviors of existing implementations?

Which usec's should be optional and not seems like pretty random right
now. What someone should have done in the first place was probably
something like:

        KerberosTime ::= SEQUENCE {
                time    GeneralizedTime,
                usec    INTEGER OPTIONAL
        }

and always use that. Anyway, the usec field is just an optional
integer, and as such it's probably easier to re-encode it as received,
instead of doing something with it. It doesn't matter much.

>     on all implementations?  How are non-MIT implemenations

We seem to always encode microseconds (regardless of them being zero
and/or optional).

>     Q: Does anyone feel that there needs to be a semantic
>     distinction between a zero-length list and an omitted list for
>     any types other than HostAddresses?

If there should be a difference for HostAddresses I think there should
be for any other type. Adding more (unneeded) semantics to the ASN.1
mess we have doesn't sound like a great idea to me.

/Johan