Язык описания интерфейсов данных ASN.1

Data interface description language

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 series. The latest revision of the X.680 series of recommendations is the 6.0 Edition, published in 2021.

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.

ASN.1 is used to define a large number of protocols. Its most extensive uses continue to be telecommunications, cryptography, and biometrics. + Protocols that use ASN.1 Protocol Specification Specified or customary encoding rules Uses Interledger Protocol ILPV4 Specification Octet Encoding Rules NTCIP 1103 Transport Management Protocols NTCIP 1103 Octet Encoding Rules Traffic, Transportation, and Infrastructure Management X.500 Directory Services The ITU X.500 Recommendation Series Basic Encoding Rules, Distinguished Encoding Rules LDAP, TLS (X.509) Certificates, Authentication Lightweight Directory Access Protocol (LDAP) Basic Encoding Rules PKCS Cryptography Standards PKCS Cryptography Standards Basic Encoding Rules and Distinguished Encoding Rules Asymmetric Keys, certificate bundles X.400 Message Handling The ITU X.400 Recommendation Series An early competitor to email EMV EMVCo Publications Payment cards T.120 Multimedia conferencing The ITU T.120 Recommendation Series Basic Encoding Rules, Packed Encoding Rules Microsoft's Remote Desktop Protocol (RDP) Simple Network Management Protocol (SNMP) Basic Encoding Rules Managing and monitoring networks and computers, particularly characteristics pertaining to performance and reliability Common Management Information Protocol (CMIP) ITU Recommendation X.711 A competitor to SNMP but more capable and not nearly as popular Signalling System No. 7 (SS7) The ITU Q.700 Recommendation Series Managing telephone connections over the Public Switched Telephone Network (PSTN) ITU H Series Multimedia Protocols The ITU H.200, H.300, and H.400 Recommendation Series Voice Over Internet Protocol (VOIP) BioAPI Interworking Protocol (BIP) ISO/IEC 24708:2008 Common Biometric Exchange Formats Framework (CBEFF) NIST IR 6529 A Basic Encoding Rules Authentication Contexts for Biometrics (ACBio) ISO/IEC 24761:2019 Computer supported telecommunications applications (CSTA) Basic Encoding Rules Dedicated short range communications (DSRC) SAE J2735 Packed Encoding Rules Vehicle communication IEEE 802.11p (IEEE WAVE) IEEE 1609.2 Vehicle communication Intelligent Transport Systems (ETSI ITS) ETSI EN 302 637 2 (CAM)ETSI EN 302 637 3 (DENM) Unaligned Packed Encoding Rules Vehicle communication Global System for Mobile Communications (GSM) 2G Mobile Phone Communications General Packet Radio Service (GPRS) / Enhanced Data rates for GSM Evolution (EDGE) 2.5G Mobile Phone Communications Universal Mobile Telecommunications System (UMTS) 3G Mobile Phone Communications Long Term Evolution (LTE) 4G Mobile Phone Communications 5G 5G Mobile Phone Communications Common Alerting Protocol (CAP) XML Encoding Rules Exchanging Alert Information, such as Amber Alerts Controller–pilot data link communications (CPDLC) Aeronautics communications Space Link Extension Services (SLE) Space systems communications Manufacturing Message Specification (MMS) ISO 9506 1:2003 Manufacturing File Transfer, Access and Management (FTAM) An early and more capable competitor to File Transfer Protocol, but its rarely used anymore. Remote Operations Service Element protocol (ROSE) ITU Recommendations X.880, X.881, and X.882 An early form of Remote procedure call Association Control Service Element (ACSE) ITU Recommendation X.227 Building Automation and Control Networks Protocol (BACnet) ASHRAE 135 2020 BACnet Encoding Rules Building automation and control, such as with fire alarms, elevators, HVAC systems, etc. Kerberos Basic Encoding Rules Secure authentication WiMAX 2 Wide Area Networks Intelligent Network The ITU Q.1200 Recommendation Series Telecommunications and computer networkingX2APBasic Aligned Packed Encoding Rules Lawful Interception (LI) Handover Interface ETSI TS 102 232 1 Lawful 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 rowspan=2 Object identifier Object descriptor value rowspan=2 rowspan=2 rowspan=2 rowspan=2 rowspan=2 Description Dotted IRI (Internationalized resource identifier) 2.1.1 /ASN.1/Basic Encoding Basic Encoding of a single ASN.1 type ITU X.690 Octet ✔ ✔ 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. 2.1.2.1 /ASN.1/BERDerived/DistinguishedEncoding Distinguished encoding of a single ASN.1 type ITU X.690 Octet ✔ ✔ A restricted subset of the Basic Encoding Rules (BER). Typically used for things that are digitally signed because, since the DER allow for fewer options for encoding, and because DER encoded values are more likely to be re encoded on the exact same bytes, digital signatures produced by a given abstract value will be the same across implementations and digital signatures produced over DER encoded data will be less susceptible to collision based attacks. 2.1.2.0 /ASN.1/BERDerived/CanonicalEncoding Canonical encoding of a single ASN.1 type ITU X.690 Octet ✔ ✔ A restricted subset of the Basic Encoding Rules (BER). Employs almost all of the same restrictions as the Distinguished Encoding Rules (DER), but the noteworthy difference is that the CER specify that many large values (especially strings) are to be "chopped up" into individual substring elements at the 1000 byte or 1000 character mark (depending on the data type). 2.1.3.0.0 /ASN.1/PackedEncoding/Basic/Aligned Packed encoding of a single ASN.1 type (basic aligned) ITU X.691 Bit ✔ 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. Capable of producing very compact encodings, but at the expense of complexity, and the PER are highly dependent upon constraints placed on data types. 2.1.5.0 /ASN.1/XMLEncoding/Basic Basic XML encoding of a single ASN.1 type ITU X.693 Character ✔ ✔ ✔ Encodes ASN.1 data as XML. 2.1.6.0 Basic OER encoding of a single ASN.1 type ITU X.696 Octet ✔ A set of encoding rules that encodes values on octets, but does not encode tags or length determinants like the Basic Encoding Rules (BER). Data values encoded using the Octet Encoding Rules often look like those found in "record based" protocols. The Octet Encoding Rules (OER) were designed to be easy to implement and to produce encodings more compact than those produced by the Basic Encoding Rules (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 Packed Encoding Rules), save CPU cycles, and lower encoding/decoding latency. ITU X.697 Character ✔ ✔ ✔ Encodes ASN.1 data as JSON. 1.2.36.79672281.0.0 Generic String Encoding Rules (GSER) Character ✔ An incomplete specification for encoding rules that produce human readable values. The purpose of GSER is to represent encoded data to the user or input data from the user, in a very straightforward format. GSER was originally designed for the Lightweight Directory Access Protocol (LDAP) and is rarely used outside of it. The use of GSER in actual protocols is discouraged since not all character string encodings supported by ASN.1 can be reproduced in it. ASHRAE 135 Octet ✔ ✔ ✔ Encodes elements as tag length value (TLV) sequences like the Basic Encoding Rules (BER). France Telecom R&D Internal Document Octet ✔ ✔ 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. Internal document by INRIA. Memory Word ✔ Originates from an internal document produced by INRIA detailing the "Flat Tree Light Weight Syntax" (FTLWS). Abandoned in 1997 due to the superior performance of the Packed Encoding Rules (PER). Optionally Big Endian or Little Endian transmission as well as 8 bit, 16 bit, and 32 bit memory words. (Therefore, there are six variants, since there are six combinations of those options.) Bit Proposed in the 1980s. Meant to be as compact as possible, like the Packed Encoding Rules (PER). Bit An incomplete encoding rule specification produced by NEMA. It is incomplete because it cannot encode and decode all ASN.1 data types. Compact like the Packed Encoding Rules (PER). "Coding Rules for High Speed Networks" 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) 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 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. 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. 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. They are also both cross platform standards that are broadly popular for communications protocols, particularly when combined with a JSON schema or XML schema. 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. For more detail, see Comparison of data serialization formats.