🚀 go-pugleaf

jccw@poobah.mitre.org (John C. C. White) writes:

>I seem to recall that there was some work going on regarding
>alternatives to the Basic Encoding Rules (BER), to provide a
>more compact (or at least different) transfer syntax. Can anyone 
>point me to some documents or people that can bring me up to
>speed on this?  Or tell me that I'm dreaming, and BER is all
>anyone will ever need?

This question is another good candidate for a FAQ.  ISO/IEC/CCITT is
in the process of progressing several alternatives to BER.

What is currently called known as ISO 8825 | X.209 (i.e., BER) is being 
renamed ISO 8825-1 | X.209-1.  Several new encoding rules are being
standardized, and will result in documents whose ISO and CCITT names end 
with -2, -3, etc., suffixes (e.g., ISO 8825-2).

The new encoding rules of ASN.1 ...

ISO 8825-2 | X.209-2 describe the Packed Encoding Rules of ASN.1 (PER).
PER is characterized by the fact that it results in much more compressed
encodings than either BER.  Unlike BER, PER is implicitly typed, and
it relies on the ASN.1 subtype information to minimize the size of encodings
(e.g., a type described as "INTEGER (12345675..12345678)" can be encoded in
PER using 2 bits, whereas with BER it requires 6 bytes.

ISO 8825-3 | X.209-3 describe the Canonical and Distinguished Encoding
Rules of ASN.1 (CER & DER).  These are derived from BER and are used in
encoding a message so that there is only one encoded value for a given
message.  For example, in BER a BOOLEAN is encoded as 0 if the value is
FALSE, and non-zero if it is TRUE.  CER & DER on the other hand, state
that if the value is TRUE, it must be encoded as a 1 (hence the name canonical
and distinguished).  So, with CER & DER there is a 1-1 mapping between
the ASN.1-described types and the encoded values, whereas BER gives
more flexibility.  So why two encoding rules to do 1-1 mappings?  DER caters
to applications that have a need for a single way to encode data using
definite length encoding, while CER caters to applications that have a need
for a single way to encode data using indefinite length encoding.

DER and CER are both Draft International Standards.  PER is a Committee Draft
that may progress to DIS status in the October/November timeframe.

There is another set of encoding rules, the Light Weight Encoding Rules
of ASN.1 (LWER) that is being considered for standardization.  Its is
intended to be must faster to encode PDUs in LWER than BER, at the expense
of potentially generating larger PDUs.  LWER is not getting as much attention
in ISO/IEC/CCITT as the other encoding rules.  Among the reasons for this is
that many question the need for such a set of encoding rules, and that there
is more urgent need for the other encoding rules.

=====================================|========================================
Bancroft Scott			     |		Open Systems Solutions, Inc.
609-987-9073			     |		Princeton, N.J.
=====================================|========================================

jccw@poobah.mitre.org (John C. C. White) writes:

>I seem to recall that there was some work going on regarding
>alternatives to the Basic Encoding Rules (BER), to provide a
>more compact (or at least different) transfer syntax. Can anyone 
>point me to some documents or people that can bring me up to
>speed on this?  Or tell me that I'm dreaming, and BER is all
>anyone will ever need?

>John White
>MITRE Bedford, Mass
>jccw@mitre.org

The JTC are working on a number of other Rules, which are all
derived from BER to improve the performance of the transfer syntax.
They are described in the Addenda/Amendments to IS8825/CCITT X.209.

The new sets are:

DER (Distinguished ER) which basically imposes transfer orderings on some
classes of fields

PER (Packed ER) which 'squeezes' down the BER patterns

LWER (light Weight ER) which is designed for faster processing, by requiring,
for example, that all strings start on word boundaries.

khiem@hpindda.cup.hp.com (Khiem Ho) writes:

|>The new encoding rules of ASN.1 ...
|...etc...
|>
|>ISO 8825-3 | X.209-3 describe the Canonical and Distinguished Encoding
|>Rules of ASN.1 (CER & DER).  These are derived from BER and are used in
|>encoding a message so that there is only one encoded value for a given
|>message.  For example, in BER a BOOLEAN is encoded as 0 if the value is
|>FALSE, and non-zero if it is TRUE.  CER & DER on the other hand, state
|>that if the value is TRUE, it must be encoded as a 1 (hence the name canonical
|>and distinguished).  So, with CER & DER there is a 1-1 mapping between
|>the ASN.1-described types and the encoded values, whereas BER gives
|>more flexibility.  So why two encoding rules to do 1-1 mappings?  DER caters
|>to applications that have a need for a single way to encode data using
|>definite length encoding, while CER caters to applications that have a need
|>for a single way to encode data using indefinite length encoding.
|>
|>DER and CER are both Draft International Standards.  PER is a Committee Draft
|>that may progress to DIS status in the October/November timeframe.
|...etc...

|There's canonical BER defined in X.509 for security. Does anyone has
|any info about this C-BER comparing to the CER/DER above, and if
|there's any implementation supporting C-BER for X.509-security
|applications?

The Distinguished Encoding Rules (DER) defined in the ISO 8825-3 | 
CCITT X.209-3 draft international standard is the same as that described 
in X.509, except:

1. DER has a clause that specifies how trailing zero bits are to be treated
   when the BIT STRING is defined using a NamedBitList, and when it isn't.

2. DER specifies that: "The encoding of values of the GeneralString type 
   (and its subtypes) shall generate escape sequences to designate and 
   invoke a new register entry only when the register entry for the character
   is different from that currently designated as G0, C0, or C1.  All 
   designations and invocations shall be into the G0 set or the C0 set".

   More work is required to cover shift and locking shift characters, etc.

3. DER specifies a canonical form for encoding GeneralizedTime.

As you can see, these three points close holes that are present in X.509's
canonical BER, so DER satisfies the canonical BER specified in X.509.

As far as DER implementations supporting X.509-security is concerned, anyone
interested in this should email me directly for information on commercial
products.

=====================================|========================================
Bancroft Scott			     |		Open Systems Solutions, Inc.
609-987-9073			     |		Princeton, N.J.
=====================================|========================================