From: Carl Ellison <cme@TIS.COM>
Date: Tue, 3 Oct 95 07:57:18 PDT
To: ses@tipper.oit.unc.edu
Subject: Re: De Re ASN.1 and encoding rules ( was Re: X.509,...)
In-Reply-To: <Pine.SOL.3.91.951002141516.6137B-100000@chivalry>
Message-ID: <9510031453.AA22371@tis.com>
MIME-Version: 1.0
Content-Type: text/plain


(my friend Tom is cc:'d as the Multics expert, re: the ref below)
-----BEGIN PGP SIGNED MESSAGE-----

>Date: Mon, 2 Oct 1995 17:13:21 -0700 (PDT)
>From: Simon Spero <ses@tipper.oit.unc.edu>

>Lets use 3DES as our example. We'll start with a naive specification:

[etc.]

You're starting down the same road I did in writing my example of how ASN.1
seduces you into bad design.  ..very good, but you stopped short.

[The PER sounds much better than BER -- but I've never seen PER before.  I
learned enough about ASN.1 to have decided it is a lost cause -- far easier
to let ASN.1 advocates talk to themselves while I go off to do something
independent and good.]

Back to the example.

>--
>LongLong ::= OCTET STRING (SIZE(8)) -- a long long is 8 bytes, er, long

Really?  There is an OCTET STRING (SIZE(8)) and you can make it a datatype?

I suppose you can make an OCTET STRING (SIZE(9)) too?

That can be really convenient.  You can have a tagged quantity (using the
top byte).  Alternatively, someone could define:

DesKey ::= SEQUENCE {
 encr BIT STRING (SIZE(1)), -- encrypt mode if 1, decrypt if 0
 value OCTET STRING (SIZE(8))
}

and now you can use DesKey as your data type with no bad effects and only
good ones (as far as the ASN.1 user is concerned).  Of course, the code to
pack/unpack just exploded.  So did the packet size (maybe, depending on
effort spent in pack/unpack) and so did the internal struct, probably.

[Truth in advertising: the example above is adapted from early Multics
where PL/I allowed you to do such nonsense and some programmer saw the
power of it -- so he used it in the file system, until he got caught.]

Lesson from this: there is a reason not to give a designer generality you
would not use in an actual implementation.

Anyway -- my example of ASN.1 abuse is along these lines but I won't
reproduce it here.  We can leave this as a parlor game for computer geeks.
:-)


>Here's the new definitions:
>
>--
>Long ::= OCTET STRING (SIZE(4))
>
>ThreeDes ::=SEQUENCE {
>	   IV SEQUENCE OF (SIZE(1..2) LONG,
>	   Key1 DesKey,
>	   Key2 DesKey OPTIONAL,
>	   Key3 DesKey OPTIONAL
>}

See -- ASN.1 is powerful in its seductiveness.  Even though you were trying
to convince me that it can be the same as my primitive example (and
therefore just as efficient), you couldn't resist using the power of the
generality to elaborate on the structure.

This is not a good feature of ASN.1.  This is its primary fault.  This is
why I call it a work of Satan.  (BER/DER helps in that evaluation, of
course).


>To be continued... (unless I get flamed off the list)

As I said, this could be a wonderful parlor game -- or list topic, if
people want to waste the time.  Think of it as the Crossword Puzzle page of
the cypherpunks on-line newspaper. :-)

 - Carl

+--------------------------------------------------------------------------+
|Carl M. Ellison      cme@tis.com    http://www.clark.net/pub/cme	   |
|Trusted Information Systems, Inc.   http://www.tis.com/                   |
|3060 Washington Road          PGP 2.6.2:  61E2DE7FCB9D7984E9C8048BA63221A2|
|Glenwood MD  21738         Tel:(301)854-6889      FAX:(301)854-5363       |
+--------------------------------------------------------------------------+

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMHFNJFQXJENzYr45AQFV2AP9H1/A5bY4H8C/Ms3dhHIPOWiLCYhqLzFR
qKdvQaBYvPDCrr8jXLwQhTogvzu/9gkZ2DwnXVya7MxEpyy+1A5WrO3Jlqu+6Euy
bBcl1idhoomMzmzOga/F7YasXsFkoZoSqNYQKX/ZKcFvEuDGrzohlBNV5ubDEL7G
E3hdsak0f2Y=
=cjU/
-----END PGP SIGNATURE-----