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) 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.Example
This is an example ASN.1 module defining the messages (data structures) of a fictitious Foo Protocol:FooProtocol DEFINITIONS ::= BEGIN
FooQuestion ::= SEQUENCE
FooAnswer ::= SEQUENCE
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 ::=ASN.1 supports constraints on values and sizes, and extensibility. The above specification can be changed to
FooProtocol DEFINITIONS ::= BEGIN
FooQuestion ::= SEQUENCE
FooAnswer ::= SEQUENCE
FooHistory ::= SEQUENCE
END
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.
To send the myQuestion message through the network, the message is serialized (encoded) as a series of Example encoded in DER
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 3fDER 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?")
Example encoded in XER
Alternatively, it is possible to encode the same ASN.1 data structure withExample 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 c0In 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). 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).
Tools
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 thOnline tools
Comparison to similar schemes
ASN.1 is similar in purpose and use to 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.See also
* X.690 * Information Object Class (ASN.1) *References
External links