ASN.1

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Jacob.hoffmanandrews (talk | contribs) at 20:39, 6 March 2017 (Simplify descriptions of references; add ASN.1 category). 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 an interface description language for defining data structures that can be serialized and deserialized in a standard, cross-platform way. It's 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. Because the language is both human-readable and machine-readable, modules can be automatically turned into libraries that process their data structures, using an ASN.1 compiler.

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

Applications

ASN.1 is used in X.509, which defines the format of certificates used in the HTTPS protocol for securely browsing the web, and in many other cryptographic systems.

It's also used in the PKCS group of cryptography standards, X.400 electronic mail, X.500 and Lightweight Directory Access Protocol (LDAP), H.323 (VoIP), Kerberos, BACnet and simple network management protocol (SNMP), and third- and fourth-generation wireless communications technologies (UMTS, LTE, and WiMAX 2).[1]

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:

The encoding rules are all platform-independent, and can be used across a variety of hardware and software.

The PEM format is often used to encapsulate DER-encoded ASN.1 certificates and keys in an ASCII-only format. The PEM version of a DER message consists of the base64 encoding of the DER message, preceded by "-----BEGIN FOO-----" and followed by "-----END FOO-----," where "FOO" may indicate "CERTIFICATE," "PUBLIC KEY," "PRIVATE KEY" or many other types of content.

Example

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

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

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

Example encoded in DER

Below is the data structure shown above 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?")

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

Comparison to similar schemes

ASN.1 is most similar 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. 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. For instance, a module can specify an integer field that must be in the range 0 to 100.

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: While ASN.1 defines a data structure, which can be encoded various ways, ABNF combines the data structure definition with an encoding definition. ABNF tends to be used more frequently for defining textual, human-readable protocols, and generally is not used to define type-length-value encodings. In the Megaco protocol, two encodings are defined: one based on ASN.1 and one based on ABNF.

Many programming languages define language-specific serialization formats. For instance, Python's "pickle" module and Ruby's "Marshal" module. These formats are generally language specific. They also don't require a schema, 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. However, they are both cross-platform standards, and are broadly popular for communications protocols, particularly when combined with an XML schema or JSON schema.

For more detail, see Comparison of data serialization formats.

Standards

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[2]. 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 series. The latest revision of the X.680 series of recommendations is the 5.0 Edition, published in 2015.

The ITU website lists the complete set of ITU ASN.1 standards. RFC 3641 and RFC 4792 define the Generic String 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
phpseclib: ASN.1 Parser PHP
tlve Apache C
IvmaiAsn GPL Java
Erlang asn1ct Apache Erlang

References

  1. ^ ITU-T website - Uses of ASN.1
  2. ^ "ITU-T Recommendation database". ITU. Retrieved 2017-03-06.

External links

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