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

From: William Whyte <[email-masked]>
Date: Mon, 28 Jul 2014 23:38:27 -0400

Hi all,

> [Hannes Tschofenig]
>> PS: Regarding the ASN.1 format I am wondering whether the IEEE has done
>> some more detailed analysis of the over-the-wire and the software
>> implementation cost. This would be useful for us in the ACE working group.
>
> [Bob Moskowitz]
> Actually, I mispoke a bit on this.  ASN.1 can be a syntax to describe data.
> It is the BER that defines what is really in the object.  So 1609 as
> developing a task to create an ASN.1 discription of their format and the
> specific BER to create it.  ETSI will be much happier once this is done.

I'm the editor of 1609.2, which currently describes the data
structures in a TLS-like notation and is considering moving to ASN.1.
We've analysed both relative packet size and relative encoding speeds
with ASN.1 (with various different encoding rules) and with the
current encoding. The results are still a bit rough so I can't
distribute them publicly, but we anticipate that they'll be
publishable in a month or so. (I don't know if they're relevant to
this list -- let me know where else I should send them if this list
isn't the place). The high-level outcome, though, is that if you pick
a good set of encoding rules (Octet Encoding Rules, or OER, rather
than the BER/DER that's used in X.509 certs and bloats nested
structures by putting tag and length at every level), then encoding
speed and encoded size are competitive with the current 1609.2 custom
format -- slightly larger and very competitive in speed -- and we
understand ASN.1 has advantages in tool availability, maintainability,
extensibility, and completeness, as well as being preferred for ETSI
standards and for standards sponsored by USDOT.

I would put Bob's statements slighltly differently:
> ASN.1 can be a syntax to describe data.
ASN.1 is a language used to define data structures.
> It is the BER that defines what is really in the object.
The encoding rules (which there are many of, including BER but also
other more compact ones) describe the encoding and decoding for
transmission.
> So 1609 as
> developing a task to create an ASN.1 discription of their format and the
> specific BER to create it.
Yes -- we're creating an ASN.1 description of our structures, and
we're looking at which set of encoding rules it makes sense to specify
for use.

Hope this helps.

Cheers,

William

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 29 Jul 2014 09:06:05 +0200

On 29 Jul 2014, at 05:38, William Whyte <[email-masked]> 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).