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

From: Bancroft Scott <[email-masked]>
Date: Wed, 24 Dec 1997 08:16:13 -0500 (EST)

Christian,

The decision to stick with X.208 makes no sense in light of the number of
serious defects that it contains and the productivity enhancements
possible when using ASN.1:1994.

The many defect reports that were issued against X.208 were corrected,
yielding the ASN.1:1994 standards.  The most visible manifestations of
these bug fixes are the replacement of the macro notation and ANY / ANY
DEFINED BY, change in the CHOICE value notation, and the mandatory
presence of identifiers in the definition of SET, SEQUENCE and CHOICE
types.  Because many of the defects were so serious and proved to be
impediments to quick implementations, then had to be removed. 

Benefits of using ASN.1:1994 include its greater readability, precision,
flexibility and ease of implementation. For example, when macros are used
in X.208 ASN.1 modules you can not tell what the macro does without its
author having to describe its behavior to you.  With ASN.1:1994 the
notation is much more precise, making this largely unnecessary.  Indeed,
the ASN.1:1994 replacement syntax for ANY DEFINED BY (now called an open
type) and macros is so much better that applications can be written more
quickly, simply and in significantly fewer lines of code.  With the
ASN.1:1994 syntax it is possible for encoders/decoders to fully decode a
message, including open types nested in open types nested in open types
(i.e., ANY nested in ANY nested in ANY, etc.), all via a single call to
the encoder or decoder, and without any custom modifications to the ASN.1
to accomplish this. Contrast this to use of X.208 which requires you to
repeatedly call the encoder/decoder for every ANY that you wish to encode
or decode, or which requires you to make custom modifications to the ASN.1
and utilize special ASN.1 tools that understand such customizations.  This
is just one of the enhancements to ASN.1 in 1994 that makes for easier
implementation of applications. 

It is due to the severity of the defects in X.208 that are corrected in
the current version of ASN.1, along with the many enhancements introduced
by ASN.1:1994, that X.208 has been slated for withdrawal as a standard by
ISO and ITU-T.  In preparation for the withdrawal, ISO and ITU-T standards
have been transitioning to ASN.1:1994 since its introduction; I see no
sense in writing a new standard such as S/MIME using X.208 that is buggy
and is slated to be withdrawn.  Nor is there any sense in writing S/MIME
or any other standard in an old version of ASN.1 that prevents
implementors from producing the smaller, simpler, easier to implement and
maintain applications that are possible with ASN.1:1994.

Bancroft Scott (ITU-T | ISO/IEC ASN.1 Editor)

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 24 Dec 1997 20:03:13 -0500

Bancroft,

	I wouldn't dream of disagreeing with you about the wretchedness
of ASN.1:1984; in fact, having used it and having needed to implement
systems which use it, I was left with feeling of "never again".

	ASN.1:1994 may or may not be a vast improvement, but there is
one (perhaps only one) good thing going for ASN.1:1984 --- and that is
Burt Kaliski's, "A Layman's Guide to a Subset of ASN.1, BER, and DER",
which is freely available from ftp://ftp.rsa.com/pub/pkcs/ps/laymen.ps.

	Unlike the official ASN.1 specifications, the Layman's guide is
free and easily accessible from the net, and more importantly, written
in plain English instead of "ISO-ese".  Hence, it was a description of
ASN.1 which was understandable by mere mortals, and which had all of the
relevant information in a single 49 page document, instead of scattered
across several hard-to-read documents (each of which had to be
separately ordered and paid for).

	Are you aware of a similar document which describes the new 1994
version of ASN.1?  There perhaps would be a greater acceptance of the
new version of ASN.1 if there was a gentle introduction to ASN.1:1994
(both its syntax and its various encodings) for those of us who weren't
intimately involved in the creation of the standard.

	Speaking personally, given my past experiences with the older
version of ASN.1, I don't have much inclination to look at the new
version.  If you say that it's much better, perhaps it's worth another
look.  A decision to look at ASN.1:1994 would be that much easier,
though, if there was something like Kaliski's "A Layman's Guide" ---
that is, something which is (a) easy to read, and (b) easy to get.

							- Ted

---

From: Bancroft Scott <[email-masked]>
Date: Fri, 26 Dec 1997 07:34:21 -0500 (EST)

Theodore,

Due to how widely ASN.1 is used outside of ISO and ITU-T (e.g., electronic
commerce, radio paging, aviation, transportation industry, etc.) it was
placed in a new category within ISO a few months ago.  In this new
category you no longer have to be affiliated with a "National Body" 
standards organization to participate in controlling ASN.1.  Anyone off
the street can now participate in ASN.1 standards meetings, whether face
to face or by email, without having to a formal representative of a
national body standards organization and without having to pay yearly dues
such as are required by ITU-T and typically by ISO member bodies.  This is
a new process and I will be able to say more about it in about two and a
half weeks.

Concerning the availability of a layman's guide to current ASN.1, there is
no similar document that is available, but that will change shortly.  I am
aware of at least two books on the subject that are being written, as well
as an excellent layman's introduction to ASN.1:1994 that was written by
Nilo Mitra (I have a copy but need permission from AT&T to post it at our
web site since it was published in the AT&T Technical Journal.)  There are
chapters here an there in other works that introduce ASN.1:1994, such as
Object-Oriented Networks by Subodh Bapat, but no distillation of ASN.1
as found in A Layman's Guide.  Yet.

I'll look into what changes are needed to Burt Kaliski's "Layman's Guide" 
to make it current as far as BER/DER is concerned.  The section on
encoding will see little change, for aside from the introduction of the
likes of UTF8String and BMPString and greater clarity/precision in the
encoding rules, the BER/DER encodings are unaffected by ASN.1:1988.
Probably the major change will be related to making clear to application
implementors how to fill the "holes" defined in some ASN.1 specs (ANY DEFINED
BY or, for misguided and harder to implement standards, OCTET STRING.) 
This is a where the current ASN.1 differs most radically from X.208 (1988). 

With X.208 a protocol designer can define a "hole" in their ASN.1 spec
using ANY DEFINED BYs or OCTET STRINGs whose type of contents is not fully
known until runtime, but they did not need to clearly indicate how these
holes should be filled.  This too often lead to difficult or/or invalid
implementations, for programmers had no simple table that correlate the
types of values carried in these holes with their identifying field.
ASN.1:1994 forces protocol designers to think about and clearly specify
how any such holes that they create should be filled.

I would imagine that at least a couple major variants of Layman's Guide
are needed.  One that addresses BER/DER, and another that addresses the
Packed Encoding Rules (PER).  PER encodings are very different from BER/DER
both algorithmically and in compactness.  Since its introduction in
1995 it has been chosen for use in just about every new application
protocol outside of the OSI arena when backward compatibility was not a
concern (MasterCard/Visa's SET is the only exception that comes to mind.)

--------------------------------------------------------------------------
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: "Phillip H. Griffin" <[email-masked]>
Date: Fri, 26 Dec 1997 11:57:41 -0500

> which is freely available from ftp://ftp.rsa.com/pub/pkcs/ps/laymen.ps.

Yes, "A Layman's Guide" is indispensible for those involved with 
the implementation of specifications based on early versions of 
ASN.1. I'll never forget how relieved I was to stumble upon it on
my first project, which I'm confident would have failed without
Kaliski's help. 

But with ASN.1:1994, the current standards, "Layman's Guide" must
be viewed as more of a starting point for understanding than it was
for X.208. It's really geared more towards the developer, which used
to be more likely to be the same person as the specification writer.
It would be nice to see this work updated and extended.

> separately ordered and paid for).

When I first started using ASN.1, I thought that I could avoid the ISO
standards documents almost entirely. They were a very difficult read
compared to the simplicity of presentation in "A Layman's Guide". But
then, they describe much more than existed in X.208, and provide new
tools for the specifications designer that were not available in the
80's. The current standards address modern, object oriented concepts
and map more naturally to OOP languages like C++ and Java.

> that is, something which is (a) easy to read, and (b) easy to get.

Phil
-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

---

From: Karl Auerbach <[email-masked]>
Date: Fri, 26 Dec 1997 14:15:25 -0800 (PST)

I hope all this talk about ASN.1 doesn't lead people to believe that it is
a good thing to adopt for use in protocols.

My own experience with ASN.1 and BER (via implementations of X.400 and
SNMP) as well as by watching people struggle with the weirdities of ASN.1
as a means of expressing even the most simplistic of data structures
(MIBs) has led me to a firm belief in the following:

Unless one can articulate specific and compelling technical reasons to use
ASN.1 or any of its encoding schemes, it is wrong to use it in a computer
protocol either in packet encodings or as a means of documentation or
specification. 

In the context of SNMP, ASN.1 has been the dominant source of
mis-implementation and of non- or poor interoperability.  And many
implementors don't recognize ASN.1/BER as being full of value-dependent
edge conditions and hence many implementations are inadequately tested.

This doesn't mean that ASN.1 should be considered as the universal pariah
of networking.  For example, I wish we had considered ASN.1/<some encoding
rules> in the context of RSVP packet structures.  But we should recognize 
that when one adopts ASN.1 one should be aware of the heavy ball and
chain that comes with it. 

		--karl--