Subject: Re: User Petition on Standards to Netscape and Microsoft

From: Rowland Smith <[email-masked]>
Date: Wed, 24 Dec 1997 09:04:40 -0500

On Tue, 23 Dec 1997, Christian Huitema wrote:

> ....  A nasty side
> effect is that by changing the language, they essentially rendered the
> existing ASN.1 tools obsolete.  All users of ASN.1 are thus faced with a
> dilemma: stick with the 1988 version, or bear the heavy costs of moveing
> to the incompatible 1994 version.  That SMIME is faced with this problem
> is not surprising.  Making a cogent decision to stick with the 1988
> version of ASN.1 is entirely reasonable.

The first version of the C language had serious defects which when later
corrected rendered the existing C compilers obsolete.  However, the end
result was that C became a more usable language that is now much more
portable across platforms.  The same has occurred for many other
languages, such as C++, Pascal.  Bug fixes and improvements sometimes
require non-backward compatible syntax changes, and in the case of ASN.1,
as with C, IMHO this was necessary and was for the greater good. 

When you consider the big improvements brought about by the changes to
ASN.1 in 1994, and the fact that the bug fixes to X.208 were all
syntactical and introduced no interoperability problem between
applications that used the older syntax and newer ones that use the
equivalent new syntax, you realize that the job of fixing the bugs in
X.208 was definitely a success. 

> In fact, the ASN.1 story should teach us a lesson about dependance on
> other bodies work.  Basically, you are much better of using self contained
> definitions (good old BNF) than trying to import a language you don't
> control. 

C, C++, Pascal, etc. change from time to time in non-backward compatible
ways - especially during the early years before there were sufficient
compiler implementations to shake the bugs out of them.  ASN.1 is no
different, for once people started building ASN.1 compilers in the second
half of 1980 the bugs in X.208 rose to the surface.  Well, those bugs have
been removed and ASN.1 has proven itself to be an excellent notation, so
it is wise to make use of it instead of reinventing the wheel.

Later,

Rowland Smith
[email-masked]

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 27 Dec 1997 10:31:05 -0800

At 02:15 PM 12/26/97 -0800, Karl Auerbach wrote:
>But we should recognize 
>that when one adopts ASN.1 one should be aware of the heavy ball and
>chain that comes with it. 

And we also have to realize that the size of ball and chain varies with the
person relating the story, as well as the time that person tried using
ASN.1. According to many stories I've heard, many of the obvious problems
with ASN.1 that were encountered by the SNMP community existed in
ASN.1:1988 and were fixed by ASN.1:1994. I've also heard from some
implementors who had heard terrible things about ASN.1 (my favorite is the
pronunciation "asinine one") that it wasn't as bad as they feared... as
long as they already had a compiler tool.

To be sure, there is almost no good, readable material on ASN.1. I've found
a total of one book, and it only covers ASN.1:1988. (ASN.1 Tutorial and
Reference, Douglas Steedman, ISBN 1871802067; the only online source that
had even heard of it was Computer Literacy.) The fact that the source for
the standard costs a lot of money and is universally acknowledge to be
obtuse makes matters worse. Fortunately, the ASN.1:1994 standard should be
freely available within a few weeks.

In frussling around with ASN.1 for S/MIME, I've found lots of diverging
viewpoints and a huge amount of apathy (nothing new in the IETF). Getting a
few opinions when making choices for or against ASN.1 (or even choosing a
particular year) is well advised.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "William Allen Simpson" <[email-masked]>
Date: Tue, 30 Dec 97 07:03:49 GMT

> From: "Phillip H. Griffin" <[email-masked]>
> I decided not to respond to the post from Bill Simpson, because
> some of the assertions seemed so off base from my perspective,
> and I was not really sure if he was serious after reading statements
> like "It has been historically problematic to get them correct just
> using our heads."
>
There were also some private messages that questioned my seriousness.
I'd have to guess that is the latest method of gratuitous ad hominem
insult from the ASN camp, as it is so uniform.

Of course I'm serious!  I really don't have time to post non-serious
messages, particularly to this group!  Heck, I don't really have time to
post any messages, I'm so far behind on everything since the IETF
meeting....

> I've done it three ways, hand coding, with coding toolkits, and with
> a compiler. There is absolutely nothing more complex or prone to
> error than trying to perform an automatable task by hand - a hand
> job. Where compilers can really shine is in insulating an application
> from frequent changes to an ASN.1 specification.
>
Count me in the group of feckless adventurers that do not use an ASN.1
compiler, and will probably never use any ASN.1 compiler.  I've coded
all my MIBs by hand.  If anything is more complicated, or has frequent
changes, then there is (by definition) a serious problem with the
original protocol design!

I've also done a few things here and there in the security field ;-)

(Nota Bene: those of you newbie email enthusiasts from the ASN camp will
note the wink; this was supposed to be a humorous statement with a hint
of irony.  Any other statements without this notation should be read in
a serious tone of voice.)

When my implementation processes a RSA signature over MD5 hash, the
magic token had better be (as documented in RFC-1991 -- I was never able
to determine it correctly by hand):

   30 20 30 0C 06 08 2A 86 48 86 F7 0D 02 05 05 00 04 10

I really don't care that there are other equivalent encoding methods
to represent the same ASN.1 value.  If they do not match exactly, they
will be rejected.

Good security protocol design practices do not allow permissive
variations and nebulous frameworks.  I am advocating that S/MIME have
all its messages defined as explicit octet strings.

> If true, how do you explain the extensive use of ASN.1 for
> cell phone messages, air to ground systems, and the new
> ITU-T wireless standards?
>
That's easy.  Cluelessness, and lack of interoperability concerns by
proprietary interests.	The folks actually making systems that work out
the door for a reasonable cost are not using ASN.1, at least in my
EIA/TIA cellular experience.

Of course, the GSM and CDPD folks threw a few tens of billions (thousand
millions) US dollar equivalents at the problem, and there are fewer
interoperability failures than when they were first introduced.  I don't
consider that money well spent!

Of course, I still remember the little battle to get a few million to
get the NSFnet rolling.  It seemed like so much money at the time.  Tens
of billions are practically unthinkable, and would solve rather a lot of
our Internet management problems, like funding IANA....

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26	DD 0D B9 9B 6A 15 2C 32

---

From: Bancroft Scott <[email-masked]>
Date: Tue, 30 Dec 1997 05:56:49 -0500 (EST)

Christian Huitema wrote:
 
> I must say that I fully agree with Bill Simpson  on the advantage of
> completely separating S-Mime from ASN.1.   Yes, ASN.1 has changed over
> time.
> It went from a limited and somewhat broken form in 1984/1988 to
> a very ambitious object-oriented form in 1994.  Doing so, it did not
> only correct a few bugs, but also added a whole set of new
> "functionalities." basically, it promots the ASN.1 compiler to a central
> role in the implementation,

The lack of an unambiguous and compilable notation was a major complaint
about ASN.1:1988.  As a result of addressing this complaint, compilers
were able to play a central role in implementations.

> where it should not only provides
> encoding and dcoding stubes, but also a complete database of options,
> tabless and controls.

With the exception of a few enhancements such as the introduction of
BMPString, the current ASN.1 provides only those functionalities that the
1988 ASN.1 sought to provide but failed to do.

> This is precisely the proble.m.  Compilers introduce all kinds of
> weirdnesses in protocol development.  They encourage gratuitous 
> complexity.

The protocol needs be only as complex as its authors deem necessary. 
Providing notation that allows complex types to be defined does not mean
that it has to be employed when it is not needed.  This is no different
from C and Java which allow gratuitously complex programs to be written,
but that does not mean that they encourage such programs.

> They tend to generate very large code.  They also tend

The better ASN.1 compilers clearly generate code that is fast enough and
small enough to fit into many small everyday devices.  Witness its use in
cell phones, radio pagers, ISDN devices, fax routers, etc.

> to  make code hard to prot; specifically, they make it bvery difficult
> to mix modules developed with different compilers,because each one
> generates its own API and  uses its own set of libraries.

Good ASN.1 compilers provide you with the flexibility needed to closely
match the APIs of other compilers, though not necessarily all. 
Regardless, I don't see how what you are saying is a reason to preclude
use of ASN.1 compilers.  They have proven to be a major productivity boost
from syntactically simple specifications such as the video phone standards
for communication across the Internet, to complex ones such as SET. 

--------------------------------------------------------------------------
Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                                  Tech Support :1-732-249-5107
http://www.oss.com                            Fax          :1-732-249-4636

---

From: "William Allen Simpson" <[email-masked]>
Date: Tue, 30 Dec 97 16:38:24 GMT

> From: Bancroft Scott <[email-masked]>
> On Sun, 28 Dec 1997, William Allen Simpson wrote:
> > But I have a very basic question: Since the replacement is not backward
> > compatible, why was it not given a new label, such as ASN.2?
>
> Same reason that C was not renamed D after the bugs were cleaned up,
> yielding a better but non-backward compatible version of C.  And the same
> reason that C++ was not renamed to C+++ when it was cleaned up, yielding a
> better but non-backward compatible version of C++.
>
Well, gosh, I'm not sure that I know what those non-backward compatible
changes to C were.  I've only been using C since 1980 (maybe '79).
Perhaps you are referring to something before that?

As best as I remember, my C code written for Ron Cain's small c compiler
on the Z80 (which I personally extended from time to time), all pretty
strictly K&R, still compiled on Borland's C for the '88 and DJ's GNU C for
the 386 without any syntactic changes other than header file names.

The non-backward compatible changes begat a new thing, renamed C++.

Unfortunately, I've never liked C++, and use it as little as
possible....  So, I don't know what the non-backward compatible changes
were there, either.  I have not noticed any syntactic changes, like
added colons or semicolons or parenthesis, to anything that I have used.

> The essense of ASN.1 was not changed between 1988 and 1994, and ASN.1
> modules can be written that conform to both 1988 and 1994 ASN.1 so long as
> they don't use any of the buggy notation corrected by the 1994 version of
> ASN.1 (e.g., macros), or use any features unique to 1994 ASN.1 (e.g.,
> BMPString).
>
Good, so there will be no problem with our MIBs?

(And in his response to Christian)
# Pagh!  More of the "not invented here" nonsense.  Take a look at how
# rapidly Microsoft was able to develop NetMeeting, or Intel its VideoPhone
# products, or how quickly the many others in the audio/video over Internet
# arena were able to get the products to market, then explain to me how they
# could have arrived at interoperating products in such short time if
# ASN.1:1994 was anything short of beautiful?

Hmmm, do I detect a note of bias in this response?  I'd guess "beauty is
in the eye of the beholder".

With whom does NetMeeting interoperate?

With whom does VideoPhone interoperate?

And more importantly, do they interoperate with sd?

I'm pretty sure I mentioned in a previous message that all of the ASN.1
efforts of which I am aware (other than MIBs) were not concerned with
interoperability -- they were proprietary.  Later interoperability took
vast effort, and still has not been entirely successful.

And the MIBs have been a tough row to hoe as well.

[email-masked]