ASN.1

Key takeaways

ASN.1 belongs to science; place it in that map before memorising details.
Learn the definition first, then one example that makes the definition concrete.
Connect ASN.1 to a quantity you can measure, compute or draw — that is where exam questions come from.
Reproduce the core statement of ASN.1 from memory before moving on to harder problems.

Reference excerpt

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.

Structure X.680 defines the basic lexical items of the ASN.1 language (special tokens, format of basic literal values, etc.). It defines the syntax of a "module definition", the definition of a module within a protocol. A module definition can contain data types, predefined information objects written in those data types (detailed syntax in X.681), constraint elements (detailed syntax in X.682), among other things. X.681 defines the syntax of an information object, which allows for objects in custom datatypes to be represented in the language (akin to object literals in other languages). It also defines a way to reference a specific value from an object using a dot notation as if it is a table. X.682 defines constraint elements, which can be used to apply more advanced constraints in a module. X.683, Parameterization of ASN.1 specifications, allows assignments and definitions to vary according to parameters.

Language support ASN.1 is a data type declaration notation. It does not define how to manipulate a variable of such a type. Manipulation of variables is defined in other languages such as SDL (Specification and Description Language) for executable modeling or TTCN-3 (Testing and Test Control Notation) for conformance testing. Both these languages natively support ASN.1 declarations. It is possible to import an ASN.1 module and declare a variable of any of the ASN.1 types declared in the module.

Applications ASN.1 is used to define a large number of protocols. Its most extensive uses continue to be telecommunications, cryptography, and biometrics.

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

Encoding Control Notation 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.

Relation to Privacy-Enhanced Mail (PEM) Encoding 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.

As computer files 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.

Example

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

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. ASN.1 supports constraints on values and sizes, and extensibility. The above specification can be changed to:

This change constrains trackingNumbers to have a value between 0 and 199 inclusive, and questionNumbers to have a value between 10 and 20 inclusive. 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 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 should 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, reducing risk and cost. The above examples only make use of syntax from X.680. More advanced constraints from X.682 are not used.

Example PDU 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:

… excerpt ends here. Continue reading the full article.

Worked examples

Example 1 — a first encounter with ASN.1

Start with the simplest possible case. Write down what ASN.1 claims or describes in one sentence, then invent the smallest concrete situation in which that sentence is true. In science, the smallest case is usually a single object, a single equation or a single measurement. Check that every symbol or term in your sentence has a meaning in that case.

Example 2 — changing one variable

Take the situation from Example 1 and change exactly one quantity: double it, halve it, or set it to zero. Predict what should happen to ASN.1 before you calculate. Comparing your prediction with the result is the fastest way to find out whether you understand the idea or only the words.

Example 3 — an exam-style question

Typical questions about ASN.1 ask you to (a) state it precisely, (b) apply it to given data, and (c) explain a limitation. Practise writing all three answers in under five minutes; the third part is what separates a full-mark answer from an average one.

Applications of ASN.1

In research: ASN.1 appears in science research whenever the underlying quantities have to be modelled precisely. Papers usually cite it as a starting assumption and then explore where it breaks down.
In technology and industry: Engineering practice reuses ASN.1 in design rules, simulations and safety margins. Knowing the idea lets you read a specification sheet and understand why the numbers look the way they do.
In the classroom: ASN.1 is common in secondary-school and first-year university syllabi. It links to neighbouring topics ASN.1, Data modeling languages, Data serialization formats, so understanding it makes those chapters shorter.
In everyday life: Look for ASN.1 outside the textbook — in sport, cooking, traffic, electronics or the sky above you. An example you found yourself is remembered far longer than one you were given.

How to study ASN.1 in 20 minutes

Read the reference excerpt below once, without taking notes.
Close the page and write down what ASN.1 means in your own words.
Compare your version with the excerpt and mark what you missed.
Work through the three examples above with pen and paper.
Explain ASN.1 out loud to somebody else — or to Teacher Smith in the lgStudy chat.

Frequently asked questions

What is ASN.1 in simple terms?

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.

Why does ASN.1 matter?

Because it connects several science ideas at once: it gives you a definition you can apply, a quantity you can calculate, and a way to check whether a result is plausible.

How should I study ASN.1?

Read the excerpt, restate it from memory, then work through the examples and applications listed on this page. The five-step study plan above takes about twenty minutes.

What does this page cover?

It gives you a compact reference excerpt plus original lgStudy explanations, examples, applications and study material on ASN.1.