Jump to content

ASN.1

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by GreenC bot (talk | contribs) at 02:07, 17 November 2016 (1 archive template merged to {{webarchive}} (WAM)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Abstract Syntax Notation One (ASN.1) is a standard and notation that describes rules and structures for representing, encoding, transmitting, and decoding data in telecommunications and computer networking. The formal rules enable representation of objects that are independent of machine-specific encoding techniques. Formal notation makes it possible to automate the task of validating whether a specific instance of data representation abides by the specifications. In other words, software tools can be used for the validation.[1]

ASN.1 is a joint standard of the International Organization for Standardization (ISO), International Electrotechnical Commission (IEC), and International Telecommunication Union Telecommunication Standardization Sector ITU-T, originally defined in 1984 as part of CCITT X.409:1984. ASN.1 moved to its own standard, X.208, in 1988 due to wide applicability. The substantially revised 1995 version is covered by the X.680 series. The latest revision of the X.680 series of recommendations is the 5.0 Edition, published in 2015.

ASN.1 in transfer

A source of observation may generate data that is needed at another location for processing. For example, a radio telescope in outer space might produce voluminous signal data that cannot be processed locally. The recording and processing systems may be very different in nature, and may even be produced by different vendors. A consistent mechanism is needed to record, transmit, and receive data across diverse systems.

ASN.1 defines the abstract syntax of information but does not restrict the way the information is encoded. Various ASN.1 encoding rules provide the transfer syntax (a concrete representation) of the data values whose abstract syntax is described in ASN.1.

The standard ASN.1 encoding rules include:

ASN.1 together with specific ASN.1 encoding rules facilitates the exchange of structured data, particularly between application programs separated by networks, by describing data structures in a way that is independent of machine architecture and implementation language.

Application layer protocols such as X.400 electronic mail, X.500 and Lightweight Directory Access Protocol (LDAP) directory services, H.323 (VoIP), Kerberos, BACnet and simple network management protocol (SNMP) use ASN.1 to describe the protocol data units (PDU) they exchange. The access and non-access strata of the Universal Mobile Telecommunications System (UMTS) also use ASN.1 extensively. There are many other application domains of ASN.1.[2]

A particularly useful application of ASN.1, Fast Infoset - an international standard introduced in 2005 - specifies a binary serialization encoding format for the XML Information Set (XML Infoset) that is more efficient than the text-based XML format.[citation needed]

Example

Data structures of (a fictitious) Foo Protocol defined using the ASN.1 notation: 

FooProtocol DEFINITIONS ::= BEGIN

    FooQuestion ::= SEQUENCE {
        trackingNumber INTEGER,
        question       IA5String
    }

    FooAnswer ::= SEQUENCE {
        questionNumber INTEGER,
        answer         BOOLEAN
    }

END

This could be a specification published by creators of Foo protocol. Conversation flows, transaction interchanges, and states are not defined in ASN.1, but are left to other notations and textual description of the protocol.

Assuming a message that complies with the Foo protocol and that will be sent to the receiving party, this particular message (protocol data unit (PDU)) is: 

myQuestion FooQuestion ::= {
    trackingNumber     5,
    question           "Anybody there?"
}

ASN.1 supports constraints on values and sizes, and extensibility. The above specification can be changed to 

FooProtocol DEFINITIONS ::= BEGIN

    FooQuestion ::= SEQUENCE {
        trackingNumber INTEGER(0..199),
        question       IA5String
    }

    FooAnswer ::= SEQUENCE {
        questionNumber INTEGER(10..20),
        answer         BOOLEAN
    }

    FooHistory ::= SEQUENCE {
        questions SEQUENCE(SIZE(0..10)) OF FooQuestion,
        answers   SEQUENCE(SIZE(1..10)) OF FooAnswer,
        anArray   SEQUENCE(SIZE(100))  OF INTEGER(0..1000),
        ...
    }

END

The changes above are that trackingNumbers are now constrained to values 0 to 199, questionNumbers 10 to 20. The size of the questions array can be between 0 and 10 elements, with the answers array between 1 and 10 elements. The anArray field is a fixed length 100 element array of integers that must be in the range 0 to 1000. The '...' extensibility marker means that the FooHistory message specification may have additional fields in a future versions of the specification; systems compliant with one version should be able to receive and transmit transactions from a later version, though able to process only the fields specified in the earlier version. Good ASN.1 compilers will generate (in C, C++, Java, etc.) source code that will automatically check that transactions fall within these constraints. Transactions that violate the constraints will not be accepted from, or presented to, the application. Constraint management in this layer significantly simplifies protocol specification because the applications will be protected from constraint violations, removing risk and cost from the development. Many other serialisation technologies lack this feature.

To send the myQuestion message through the network, the message is encoded as a string of bits. ASN.1 defines various algorithms to accomplish that task, called Encoding Rules, of which a number are defined. Among the simplest is Distinguished Encoding Rules (DER).

The Foo protocol specification should explicitly name one set of encoding rules to use, so that users of the Foo protocol know which one they should use and expect.

Example encoded in DER

Below is the data structure shown above encoded in DER format (all numbers are in hexadecimal): 

30 — type tag indicating SEQUENCE
13 — length in octets of value that follows
02 — type tag indicating INTEGER
01 — length in octets of value that follows
05 — value (5)
16 — type tag indicating IA5String 
     (IA5 means the full 7-bit ISO 646 set, including variants, 
      but is generally US-ASCII)
0e — length in octets of value that follows
41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f — value ("Anybody there?")

(Note: DER uses a pattern of type-length-value triplets, and uses well known byte constants for encoding type tags)

The result is the string of 21 octets (8-bit bytes): 

30 13 02 01 05 16 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f

The scope of ASN.1 and DER ends here. It is possible to transmit the encoded message to the recipient by any means (Transmission Control Protocol (TCP) or any other protocol). The party should be able to decode the octets from the DER.

Example encoded in XER

Alternatively, it is possible to encode the same ASN.1 data structure with XML Encoding Rules (XER) to achieve greater human readability "over the wire". It would then appear as the following 108 octets, (space count includes the spaces used for indentation): 

<FooQuestion>
    <trackingNumber>5</trackingNumber>
    <question>Anybody there?</question>
</FooQuestion>

Example encoded in PER (unaligned)

Alternatively, if Packed Encoding Rules are employed, the following 122 bits (16 octets amount to 128 bits, but here only 122 bits carry information and the last 6 bits are merely padding) will be produced: 

01 05 0e 83 bb ce 2d f9 3c a0 e9 a3 2f 2c af c0

In this format, type tags for the required elements are not encoded, so it cannot be parsed without knowing the expected schemas used to encode. Additionally, the bytes for the value of the IA5String are packed using 7-bit units instead of 8-bit units, because the encoder knows that encoding an IA5String byte value requires only 7 bits. However the length bytes are still encoded here, even for the first integer tag 01 (but a PER packer could also omit it if it knows that the allowed value range fits on 8 bits, and it could even compact the single value byte 05 with less than 8 bits, if it knows that allowed values can only fit in a smaller range).

Note also that the last 6 bits in the encoded PER are padded with null bits in the 6 least significant bits of the last byte c0 : these extra bits may not be transmitted or used for encoding something else if this sequence is inserted as a part of a longer unaligned PER sequence.

This means that unaligned PER data is essentially an ordered stream of bits, and not an ordered stream of bytes like with aligned PER, and that it will be a bit more complex to decode by software on usual processors because it will require additional contextual bit-shifting and masking and not direct byte addressing (but the same remark would be true with modern processors and memory/storage units whose minimum addressable unit is larger than 1 octet). However modern processors and signal processors include hardware support for fast internal decoding of bit streams with automatic handling of computing units that are crossing the boundaries of addressable storage units (this is needed for efficient processing in data codecs for compression/decompression or with some encryption/decryption algorithms).

If alignment on octet boundaries was required, an aligned PER encoder would produce: 

01 05 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f

(in this case, each octet is padded individually with null bits on their unused most significant bits).

ASN.1 versus other data structure definition schemes

Since it is commonly used for defining messages for communication protocols, ASN.1, with its associated encoding rules, results in a binary encoding.

Other communication protocols, such as Internet protocols HTTP and SMTP, define messages using text tags and values, sometimes based on the Augmented Backus-Naur form (ABNF) notation. The definition also defines the encoding, which is in text.

There has been much debate over the two approaches, and both have their merits; the ASN.1 approach is believed to be more efficient,[citation needed] and with Packed Encoding Rules, certainly provides a more compact encoding. The textual approach is claimed to be easier to implement (through creation and parsing of text strings) and easier to debug with only a text editor. In the case of the Megaco protocol, consensus between the two points of view was not reached and so two encodings, one based on ASN.1 and one on ABNF, were defined.

The ASN.1 XML Encoding Rules (XER) attempts to bridge the gap by providing a textual encoding of data structures defined using ASN.1 notation. Generic String Encoding Rules were also defined for the sole purpose of presenting and inputting data to/from a user.

Encoding Control Notation (ECN)

Main article: Encoding Control Notation

The Encoding Control Notation (ECN) is a notation to specify specific encodings of ASN.1 types. ECN is useful to describe legacy protocols in ASN.1. It is possible to specify only the encoding of some types and then complete with a standard encoding rules (usually unaligned PER).

ASN.1 Information Object Class

Main article: Information Object Class (ASN.1)

Information Object Classes is a concept used in ASN.1 to address specification needs similar to the ones addressed by CORBA/IDL specifications.

Using ASN.1 in practice

One may use an ASN compiler which takes as input an ASN.1 specification and generates computer code (for example in the language C) for an equivalent representation of the data structures. This computer code, together with supplied run-time libraries, can then convert encoded data structures to and from the computer language representation. Alternatively, one can manually write encoding and decoding routines.

Standards

Standards describing the ASN.1 notation:

Standards describing the ASN.1 encoding rules:

Comparison of ASN.1 tools

This table provides basic comparisons for ASN.1 tools, including their licenses, the runtime they support, the possibility to compile ASN.1 descriptions into runtime-compatible code, and the support for transfer encodings.

Name License Runtime Compiler Support for BER and/or DER Support for PER
OSS ASN.1 Tools (OSS Nokalva, Inc.) Proprietary C, C++, C#, Java Yes Yes
ASN1C Compiler (Objective Systems, Inc.) Proprietary C, C++, C#, Java Yes Yes
Asn1Compiler (uniGone) Proprietary Java, C# Yes Yes
MARBEN ASN.1 Tools (Marben Products) Proprietary C, C++, Java Yes Yes
ffasn1c Proprietary C Yes Yes
asn1c BSD C C Yes Yes
asn1scc GPL, runtime exception C, Ada F#, ANTLR Yes Yes
snacc GPL C C, C++ Yes
eSNACC GPL C, C++ C Yes Yes
III ASN.1 Mozilla C++ C++ Yes Yes
libtasn1 LGPL ANSI C99 C Yes
pyasn1 BSD Python asn1ate (Python) Yes
dpkt BSD Python none Yes
libmich GPL Python Python Yes Yes
ASN1js BSD JavaScript none Yes
asn1js MIT JavaScript none Yes
node-asn1 MIT JavaScript none Yes
ASN1.js MIT JavaScript none Yes
ASN1s GPL Java Java/Antlr Yes
jASN1 LGPL Java Java Yes
openASN.1 LGPL Java Java Yes Yes
asn1forj GPL Java Yes
JAC GPL Java Yes
JASN GPL Java Yes
Binary Notes Apache Java, .NET XSLT Yes Yes
arc BSD Java javacc/Java
Cryptix BSD Java SableCC
Legion of The Bouncy Castle MIT, MIT X11 Java, C# none Yes
Apache Harmony Apache Java
Erlang ASN.1 Apache Erlang Erlang Yes Yes
GCDC ASN.1 Apache Java none Yes
OCaml ASN.1 combinators BSD OCaml Yes

See also

References

  1. ^ Using ASN.1 Archived August 1, 2012, at the Wayback Machine (Abstract Syntax Notation 1): A Data Description Language
  2. ^ ITU-T website - Uses of ASN.1

This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.

Retrieved from "https://en.wikipedia.org/w/index.php?title=ASN.1&oldid=749956958"