ASN.1 Principles

ASN.1 or Abstract Syntax Notation number 1 is a presentation transfer syntax used by application layer protocols for representation of the information exchanged between application entities. It specifies both high and (in practice) low-level structure of actual data on the network. High level information: application specific data- structuring and value constraints. In a ;SPM_quot;tuned;SPM_quot; context-specific way, applications can define complex structures, pass data or carry out transactions regardless of underlying differences such as byte-order or language constraints. Low level information: a machine-independent encoding scheme. although there is the possibility of divergent encoding schemes e.g. encrypted, in practice CCITT aligned standards are using a common octet level encoding method. It's syntax displays several properties:

The Notation is BNF (Backus Naur Form) defined. It forms a self-consistent and testable grammar which allows specification to be provable and testable.
By sticking to the production rules defined within the ASN.1 BNF, all valid instances can be produced.
Unlike BNF, which is typically used to present language grammars or systems without considering actual transfer of data ASN.1 actually defines the encodings of its objects. when reduced to its lowest form, all legal ASN.1 structure is an octet stream, a sequence of octets of data.
The encoding is defined to be Language, Host and Network independent.
This encoding is not always optimal and often highly context specific.

It is important to note that ASN.1 is BNF-defined but is not BNF itself. when reading the ASN.1 specification be sure to differentiate between them. For example, consider the following fragment of 'C' code which shows the definition of a simple data structure that could be used to represent the contents of a line in /etc/passwd, as in figure #fn71#1520>. This data structure consists of a series of pointers to strings, and embedded integers. At run-time a given instance of this structure would look like this:

#figure1521#
Figure: Example Data Structure

If the content of file /etc/passwd is: verbatim47 Then an instance of struct passwd at run-time would appear as in figure #fn72#1524>.

#figure1525#
Figure: Data Structure at runtime

Assuming that the separate field sizes were as on a typical 32-but RISC architecture machine.

char * ptr is 4 bytes
int is 4 bytes
structure is not 'contiguous' memory

Note:

size of structure is machine dependent
what is the size of a (char*) pointer?
what is the size of an int?
encoding of values is machine dependent
strings are null terminated

A typical ASN.1 representation of this structure is shown in #fn73#1534>. A more complex example is illustrated in #fnasn75#1535>.

#figure1536#
Figure: ASN.1 version of C Data Structure

Note that this assumes the following about memory templates for objects:

All objects occupy minimum space
Octet order is defined for the integer values Defined Objects The above example shows 3 of the predefined objects in ASN.1.
A simple structure is introduced by the keyword SEQUENCE
This consists of INTEGER and IA5String named sub objects.
There is one Printable String object.
There is an OPTIONAL component.
Comments are embedded into the definition and layout is used just like in normal programming languages to delimit and aid 'parsing' of the structure.
Unlike most languages ASN.1 has a rich set of primitive types and few construction types.
This is because the constraints of Open systems oriented networking require that the notation be able to control use of network or technology specific objects as tightly as possible.
Most construction types in programming languages are simply ;SPM_quot;user-friendly;SPM_quot; variations or abstractions of simple types like arrays or sets.
These can be built up quite easily in ASN.1, but the definition of primitive objects that conform to interworking standards requires central control,
The notation provides as many defined types as possible, and facilities for new definitions and extensions have been made.
IA5String is a type which defines Objects of any length, but consisting only of characters in the IA5 alphabet. The 'C' definition didn't actually constrain the values in this way, but a Hard-Typed language such as Pascal could easily have done so.

#table1541#
Table: ASN Base Data Types

The list in #fn74#1547> has only two construction types: the SET and the SEQUENCE. using these along with a MACRO notation and a CHOICE selector arbitrarily complex structures can be built up. o Sub-types and ranges can also be defined from the primitive types allowing finer control of the value of the primitive elements. o The use of named types also providing some clarity for readers since names like T61String and Videotex String don't really tell you much about the context. o By its nature ASN.1 can be ambiguous. Although definitions can carry a lot of tagging and identification this increases the volume of transmitted octets hugely. o Typically reduced definitions are used where the context can define the encoding of following objects. This is not without it's dangers, and you should be very careful to determine whether a piece of ASN.1 defines something of global or localized significance. o Annexe A to CCITT X/409 is a guide for the use of ASN.1, which can help avoid creating such ambiguities. Example: an ASN.1 definition for autotellers Here is a small set of ASN.1 definitions for objects which might plausibly be exchanged during the use of high street cash dispensers, assuming anyone was rash enough to attach them to an OSI network!

#figure1548#
Figure: Example ASN Specification- Cash Dispenser

New Types are defined using an ;SPM_quot;overloading;SPM_quot; facility that re-defines the predefined types for this application thus defining application wide types which have global significance. -e.g. PinType
New UNIVERSAL types are defined by international agreement and cannot be pre-empted, but private and application specific types can be created at will.
Where context permits the use of IMPLICIT types helps to reduce the coding overheads, the context will implicitly define the object so a distinct marker is not required.
Sets, unordered lists of items typically require the use of SET-Specific tags, to ensure each item can be discriminated.
Wildcard types can be included into constructs using <#1552#> ANY<#1552#> thus definitions can be made open-ended to encompass later extensions.