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
It's syntax displays several properties:
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:
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
This encoding is not always optimal and often highly
Figure: Example Data Structure
If the content of file /etc/passwd is:
Then an instance of struct passwd at run-time would appear as in
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
A typical ASN.1 representation of this structure is shown in
#fn73#1534>. A more complex example is illustrated in #fnasn75#1535>.
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
Figure: ASN.1 version of C Data Structure
Note that this assumes the following about memory templates for
All objects occupy minimum space
Octet order is defined for the integer values
The above example shows 3 of the predefined objects in
A simple structure is introduced by the keyword
This consists of INTEGER and IA5String named sub
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.
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
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
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!
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
Sets, unordered lists of items typically require the
use of SET-Specific tags, to ensure each item can be
Wildcard types can be included into constructs using
<#1552#> ANY<#1552#> thus definitions can be made open-ended to
encompass later extensions.