Subject: ASN.1 vs XML (was Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt)

From: "David P. Kemp" <[email-masked]>
Date: Wed, 14 Jul 1999 10:20:14 -0400 (EDT)

> From: Stephen Kent <[email-masked]>
>
>  I do disparge the notion that
> standards are established by distributed software.

I agree with that, and disagree particularly with the notion that
standards or profiles should be modified to accommodate deficiencies
in widely-used software.

> As the CTO of a CA product developer I can and do take exception with the
> suggestion that use of SSLeay is relevant to core CA business.  We
> developed our own ASN.1 compiler years ago, even sold it to some folks, and
> have not found it necessary to avail ourselves of freeware.

That is a reasonable position for the CTO of a company with deep and
longstanding expertise to take.  However, I agree with Mike Myers that
the IETF should make its standards accessible to the other 99% of us.
The "Running code" in the IETF motto applies most strongly to
running code for which source is available.

But whereas Mike believes the proper approach is to dummy-down the
syntax, I believe the proper approach is to smarten-up the developers.
SSLeay (which supports TLS, but predated it, hence the name) is a
valuable resource for developers.  The S/MIME Freeware Library, the
OpenLDAP BER library, and the zillions of SNMP books with code
mentioned by Peter are all educational materials available to
developers who would like to use ASN.1 but are put off by the
difficulty of either learning from scratch or purchasing expensive
expertise.

My own small attempt at protocol design, a digital-signature based
equivalent of S/KEY written up in a series of I-Ds several years ago,
used a yacc grammar as the syntax expression language because I
believed the buzz that ASN.1 is "too hard" or "too OSI" for the IETF.
Today, if there were still a need for such a protocol, I wouldn't
hesitate to specify and implement it in ASN.1, perhaps constrained to
the LDAP-supported subset.

Carl Ellison is correct when he claims that the worst feature of ASN.1
is that it enables (in the pejorative psychobabble sense: "you're
enabling this destructive behavior") protocol committees to lard their
designs with complex features.  Complex functionality requires complex
syntax, but when the only examples of ASN.1 people see are big and
incomprehensible, they get the impression that the language is the
cause of the incomprehensibility.  A counterexample - a simple protocol
expressed in a simple subset of ASN.1 with a simple reference
implementation, would both help dispell that impression and widen the
pool of expertise.  You have to start somewhere.