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

From: Bancroft Scott <[email-masked]>
Date: Fri, 2 Jan 1998 13:55:25 -0500 (EST)

Christian Huitema wrote:

> Joerg, The extension mechanism that you describe does not work well with
> PER. In the case of PER, the decoder will encounter a bit saying that
> the element was extended.  This bit will be followed by a bit field with
> one bit for each optional element in the extended set. 

No, Christian, this is not how the extension mechanism in PER works.  You
are confusing how SETs and SEQUENCEs with components marked with OPTIONAL
or DEFAULT are encoded versus how extension additions are encoded. 

> If the decoder does
> not know the number of such elements, it will loose synchronization.
> Thus, a PER decoder that encounters an extension will most likely just
> give up. 

No.  The extensible fields are grouped together and are prefixed with
information used in determining how many extension addition values are
present.  The number of extensions present is 100% determinable by the
receiver even when none of the extensions are defined to the receiver. So,
the sender of a SEQUENCE value could have thirty fields defined, and the
receiver 10, and the receiver will know how to ignore the twenty
additional values.

> This points to another drawback of PER.  The encoding is extremely
> compact because it does away with any form of redondancy. This also
> means that wild errors, such as messages decrypted with the wrong key,
> are likely to generate semantically valid components. 

PER does do away with most forms of redundancy, but in practice this
rarely poses a problem.  In those cases where it is suspected that the
data may be mangled it is remedied by the inclusion of a single field at
the start of the application message that includes a constant value.  This
is far more efficient than having a tag or some other identifier in front
of each value, as is done in BER, and accomplishes the same thing. 
However, I have never seen this employed, for any such problems are in
practice easily detected during development or, at the latest, during
interoperability testing. 

> You can
> experience that by feeding random bits into, for example, a PER decoder
> for H.225.  About 1/4th of the time, you will obtain a valid decoding... 

No.  Aside from very tiny encodings (e.g., four, five bytes), PER encoded
messages are rarely successfully decoded if they have been mangled, due to
either a length being outside of the expected range, an integer having a
value outside its expected range, etc..  Even in the case where the
application is badly misbehaving by decrypting with the wrong key, say,
the resulting decoded data makes no sense, resulting in the problem being
detected by the application (e.g., signature check fails), or in protocol
violation being signalled. 

--------------------------------------------------------------------------
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: Kent Crispin <[email-masked]>
Date: Fri, 2 Jan 1998 12:17:18 -0800

> are confusing how SETs and SEQUENCEs with components marked with OPTIONAL
      ^^^^^^^^^
> or DEFAULT are encoded versus how extension additions are encoded. 

However, this and the deleted following discussion exactly illustrates 
the problem with asn.1 -- it is, to use your word, confusing. 

My last use of asn.1 was several years ago, implementing a protocol
library for the NASA Portable Batch System (PBS) using ISODE.  That
was a very simple use of asn.1, for what is clearly an application
level protocol, and I grant that once we had the protocol defined it
was relatively simple for me to make changes.  However, no one else on
the project could make those changes without going through an ugly
learning curve, and after I was pulled off the project I believe that
later versions of PBS threw away the asn.1 version, and changed to a
simple ascii protocol. 

Maintaining expertise in something as complex as asn.1 is a
significant overhead for most software engineers -- unless you want to
make a career of using it. 

-- 
Kent Crispin				"No reason to get excited",
[email-masked]			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html