Committed to connecting the world

ICTs for a Sustainable World #ICT4SDG

Introduction to ASN.1​

Main concepts

​ASN.1 is a formal notation used for describing data transmitted by telecommunications protocols, regardless of language implementation and physical representation of these data, whatever the application, whether complex or very simple.
Abstract Syntax Notation number One
is a standard that defines a formalism
for the specification of abstract data types.
The notation provides a certain number of pre-defined basic types such as: 
  • integers (INTEGER),
  • booleans (BOOLEAN),
  • character strings (IA5StringUniversalString...),
  • bit strings (BIT STRING),
  • etc.,
and makes it possible to define constructed types such as: 
  • structures (SEQUENCE),
  • lists (SEQUENCE OF),
  • choice between types (CHOICE),
  • etc.
Subtyping constraints can be also applied on any ASN.1 type in order to restrict its set of values.

Unlike many other syntaxes which claim to be extensible, ASN.1 offers extensibility which addresses the problem of, and provides support for, the interworking between previously deployed systems and newer, updated versions designed years apart.

ASN.1 sends information in any form (audio, video, data, etc.) anywhere it needs to be communicated digitally. ASN.1 only covers the structural aspects of information (there are no operators to handle the values once these are defined or to make calculations with). Therefore it is not a programming language.

ASN.1 definition can be contrasted to the concept in ABNF of "valid syntax", or in XSD of a "valid document", where the focus is entirely on what are valid encodings of data, without concern with any meaning that might be attached to such encodings. That is, without any of the necessary semantic linkages.

One of the main reasons for the success of ASN.1 is that this notation is associated with several standardized encoding rules such as the BER (Basic Encoding Rules), or more recently the PER (Packed Encoding Rules), which prove useful for applications that undergo restrictions in terms of bandwidth. These encoding rules describe how the values defined in ASN.1 should be encoded for transmission (i.e., how they can be translated into the bytes 'over the wire' and reverse), regardless of machine, programming language, or how it is represented in an application program. ASN.1's encodings are more streamlined than many competing notations, enabling rapid and reliable transmission of extensible messages -- an advantage for wireless broadband. Because ASN.1 has been an international standard since 1984, its encoding rules are mature and have a long track record of reliability and interoperability.
 
An ASN.1 definition can be readily mapped (by a pre-run-time processor) into a C or C++ or Java data structure that can be used by application code, and supported by run-time libraries providing encoding and decoding of representations in either an XML or a TLV format, or a very compact packed encoding format.
 
Tools on almost all operating systems support ASN.1. ASN.1 also supports popular programming languages such as Java, C and C++, as well as older ones including COBOL. As an example of ASN.1's universality, there are tools that have been ported to over 150 different computing platforms.
 
There are a lot of well-tested ASN.1 tools that have been used for a long time. Using such tools, there are less likely to be costly delays in bringing new products to market or, even worse, recalling products based on new code that hasn't been sufficiently tested for flaws.
 
ASN.1 is widely used in industry sectors where efficient (low-bandwidth, low-transaction-cost) computer communications are needed, but is also being used in sectors where XML-encoded data is required (for example, transfer of biometric information).

Case study

​Suppose a company owns several sales outlets linked to a central warehouse where stocks are maintained and deliveries start from. The company requires that its protocol have the following features:
  • the orders are collected locally at the sales outlets ;
  • they are transmitted to the warehouse, where the delivery procedure should be managed ;
  • an account of the delivery must be sent back to the sales outlets for following through the client's order.
This protocol can be specified with the two following ASN.1 modules:
-- Module sample (sample:01/2014)
-- See also the README file
-- See also the index of all ASN.1 assignments needed in this Recommendation

Module-order DEFINITIONS AUTOMATIC TAGS ::=
BEGIN

Order ::= SEQUENCE {header  Order-header,
                    items   SEQUENCE OF Order-line
}

Order-header ::= SEQUENCE {
  number   Order-number,
  date     Date,
  client   Client,
  payment  Payment-method
}

Order-number ::= NumericString(SIZE (12))

Date ::= NumericString(SIZE (8)) -- MMDDYYYY
                      

Client ::= SEQUENCE {
  name      PrintableString(SIZE (1..20)),
  street    PrintableString(SIZE (1..50)) OPTIONAL,
  postcode  NumericString(SIZE (5)),
  town      PrintableString(SIZE (1..30)),
  country   PrintableString(SIZE (1..20)) DEFAULT default-country
}

default-country PrintableString ::= "France"

Payment-method ::= CHOICE {
  check        NumericString(SIZE (15)),
  credit-card  Credit-card,
  cash         NULL
}

Credit-card ::= SEQUENCE {
  type         Card-type,
  number       NumericString(SIZE (20)),
  expiry-date  NumericString(SIZE (6))-- MMYYYY -- 
}

Card-type ::= ENUMERATED {
  cb(0), visa(1), eurocard(2), diners(3), american-express(4)}

Order-line ::= SEQUENCE {
  item-code  Item-code,
  label      Label,
  quantity   Quantity,
  price      Cents
}

Item-code ::= NumericString(SIZE (7))

Label ::= PrintableString(SIZE (1..30))

Quantity ::= CHOICE {
  unites        INTEGER,
  millimetres   INTEGER,
  milligrammes  INTEGER
}

Cents ::= INTEGER

Delivery-report ::= SEQUENCE {
  order-code  Order-number,
  delivery    SEQUENCE OF Delivery-line
}

Delivery-line ::= SEQUENCE {item      Item-code,
                            quantity  Quantity
}

END



Protocol DEFINITIONS AUTOMATIC TAGS ::=
BEGIN

IMPORTS
  Order, Delivery-report, Item-code, Quantity, Order-number
    FROM Module-order;

PDU ::= CHOICE {
  question
    CHOICE {question1  Order,
            question2  Item-code,
            question3  Order-number,
            ...},
  answer
    CHOICE {answer1  Delivery-report,
            answer2  Quantity,
            answer3  Delivery-report,
            ...}
}

END

Applications fields

​Originally standardized to specify data protocols in an open system interconnection (OSI) environment, ASN.1 has imposed its intrinsic advantages in many other popular fields.

A lot of application fields of ASN.1 are presented in Chapter 7 of the book "ASN.1. Communication between Heterogeneous Systems", byOlivier Dubuisson (© 1999).

Other application fields are also listed here. ASN.1 is a critical part of our daily lives; it's everywhere, but it works so well it's invisible.

State of standardization

​ASN.1 was first standardized in 1984 by the CCITT (International Telegraph and Telephone Consultative Committee, now called ITU-T,International Telecommunication Union - Telecommunication Standardization Sector) under the name "X.409 Recommendation". A little later, ISO (International Organization for Standardization) chose to adopt this notation and split this recommendation into two separate documents: the abstract syntax (ASN.1) and the encoding rules (BER). In 1985, the CCITT decided to collaborate with ISO on these two documents.

In 1987, ISO published these documents as 8824 and 8825 (only three new types of character strings are added). In 1988, ISO merged with the IEC (International Electrotechnical Commission) forming a joint technical committee called ISO/IEC JTC 1, which is now in charge of the ASN.1 standard.

For its Blue Book, in 1989, the CCITT published the X.208 and X.209 recommendations: a new release for the ASN.1 standard, which was provided with extensions resulting from a common work with the JTC 1.

For the last version (available since end of 2008), the ISO 8824 standard was split into four parts: 
As far as encoding rules are concerned, ISO 8825 standard was split into seven parts:

ASN.1:2002 and later editions are, from now on, strongly recommended. The 1990-release is no longer available.

​Presented during the January 1999 ASN.1 meeting, the encoding control notation (ECN) allows specifiers to define their own encoding rules by referencing standardized encoding rules and modifying some of their characteristics, or even to set up completely new ones.

ASN.1 has a long record of accomplishment, having been in use since 1984. It has evolved over time to meet industry needs, such as PER support for the bandwidth-constrained wireless industry and XML support for easy use of common Web browsers.