[Cfrg] OER (Re: ASN.1 in IEEE 1609.2 (was Re: Curve selection revisited))

[Carsten Bormann <[e-mail]>]

On 29 Jul 2014, at 05:38, William Whyte <[e-mail]> wrote:

> Octet Encoding Rules, or OER

Many people here may not be familiar with this newest member of the growing family of ASN.1 encoding rules.  Until recently, OER was strictly domain-specific.  Now, it has been submitted to ITU-T and surfaced as X.696 (ISO/IEC 8825-7).

The original NTCIP document specifying OES has this to say:

> Annex A Justification for OER
> 
> (Informative)
> 
> During the development of the NTCIP, in 1995, the NEMA 3-TS Technical Committee began to learn about the Simple Network Management Protocol (SNMP) and Abstract Syntax Notation One (ASN.1). The committee liked the design of both SNMP and ASN.1, but was concerned about the massive bandwidth requirements that the SNMP solution imposed. As such, the committee set forth to establish a new protocol, called the Simple Transportation Management Protocol (STMP), which would meet the bandwidth requirements of intelligent transportation systems.
> 
> The STMP was designed around the concept of configuring message content at run-time, but prior to actual message use, and using more compact encoding rules. Unfortunately, the NEMA committee was unaware of ISO's development of Packed Encoding Rules (ISO PER), ISO 8825-2. Thus, instead of using ISO PER, NEMA developed their own encoding rules, which were limited to the needs of STMP. To further complicate the matter, NEMA also named their encoding rules Packed Encoding Rules (NEMA PER).
> 
> By 1998, several firms were implementing the STMP and the supporting encoding rules, and through this process, several ambiguities were noticed in the NEMA PER standard. Further, the Committee realized that some people were becoming confused by the two versions of PER. Finally, the committee was being asked to investigate an extension to STMP that would use fixed messages. Thus, the Committee conducted an investigation to determine whether the standard should be modified to use ISO PER, or if the existing standard (STMP) should simply be clarified.
> 
> After a detailed review of the issue, the Committee, in association with various NTCIP Working Groups that had since been established, decided to clarify the original specification due to the inherent complexity of the ISO PER.
> It also agreed that the long-term solution was to develop a separate document that would formally define these new encoding rules for all ASN.1 Types. Finally, it was decided that the name of the encoding rules should be changed in order to minimize confusion, and the committee decided upon the name "Octet Encoding Rules” because of the octet-aligned nature of the encoding. [...]

Different from BER, OER focuses on generating fixed-size fields when that fixed size can be derived from the ASN.1 type constraints.  It also recognizes the importance of unsigned integers*).  With some care, something resembling a classic IETF packet format could be written down in ASN.1 assuming OER (at least as long as everything is byte-aligned)**).

While BER is structurally self-describing (you can decode the structure of an ASN.1 BER object even without having the data definition at hand), for an OER object you do need the data definition to make any sense of it.  Generic tools cannot be written: implementations are specific to the data definition or need an interpreter for the ASN.1 language in which it is written (i.e., the modern variant, not the older dialect used in the IETF). This reliance on information from the data definition is not different from TLS notation or box notation, but might be surprising for those who think about ASN.1 in terms of BER.

The companies that supply ASN.1 tools love OER.  The market for commercial ASN.1 tools had been drying up when open-source ASN.1 tools became better and better.  OER presents new opportunities for commercial tools.  I’m sure they will know to avoid another “PER disaster”***).

Grüße, Carsten

*) (A pet peeve many of us have with BER is that it only supports signed integers, which are less interesting in many embedded applications.)

**) Hand-crafted packet formats will almost always win over generated ones unless the complexity is so high that shortcuts have to be taken in the handcrafting.

***) (Little known outside that community, bugs in the pretty much single-sourced ASN.1 PER tools almost sunk H.323 in the mid-90s).