[50] in GSSAPI Development
One BER generality ruled out
daemon@ATHENA.MIT.EDU (John Linn. 508.486.6588. DTN 226-6)
Tue May 21 11:34:26 1991
Date: Tue, 21 May 91 08:33:50 PDT
From: "John Linn. 508.486.6588. DTN 226-6588. 21-May-1991 1133" <linn@zendia.enet.dec.com>
To: gssapi-dev@ATHENA.MIT.EDU
Ted writes:
>P.S. Actually, I may be mistaken. There may be an infinite number of
>ways of expressing any object in BER; it's a question of whether or not
>an encoding of the form:
>
>31, 128, 128, 128, ... , 128, 2, 1, 42
>
>is a valid way of expressiong the integer 42. It seems to be valid, but
>I'm not positive of that. If it is valid, then there is a infinite (but
>still countably infinite, thank goodness!) ways of encoding the integer
>42.
Per my ASN.1 spec (ISO 8825: 1987(E)), this case doesn't appear to be
valid. An integer is a [UNIVERSAL 2], so clause 6.2.2 applies: "For tags
with a number ranging from zero to 30 (inclusive), the identifier octets
shall comprise a single octet encoded as follows: a) bits 8 and 7 shall be
encoded to represent the class of the tag as specified in table 1, b) bit
6 shall be a zero or a one according to the rules of 6.2.5; c) bits 5 to 1
shall encode the number of the tag as a binary integer...". If the tag had
a value greater than 30, requiring use of a form with multiple octets,
clause 6.2.4.2 (c) would preclude an unbounded series of 128's based on
its prescription that "bits 7 to 1 of the first subsequent octet shall not
all be zero".
The sender option to include more than a minimum number of length octets
within a long-form BER length encoding does imply the ability to parse a
large variety of equivalent representations, but constraint a) in X.509
clause 8.7 (aka X.509-DER), "the definite form of length encoding shall be
used, encoded in the minimum number of octets", would serve to tighten
this up.
--jl
