Subject: Re: Compressed data type for S/MIME

From: [email-masked] (Peter Gutmann)
Date: Thu, 5 Aug 1999 13:47:49 (NZST)

"David P. Kemp" <[email-masked]> writes:

>I've often wondered whether ASN.1 could be used to express the bits on the 
>wire of an existing protocol such as IPSEC's AH.   To do so, one would need 
>to define "Fixed-field Encoding Rules" (FER) which would place only data 
>(not tag or length) octets in the datastream, and a set of macros to 
>conveniently represent the necessary fields.

I dunno about IPSEC, but I'm pretty sure you could shoehorn the SSL encoding
into it without too much trouble, it's just a stripped-down ASN.1+DER (the 
best description I can think of is a kiddies ASN.1, without meaning that in a
negative way).  I've even seen an attempt at EDI using an ASN.1-like notation, 
although the result was... unpleasant (actually I think Colonel Kurtz had 
appropriate words for the result).

Peter.

---

From: Marc Branchaud <[email-masked]>
Date: Thu, 05 Aug 1999 10:12:04 -0700

> appropriate words for the result).

I've been toying with this kind of idea recently, too.  I was actually
thinking of PER instead of DER.  I've only glanced through the PER spec,
but it seems to me that a stripped-down ASN.1 encoded with PER would be
easy to map into those 32-bit block diagrams you usually see in Internet
specs.

My reading of PER is that it provides a way to strip out as much of the
tag and length values as possible.  To me, this most closely resembles
the "usual" Internet way of specifying a protocol -- the first four
bytes are a value for foo, the next two are for a bar, etc.  

It's obvious that many people don't like ASN.1 for all sorts of
reasons.  I believe that a definition of ASN.1 that allowed a reader to
easily visualize the bits on the wire would go a long way towards making
ASN.1 more acceptable to the Internet community.  This thought led to my
speculations about a "thin" ASN.1 and PER.  I can even envision a Perl
script that takes thin ASN.1 and spits out a 32-bit block diagram...

I'm happy to work with someone on this sort of thing if people think it
has merit.

		M.

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL
INC.
 [email-masked]        PKI References page:             
www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Fri, 6 Aug 1999 13:50:45 -0400

It is worthwhile to use a formalism to express the
syntax of IETF protocols. It would be much better to 
capture both syntax and semantics and this is easy 
enough using augmented finite state machines and such.

Using ASN.1 for the task would be futile. It would 
be like trying to convert a steam locomotive to run
on roads.

I wrote a synthesizer for most of the IETF protocols
back in '92 which covered SMTP, NNTP, FTP and of course
HTTP. The data structure it used was pretty simple as
I recall - about ten pages in all. If folk are interested 
I might be able to find it.

		Phill

---

From: Marc Branchaud <[email-masked]>
Date: Fri, 06 Aug 1999 11:51:16 -0700

There are (at least) a couple of issues here:

1. Are ABNF/ASCII protocols enough?  Things like SMTP, FTP and HTTP are
fine protocols, but they are based on an ASCII command-response system. 
Things like SSL/TLS and IPSec didn't use an ASCII protocol for various
reasons, and so I doubt that ASCII is adequate.  BTW, someone sent me a
pointer to draft-cordell-messaging-00.txt which is essentially an ASCII
encoding for ASN.1 (a sort of AER).

2. We already have a lot of ASN.1 in IETF RFCs, and so I don't think
abandoning ASN.1 is a viable solution.  We're stuck with ASN.1 notation,
it seems, barring some drastic paradigm shift.  My thinking is we might
as well adapt that ASN.1 notation into something that maps (relatively)
easily into bits-on-the-wire.

I wasn't thinking of using this for ASCII-based protocols.  I don't
think ASN.1 is a good choice for that.

		M.

---

From: Bruce Greenblatt <[email-masked]>
Date: Fri, 06 Aug 1999 19:45:40 -0700

I'd point out that ABNF and ASCII have nothing to do with each other.  It
is just fine to define a binary protocol using ABNF.  I'd also note that it
is very helpful for the wire protocol to contain some sort of viewable
keywords for those of us that are unfortunate enough to have to view the
protocol.  I'm especially fond of the ABNF that Ryan Moats created for the
Tagged Index Object in the Common Indexing Protocol (but of course, I'm
biased).  This ABNF specifically allows for the inclusion of binary data,
as well as UTF-8 encoded characters...  So, I specifically disagree with
your point 2 below.  I can't think of anything that would be better than to
abandon ASN.1.  I don't think that there are any advantages to its use
versus ABNF.

>> I might be able to find it.
==============================================
Bruce Greenblatt
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Mon, 9 Aug 1999 10:32:18 -0400

I don't accept this case.

The priciple problem with ASN.1 is that there are enough people
who violently detest it that the syntax issue is continually
being revisited. We get this in PKIX about twice a year.

I certainly don't suggest rewriting ASN.1 protocols in ABNF
or any other formalism for that matter, just as I do not propose
to revisit the ABNF decision for HTTP.

Once a system is deployed it is a legacy system. It is futile
to revisit core design decisions. For the ABNF parser I wrote
I developed the formalism to match the practice and not vice-versa.

If one has the luxury of starting from scratch with no legacy
BOTH approaches (ABNF, ASN.1) strike me as defective. The designers
of SSL took the right decision in my view in choosing a formalism
which was very simple and had a direct mapping to a well supported
programming language.

Development of a formalism requires expertise but so does
programming. It is not as time consuming as some would suggest.
Certainly my experience suggests that attempting to re-use
ASN.1 is more time consuming than starting from scratch with
a less baroque approach.

Attempts to rewrite ASN.1 systems in ABNF and vice versa strike
me as equally pointless and profitless exercises.

The correct comparison to make in my view is with a defunct
programming language. I would not advise anyone to code a
new system in COBOL or FORTRAN (ASN.1) nor would I suggest
existing systems be rewritten in Java.

And of course there will always be people who claim COBOL
and FORTRAN are not defunct.

		Phill

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Marc Branchaud
> Sent: Friday, August 06, 1999 2:51 PM
> To: [email-masked]
> Subject: Re: ASN.1 for the Internet (was Re: Compressed data type for
> S/MIME)
>
>
>

---

From: Marc Branchaud <[email-masked]>
Date: Mon, 16 Aug 1999 15:25:38 -0700

There seems to be some strong opinions that an ASN.1-Internet
reconciliation is a pointless and futile task.  I can live with that,
but I'd like to try to explain my objective one more time before it gets
thrown out with the bath water.  (On top of that, this topic is a bit
off for S/MIME -- but things are slow these days anyway.)

My basic premises are these:

1. There are a bunch of people who use ASN.1.

2. There are a bunch of other people who don't like ASN.1 because it is
very difficult to look at some ASN.1 code and figure out what the bits
on the wire will look like.  (There may be many more people who don't
like ASN.1 for other reasons, but I'm not trying to deal with them
here.)

3. The people using ASN.1 would like to see their ASN.1-based protocols
widely adopted.

Given these premises (which weren't founded on any facts and may or may
not reflect any reality anywhere), it seems to me that if there were a
version of ASN.1 that was easier to interpret then the people in my
second premise would be happier and the goal in the third premise might
be more achievable.

It also seems to me that such an ASN.1 "lite" could be defined that
would still be standard ASN.1, especially if the PER rules were used.

So I'm not suggesting a Grand Unified Syntax that will bring peace to
the world.  I'm not trying to replace ABNF or S-expressions or
whatever-your-favorite-protocol-definition-language-is.  I'm just trying
to make ASN.1 easier to digest for people who haven't read X.whatever.  

Or am I the only one who thinks it's a bit weird that the IETF is
pushing protocols defined in ASN.1 without having an RFC that explains
how to interpret them?

		Marc