Ted,
From: "Theodore Ts'o" <tytso(_at_)MIT(_dot_)EDU>
Within the IETF community ... we spend a lot of time working on are
standards which explicitly mention bits and bytes in the protocol
specification. For example, from the PPP Authentication document, RFC
1334:
A summary of the Authentication-Protocol Configuration Option format
to negotiate the Password Authentication Protocol is shown below.
The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Within the ISO and CCITT (ITU-T) community that is how things were
done many years ago. However, after suffering the problems inherent
with this approach for so long, in the early 1980's CCITT embraced the
Courier protocol which was defined for Xerox Network Systems. Courier
was thus tweaked (e.g., Courier's 16-bit alignment was changed to octet
alignment) and adopted by CCITT as X.409.
Within the ISO community, it has always seemed to me that
interoperabilty was not major, driving concern, but being able to
document protocols in an elegant, nice fashion.
This is not so, Carl. After years of explicitly mentioning things in
bits and bytes and suffering from the problems inherent in
such an approach, and after reviewing several different solutions,
CCITT created X.409, based on Xerox's Courier protocol. It was not
out of some desire to document protocols in an elegant and nice
fashion that Xerox was driven to develop Courier, nor was it out of
any such desire that CCITT chose to use Courier as the basis for
X.409. Rather, it was out of the driving need to achieve
interoperability between different implementations written in possibly
different languages running on different kinds of machines and
communicating between possibly different versions of a protocol.
Hence, the emphasis on
the whole concept of Abstract Syntax *Notation*, the bifurcation of the
notation from the encoding, and your insistence that DER and BER aren't
part of ASN.1
Benjamin was right to insist that DER and BER are not part of ASN.1,
for they aren't.
The claim which is generally made is that this bifurcation allows
flexibility, because different people can specify different ranges of a
type --- your example of INTEGER (12345678 -- 12345680) only taking two
bits, for example --- without needing to write a new protocol
specification.
What??? This is not at all what Benjamin wrote. Re-read his email
again. The intention behind having value range constraints such as
INTEGER (12345678 .. 12345680) is not to allow different people to
specify different ranges of a type without needing to write a new
protocol specification, and that is not how it is used. It is meant
simply to state the range of values that the type can take on, and is
an integral part of the type definition that no one can unilaterally
alter. I believe Benjamin was simply expressing the fact that with
ASN.1 you describe types, *not* how they are encoded. You are again
confusing the description of the data type with how it is encoded.
However, this is only interesting from a notational
point of view. From a practical, interoperability point of view, it's
meaningless and pointless, since people who aren't using the same
profile of the protocol can't interoperate.
On the contrary, there are absolutely no interoperability problems
associated with ASN.1 types defined with constraints. Indeed, if you
look at many of the more recent ASN.1 specs, such as that used for
multi-media device control, tele-conference data exchange, or the
aviation industry's protocol for air-ground traffic control, they all
choose to heavily rely on subtype constraints precisely for the fact
that it goes a long way towards ensuring interoperability.
My claim (and I believe Jeff's claim, although I won't put words in his
mouth), is that most of the interoperability problems that we have had
with Kerberos V5 would have vanished into thin air if we had put used a
protocol notation much like what was used for the IP and PPP
specifications (see above for an example), instead of using an ASN.1
specification, which then forced people try to divine what the wire
encoding of the protocol was from the often obtuse and
hard-to-understand ASN.1 encoding specifications
The problem is not with ASN.1 or its encoding rules, but with lack of
use of ASN.1 compilers. By using an ASN.1 compiler you do not need to
concern yourself with divining what the wire encoding of the protocol
is. You simply work with the C data structures that the compiler
generates and have the compiler generated encoder/decoder worry about
how to get the data into the format necessary for transmission.
Furthermore, ASN.1 compilers don't necessarily help in this matter,
either. One of the bugs was caused by a misunderstanding about whether
or not one particular ASN.1 compiler did a bit-reversal in the ordering
of the bit strings when converting the bit-string to an C integer
variable.
As with C compilers, C++ compilers, etc., there are bad ASN.1
compilers, and excellent ones. The fact that there exists ASN.1
compilers whose generated code is not up to snuff is not an indictment
of ASN.1, but of the less than thorough job that went into their
creation (This is no different from the fact that the existence of
poor C, C++, Pascal, etc. compilers does not mean these languages or
all compilers for these languages are poor). Unfortunately, in the
case of Kerberos the ASN.1 compiler that is uses in its reference
implementation is one that is so severely deficient that in the ETSI
evaluation of 14 ASN.1 compilers a couple years ago it was dismissed
from further consideration early in the evaluation process because of
the number of problems with it. Such compilers which were developed
simply as prototypes should not be used as a basis for judging ASN.1
compilers in general, or reflect upon ASN.1 and its encoding rules.
In other words, the ASN.1 compiler adds an extra abstraction
layer and an extra layer of complexity, and hence adds another place
where bugs can slip in betwixt the specification and the implementation.
Don't let your experiences with a poorly implemented compiler color
your impression of ASN.1 compilers in general. There are good ones
available in the public domain, or if you are looking for
full-featured, rigorously tested ones that are fully supported and
whose generated code is easy to use, you can choose one of the top
rated commercial ASN.1 compilers.
Bancroft Scott