ASN.1

ASN.1
Abstract Syntax Notation One
Status	In force; supersedes X.208 and X.209 (1988)
Year started	1984
Latest version	(02/21) February 2021
Organization	ITU-T
Committee	Study Group 17
Base standards	ASN.1
Related standards	X.208, X.209, X.409, X.509, X.680, X.681, X.682, X.683
Domain	cryptography, telecommunications
Website	https://www.itu.int/rec/T-REC-X.680/

Abstract Syntax Notation One (ASN.1) is a standard interface description language (IDL) for defining data structures that can be serialized and deserialized in a cross-platform way. It is broadly used in telecommunications and computer networking, and especially in cryptography.

Protocol developers define data structures in ASN.1 modules, which are generally a section of a broader standards document written in the ASN.1 language. The advantage is that the ASN.1 description of the data encoding is independent of a particular computer or programming language. Because ASN.1 is both human-readable and machine-readable, an ASN.1 compiler can compile modules into libraries of code, codecs, that decode or encode the data structures. Some ASN.1 compilers can produce code to encode or decode several encodings, e.g. packed, BER or XML.

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

RFC 4120Basic Encoding RulesSecure authentication WiMAX 2Wide Area Networks Intelligent NetworkThe ITU Q.1200 Recommendation SeriesTelecommunications and computer networking X2AP Basic Aligned Packed Encoding Rules Lawful Interception (LI) Handover InterfaceETSI TS 102 232-1Lawful Interception

ASN.1 is closely associated with a set of encoding rules that specify how to represent a data structure as a series of bytes. The standard ASN.1 encoding rules include:

ASN.1 Encoding Rules

Encoding rules	Object identifier		Specification	Unit of serialization	Encoded elements discernable without foreknowledge of specification	Octet aligned	Encoding control	Description
	Dotted	Internationalized resource identifier</span>"}]],"parts":[{"template":{"target":{"wt":"abbr","href":"./Template:Abbr"},"params":{"1":{"wt":"IRI"},"2":{"wt":"Internationalized resource identifier"}},"i":0}}]}'>IRI
Basic Encoding Rules (BER)	2.1.1	/Joint‑T/ASN.1/Basic-Encoding	ITU X.690	Octet	No	The first specified encoding rules. Encodes elements as tag-length-value (TLV) sequences. Typically provides several options as to how data values are to be encoded. This is one of the most flexible encoding rules.
Distinguished Encoding Rules (DER)	2.1.2.1	/Joint‑T/ASN.1/BERYes	‑ISO‑Derived/CanonicalYes	‑ITUNo	‑ISO‑Encoding/Basic/Aligned	ITU X.691	Bit	No	Encodes values on bits, but if the bits encoded are not evenly divisible by eight, padding bits are added until an integral number of octets encode the value.
Canonical Packed Encoding Rules Unaligned (CPER-U)	2.1.3.1.1	/Joint‑T/ASN.1/PackedNo	‑ITUNo	‑ISO‑Encoding/Basic	ITU X.693	Character	ECN	Encodes ASN.1 data as XML.
Canonical XML Encoding Rules (CXER)	2.1.5.1	/Joint‑T/ASN.1/XMLYes	‑ITUYes	‑ISO‑Encoding/Basic	ITU X.696	Octet	No	A set of encoding rules that encodes values on octets, but does not encode tags or length determinants like the BER does. Data values encoded using the OER often look like those found in "record-based" protocols. The OER were designed to be easy to implement and to produce encodings more compact than those produced by the BER. In addition to reducing the effort of developing encoder/decoders, the use of OER can decrease bandwidth utilization (though not as much as the PER), save CPU cycles, and lower encoding/decoding latency. ITU X.696 OER is derived from a largely-compatible "OER" defined in NEMA's NTCIP 1102. NEMA's OER is in turn a clarified and expanded version of the unfortunately-named NEMA Packed Encoding Rules (NEMA PER).
Canonical Octet Encoding Rules (COER)	2.1.6.1	/Joint‑T/ASN.1/OERYes	Yes	RFC 3641	Character	RFC 4792	Intended to represent encoded data to the user or input data from the user, in a very straightforward format similar to the ASN.1's value notation. GSER was originally designed for the Lightweight Directory Access Protocol (LDAP) and is rarely used outside of it. RFC 4910	Character	RFC 4911	XML format designed for the Lightweight Directory Access Protocol (LDAP).
BACnet Encoding Rules (BACnetER)			ASHRAE 135 ISO 16484-5	Octet	ECN	Encodes elements as tag-length-value (TLV) sequences like the Basic Encoding Rules (BER) does. Example messages can be found in Karg (2012); Karg also maintains an open-source implementation of a BACnet stack, in which code for reading and writing this format can be found.
Signalling Specific Encoding Rules (SER)			France Telecom R&D Internal Document	Octet	No	Used primarily in telecommunications related protocols, such as GSM and SS7. Designed to produce an identical encoding from ASN.1 that previously existing protocols not specified in ASN.1 would produce.
Lightweight Encoding Rules (LWER)			Internal document by INRIA.	Memory Word		No	No	Definition of these encoding rules were a byproduct of INRIA's work on the Flat Tree Light Weight Syntax (FTLWS).

ASN.1 recommendations provide a number of predefined encoding rules. If none of the existing encoding rules are suitable, the Encoding Control Notation (ECN, X.692) provides a way for a user to define his or her own customized encoding rules.

Privacy-Enhanced Mail (PEM) encoding is entirely unrelated to ASN.1 and its codecs, but encoded ASN.1 data, which is often binary, is often PEM-encoded so that it can be transmitted as textual data, e.g. over SMTP relays, or through copy/paste buffers.

ASN.1 language and encoding specifications do not specify details such as what filename extension to use when a chunk of data is stored as a file on a computer. Nevertheless, some conventions have arisen:

• ASN.1-language text: extensions of .asn1 and .all have been used for general files. .asn has been used for files only containing module definitions and .prt for files only containing value definitions.
• BER-encoded data: .ber has been used. There is also a proposed MIME type application/ber-stream which includes a protocol parameter specifying an associated OID.
• DER-encoded data: .der. For DER-encoded X.509 certificates, .cer and .crt in addition to .der. The MIME type application/x-x509-ca-cert is specifically for DER-encoded certificates, not general DER data.
• Other encoded data: asn1c sample files use .xer for XER, .per for PER, and .coer for COER.

This is an example ASN.1 module defining the messages (data structures) of a fictitious Foo Protocol:

To send the myQuestion message through the network, the message is serialized (encoded) as a series of bytes using one of the encoding rules. 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.

The above is an example of X.681, specifically of the ObjectAssignment construct.

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

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

DER is a type–length–value encoding, so the sequence above can be interpreted, with reference to the standard SEQUENCE, INTEGER, and IA5String types, as follows:

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?")

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):

Alternatively, if Packed Encoding Rules Unaligned 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).

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).

For comparison, Packed Encoding Rules Aligned produces instead:

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

This format is octet-aligned. In this case, each octet is padded individually with null bits on their unused most significant bits.

Most of the tools supporting ASN.1 do the following:

• parse the ASN.1 files,
• generates the equivalent declaration in a programming language (like C or C++),
• generates the encoding and decoding functions based on the previous declarations.

A list of tools supporting ASN.1 can be found on the ITU-T Tool web page.

• ASN1 Play
• ASN1 Web Tool (very limited)
• ASN1 Playground (sandbox)
• ASN.1 JavaScript decoder

ASN.1 is similar in purpose and use to Google Protocol Buffers and Apache Thrift, which are also interface description languages for cross-platform data serialization. Like those languages, it has a schema (in ASN.1, called a "module"), and a set of encodings, typically type–length–value encodings. Unlike them, ASN.1 does not provide a single and readily usable open-source implementation, and is published as a specification to be implemented by third-party vendors. However, ASN.1, defined in 1984, predates them by many years. It also includes a wider variety of basic data types, some of which are obsolete, and has more options for extensibility. A single ASN.1 message can include data from multiple modules defined in multiple standards, even standards defined years apart.

ASN.1 also includes built-in support for constraints on values and sizes. For instance, a module can specify an integer field that must be in the range 0 to 100. The length of a sequence of values (an array) can also be specified, either as a fixed length or a range of permitted lengths. Constraints can also be specified as logical combinations of sets of basic constraints.

Values used as constraints can either be literals used in the PDU specification, or ASN.1 values specified elsewhere in the schema file. Some ASN.1 tools will make these ASN.1 values available to programmers in the generated source code. Used as constants for the protocol being defined, developers can use these in the protocol's logic implementation. Thus all the PDUs and protocol constants can be defined in the schema, and all implementations of the protocol in any supported language draw upon those values. This avoids the need for developers to hand code protocol constants in their implementation's source code. This significantly aids protocol development; the protocol's constants can be altered in the ASN.1 schema and all implementations are updated simply by recompiling, promoting a rapid and low risk development cycle.

If the ASN.1 tools properly implement constraints checking in the generated source code, this acts to automatically validate protocol data during program operation. Generally ASN.1 tools will include constraints checking into the generated serialization / deserialization routines, raising errors or exceptions if out-of-bounds data is encountered. It is complex to implement all aspects of ASN.1 constraints in an ASN.1 compiler. Not all tools support the full range of possible constraints expressions. XML schema and JSON schema both support similar constraints concepts. Tool support for constraints varies. Microsoft's xsd.exe compiler ignores them.

Some ASN.1 tools are able to translate between ASN.1 and XML schema (XSD). The translation is standardised by the ITU. This makes it possible for a protocol to be defined in ASN.1, and also automatically in XSD. Thus it is possible (though perhaps ill-advised) to have in a project an XSD schema being compiled by ASN.1 tools producing source code that serializes objects to/from JSON wireformat. A more practical use is to permit other sub-projects to consume an XSD schema instead of an ASN.1 schema, perhaps suiting tools availability for the sub-projects language of choice, with XER used as the protocol wireformat.

OSS Nokalva offers a tool for converting a JSON data object or a JSON schema into an ASN.1 definition. There is not yet a tool for generating a JSON schema describing the JER-encoded structure of an ASN.1 data structure.

OSS Nokalva also offers a tool for converting a Protocol Buffers schema into an ASN.1 definition.

Many programming languages define language-specific serialization formats. For instance, Python's "pickle" module and Ruby's "Marshal" module. These formats do not require a schema. They are generally language-specific, which makes them easier to use in ad hoc storage scenarios, but inappropriate for communications protocols.

JSON and XML similarly do not require a schema, making them easy to use. They are also both cross-platform standards that are broadly popular for communications protocols, particularly when combined with a JSON schema or XML schema.

ASN.1 is visually similar to Augmented Backus-Naur form (ABNF), which is used to define many Internet protocols like HTTP and SMTP. However, in practice they are quite different: ASN.1 defines a data structure, which can be encoded in various ways (e.g. JSON, XML, binary). ABNF, on the other hand, defines the encoding ("syntax") at the same time it defines the data structure ("semantics"). ABNF tends to be used more frequently for defining textual, human-readable protocols, and generally is not used to define type–length–value encodings.

ASN.1 is also visually similar to CSN.1. However, CSN.1 also defines the encoding of an object, specifically on the bit level.

• X.690
• Information Object Class (ASN.1)
• Presentation layer