View source for ASN.1

{{Short description|Data interface description language}}
{{External links|date=July 2024}}
{{Infobox technology standard
| title             = ASN.1
| long_name         = Abstract Syntax Notation One  
| image             = 
| caption           = 
| status            = In force; supersedes X.208 and X.209 (1988)
| year_started      = 1984
| version           = (02/21)
| version_date      = February 2021
| preview           = 
| preview_date      = 
| organization      = [[ITU-T]]
| committee         = [[ITU-T Study Group 17|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]]
| abbreviation      = 
| domain            = [[cryptography]], [[telecommunications]]
| license           = 
| 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 [[serialization|serialized and deserialized]] in a cross-platform way. It is broadly used in [[telecommunications]] and [[computer networking]], and especially in [[cryptography]].<ref>{{Cite web|title=Introduction to ASN.1|url=https://www.itu.int:443/en/ITU-T/asn1/Pages/introduction.aspx|url-status=live|archive-url=https://web.archive.org/web/20210409122557/https://www.itu.int/en/ITU-T/asn1/Pages/introduction.aspx|archive-date=2021-04-09|access-date=2021-04-09|website=ITU|language=en-US}}</ref>

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, [[codec]]s, that decode or encode the data structures. Some ASN.1 compilers can produce code to encode or decode several encodings, e.g. packed, [[X.690#BER encoding|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.<ref>{{Cite web|url=https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=6947|title=ITU-T Recommendation database|website=ITU|access-date=2017-03-06}}</ref> 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'''&ndash;'''X.683''' series.<ref>[https://www.itu.int/rec/T-REC-X.680-201508-I/en ITU-T X.680 - Specification of basic notation ]</ref> The latest revision of the X.680 series of recommendations is the 6.0 Edition, published in 2021.<ref>{{FOLDOC|ASN.1}}</ref>

== 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 [[Specification and Description Language|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.

{| class="wikitable"
|+ Protocols that use ASN.1
|-
! Protocol
! Specification
! Specified or customary encoding rules
! Uses
|-
| Interledger Protocol || [https://interledger.org/developers/rfcs/interledger-protocol/#specification ILPV4 Specification]|| Octet Encoding Rules ||
|-
| NTCIP 1103 - Transport Management Protocols || [https://www.ntcip.org/wp-content/uploads/2018/11/NTCIP1103v0352b.pdf NTCIP 1103] || Octet Encoding Rules || Traffic, Transportation, and Infrastructure Management
|-
| [[X.500|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) || {{IETF RFC|4511}} || Basic Encoding Rules ||
|-
| [[PKCS|PKCS Cryptography Standards]] || [[PKCS]] Cryptography Standards || Basic Encoding Rules and Distinguished Encoding Rules || Asymmetric Keys, certificate bundles
|-
| [[X.400|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) || {{IETF RFC|1157}} || Basic Encoding Rules || Managing and monitoring networks and computers, particularly characteristics pertaining to performance and reliability
|-
| [[Common Management Information Protocol]] (CMIP) || ITU Recommendation [https://www.itu.int/rec/T-REC-X.711/en 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) || [https://www.iso.org/standard/43611.html ISO/IEC 24708:2008] || ||
|-
| [[CBEFF|Common Biometric Exchange Formats Framework]] (CBEFF) || [https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir6529-a.pdf NIST IR 6529-A] || Basic Encoding Rules ||
|-
| Authentication Contexts for Biometrics (ACBio) || [https://www.iso.org/standard/71163.html ISO/IEC 24761:2019] || ||
|-
| [[Computer-supported telecommunications applications]] (CSTA) || [https://www.ecma-international.org/activities/Communications/TG11/cstaIII.htm]|| Basic Encoding Rules ||
|-
| [[Dedicated short-range communications]] (DSRC) || [http://standards.sae.org/j2735_200911/ SAE J2735] || Packed Encoding Rules || [[Vehicle-to-everything|Vehicle communication]]
|-
| [[IEEE 802.11p]] (IEEE WAVE) || [https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7426684 IEEE 1609.2] ||  || [[Vehicle-to-everything|Vehicle communication]]
|-
| [[Intelligent Transport Systems]] (ETSI ITS) || [https://www.etsi.org/deliver/etsi_ts/102600_102699/10263702/01.02.01_60/ts_10263702v010201p.pdf ETSI EN 302 637 2 (CAM)]<br/>[https://www.etsi.org/deliver/etsi_ts/102600_102699/10263703/01.01.01_60/ts_10263703v010101p.pdf ETSI EN 302 637 3 (DENM)] || Unaligned Packed Encoding Rules || [[Vehicle-to-everything|Vehicle communication]] 
|-
| [[GSM|Global System for Mobile Communications]] (GSM) || [http://www.ttfn.net/techno/smartcards/gsm11-11.pdf]|| || [[2G]] Mobile Phone Communications
|-
| [[General Packet Radio Service]] (GPRS) / [[Enhanced Data rates for GSM Evolution]] (EDGE) || [http://www.3gpp.org/technologies/keywords-acronyms/102-gprs-edge]|| || [[General Packet Radio Service|2.5G]] Mobile Phone Communications
|-
| [[UMTS|Universal Mobile Telecommunications System]] (UMTS) || [http://www.3gpp.org/DynaReport/25-series.htm]|| || [[3G]] Mobile Phone Communications
|-
| [[LTE (telecommunication)|Long-Term Evolution (LTE)]]  || [http://www.3gpp.org/technologies/keywords-acronyms/98-lte]|| || [[4G]] Mobile Phone Communications
|-
| [[5G]]  || [https://www.3gpp.org/news-events/3gpp-news/1987-imt2020_workshop]|| || [[5G]] Mobile Phone Communications
|-
| [[Common Alerting Protocol]] (CAP) || [http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html]|| 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) || [https://www.iso.org/standard/37079.html ISO 9506-1:2003] || || Manufacturing
|-
| [[FTAM|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 [https://www.itu.int/rec/T-REC-X.227-199504-I/en X.227] || ||
|-
| [[BACnet|Building Automation and Control Networks Protocol (BACnet)]] || [https://store.accuristech.com/standards/ashrae-135-2020?product_id=2191852 ASHRAE 135-2020]|| BACnet Encoding Rules || Building automation and control, such as with fire alarms, elevators, HVAC systems, etc.
|-
| [[Kerberos (protocol)|Kerberos]] || {{IETF RFC|4120}} || Basic Encoding Rules || Secure authentication
|-
| [[WiMAX 2]] || || || Wide Area Networks
|-
| [[Intelligent Network]] || The ITU Q.1200 Recommendation Series || || Telecommunications and computer networking
|-
|X2AP
|
|Basic Aligned Packed Encoding Rules
|
|-
| Lawful Interception (LI) Handover Interface || [https://www.etsi.org/deliver/etsi_ts/102200_102299/10223201/03.33.01_60/ts_10223201v033301p.pdf ETSI TS 102 232-1] || || Lawful Interception
|}

== 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:
{| class="wikitable"
|+ ASN.1 Encoding Rules
|- style="vertical-align:bottom;"
! rowspan=2 {{verth|Encoding rules}}
! colspan=2 | Object identifier
! rowspan=2   {{verth|Specification}}
! rowspan=2   {{verth|Unit of serialization}}
! rowspan=2   {{verth|Encoded elements <br/>discernable without <br/>foreknowledge of <br/>specification}}
! rowspan=2   {{verth|Octet aligned}}
! rowspan=2   {{verth|Encoding control}}
! rowspan=2 | Description
|- style="vertical-align:bottom;"
! Dotted
! {{abbr|IRI|Internationalized resource identifier}}
|-
| {{verth|[[Basic Encoding Rules]]<br/>(BER)<ref>[https://www.itu.int/rec/T-REC-X.690-201508-I/en ITU-T X.690 - Basic Encoding Rules (BER)]</ref>}}
| 2.1.1
| /Joint{{nbh}}ISO{{nbh}}ITU{{nbh}}T/ASN.1/<wbr/>Basic-Encoding
| ITU X.690
| Octet
| {{Yes}}
| {{Yes}}
| {{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.
|-
| {{verth|[[Distinguished Encoding Rules]]<br/>(DER)<ref>[https://www.itu.int/rec/T-REC-X.690-201508-I/en ITU-T X.690 - Distinguished Encoding Rules (DER)]</ref>}}
| 2.1.2.1
| /Joint{{nbh}}ISO{{nbh}}ITU{{nbh}}T/ASN.1/<wbr/>BER{{nbh}}Derived/<wbr/>Distinguished{{nbh}}Encoding
| ITU X.690
| Octet
| {{Yes}}
| {{Yes}}
| {{No}}
| A restricted subset of the 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.
|-
| {{verth|[[Canonical Encoding Rules]]<br/>(CER)<ref>[https://www.itu.int/rec/T-REC-X.690-201508-I/en ITU-T X.690 - Canonical Encoding Rules (CER)]</ref>}}
| 2.1.2.0
| /Joint{{nbh}}ISO{{nbh}}ITU{{nbh}}T/ASN.1/<wbr/><wbr/>BER{{nbh}}Derived/<wbr/>Canonical{{nbh}}Encoding
| ITU X.690
| Octet
| {{Yes}}
| {{Yes}}
| {{No}}
| A restricted subset of the BER. Employs almost all of the same restrictions as the 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).
|-
| {{verth|Packed Encoding Rules<br/> Unaligned (PER-U/UPER)<ref name=":0" />}}
| 2.1.3.0.1
| /Joint{{nbh}}ISO{{nbh}}ITU{{nbh}}T/ASN.1/<wbr/><wbr/>Packed{{nbh}}Encoding/<wbr/>Basic/Unaligned
| ITU X.691
| Bit
| {{No}}
| {{No}}
| {{No}}
| Encodes values on bits. Sometimes simply called "PER". The PERs in general are capable of producing very compact encodings, but at the expense of complexity; they are also highly dependent upon constraints placed on data types.
|-
| {{verth|Packed Encoding Rules<br/> Aligned (PER-A/APER) <ref name=":0">[https://www.itu.int/rec/T-REC-X.691-201508-I/en ITU-T X.691 - Packed Encoding Rules (PER)]</ref>}}
| 2.1.3.0.0
| /Joint{{nbh}}ISO{{nbh}}ITU{{nbh}}T/ASN.1/<wbr/><wbr/>Packed{{nbh}}Encoding/<wbr/>Basic/Aligned
| ITU X.691
| Bit
| {{No}}
| {{Yes}}
| {{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.
|-
| {{verth|Canonical Packed<br/>Encoding Rules Unaligned<br/>(CPER-U)<ref name=":0" />}}
| 2.1.3.1.1
| /Joint{{nbh}}ISO{{nbh}}ITU{{nbh}}T/ASN.1/<wbr/><wbr/>Packed{{nbh}}Encoding/<wbr/>Canonical/Unaligned
| ITU X.691
| Bit
| {{No}}
| {{No}}
| {{No}}
| A variant of the PER-U that specifies a single way of encoding values. Sometimes simply called "CPER". The CPERs have a similar relationship to the PERs that the DER and the CER have to the BER.
|-
| {{verth|Canonical Packed<br/>Encoding Rules Aligned<br/>(CPER-A)<ref name=":0" />}}
| 2.1.3.1.0
| /Joint{{nbh}}ISO{{nbh}}ITU{{nbh}}T/ASN.1/<wbr/><wbr/>Packed{{nbh}}Encoding/<wbr/>Canonical/Aligned
| ITU X.691
| Bit
| {{No}}
| {{Yes}}
| {{No}}
| A variant of the PER-A that specifies a single way of encoding values.
|-
| {{verth|Basic XML<br/>Encoding Rules<br/>(XER)<ref name=":1">[https://www.itu.int/rec/T-REC-X.693/en ITU-T X.693 - XML Encoding Rules (XER)]</ref>}}
| 2.1.5.0
| /Joint{{nbh}}ISO{{nbh}}ITU{{nbh}}T/ASN.1/<wbr/>XML{{nbh}}Encoding/<wbr/>Basic
| ITU X.693
| Character
| {{Yes}}
| {{Yes}}
| {{Yes|ECN}}
| Encodes ASN.1 data as XML.
|-
| {{verth|Canonical XML<br/>Encoding Rules<br/>(CXER)<ref name=":1" />}}
| 2.1.5.1
| /Joint{{nbh}}ISO{{nbh}}ITU{{nbh}}T/ASN.1/<wbr/>XML{{nbh}}Encoding/<wbr/>Canonical
| ITU X.693
| Character
| {{Yes}}
| {{Yes}}
| {{Yes|ECN}}
| Variant of XER that produces only one possible encoding for a given value.
|-
| {{verth|Extended XML<br/>Encoding Rules<br/>(EXER)<ref name=":1" />}}
| 2.1.5.2
| /Joint{{nbh}}ISO{{nbh}}ITU{{nbh}}T/ASN.1/<wbr/>XML{{nbh}}Encoding/<wbr/>Extended
| ITU X.693
| Character
| {{Yes}}
| {{Yes}}
| {{Yes|ECN}}
| Variant of XER that adds options and instructions controlling stylistic choices of the encoder.
|-
| {{verth|Octet Encoding Rules<br/>(OER)<ref name=":2">[https://www.itu.int/rec/T-REC-X.696-201508-I/en ITU-T X.696 - Octet Encoding Rules (OER)]</ref>}}
| 2.1.6.0
| /Joint{{nbh}}ISO{{nbh}}ITU{{nbh}}T/ASN.1/<wbr/>OER{{nbh}}Encoding/<wbr/>Basic
| ITU X.696
| Octet
| {{No}}
| {{Yes}}
| {{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).<ref>{{cite book |title=NTCIP 1102:2004 National Transportation Communications for ITS Protocol Octet Encoding Rules (OER) Base Protocol |url=https://www.ntcip.org/file/2021/03/1102v0115p.pdf}}</ref>{{rp|27}}
|-
| {{verth|Canonical Octet<br/>Encoding Rules<br/>(COER)<ref name=":2" />}}
| 2.1.6.1
| /Joint{{nbh}}ISO{{nbh}}ITU{{nbh}}T/ASN.1/<wbr/>OER{{nbh}}Encoding/<wbr/>Canonical
| ITU X.696
| Octet
| {{No}}
| {{Yes}}
| {{No}}
| Variant of OER where each value only has one possible octet representation.
|-
| {{verth|JSON<br/>Encoding Rules<br/>(JER)<ref>[https://www.itu.int/rec/T-REC-X.697/en ITU-T X.697 - JavaScript Object Notation Encoding Rules (JER)]</ref>}}
|
|
| ITU X.697
| Character
| {{Yes}}
| {{Yes}}
| {{Yes|ECN}}
| Encodes ASN.1 data as JSON. The ASCII-only version is canonical, i.e. each value only has one possible octet representation. The rest are not.
|-
| {{verth|Generic String<br/>Encoding Rules<br/>(GSER)<ref>{{IETF RFC|3641}} - Generic String Encoding Rules (GSER)</ref>}}
| 1.2.36.<wbr/>79672281.<wbr/>0.0
| /ISO/Member{{nbh}}Body/AU/Adacel/0/GSER
| {{IETF RFC|3641}}
| Character
| {{Yes}}
| {{Yes}}
| {{Maybe|RFC<br>[https://www.rfc-editor.org/rfc/rfc4792 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. {{citation needed span|The use of GSER in actual protocols is discouraged since not all character string encodings supported by ASN.1 can be reproduced in it.|date=June 2025}} Customization of encoding occurs through  instead of ECN.
|-
| {{verth|Robust XML<br/>Encoding Rules (RXER)}}
| 1.2.36.<wbr/>79672281.<wbr/>0.2
| /ISO/Member{{nbh}}Body/AU/Adacel/0/RXER
| {{IETF RFC|4910}}
| Character
| {{Yes}}
| {{Yes}}
| {{Maybe|RFC<br>[https://www.rfc-editor.org/rfc/rfc4911 4911]}}
| XML format designed for the [[Lightweight Directory Access Protocol]] (LDAP).
|-
| {{verth|BACnet<br/>Encoding Rules<br/>(BACnetER)}}
|
|
| ASHRAE 135<br/>ISO 16484-5
| Octet
| {{Yes}}
| {{Yes}}
| {{Yes|ECN}}
| Encodes elements as tag-length-value (TLV) sequences like the Basic Encoding Rules (BER) does. Example messages can be found in Karg (2012);<ref>{{cite web |last1=Karg |first1=S |title=Understanding BACnet MS/TP Encoding |url=https://bacnetexperts.com/papers/Understanding%20BACnet%20MSTP%20Encoding.pdf |date=2012}}</ref> Karg also maintains an open-source implementation of a [[BACnet]] stack, in which code for reading and writing this format can be found.<ref>{{cite web |title=bacnet-stack/bacnet-stack |url=https://github.com/bacnet-stack/bacnet-stack |publisher=BACnet Stack |date=14 June 2025}}</ref>
|-
| {{verth|Signalling Specific<br/>Encoding Rules<br/>(SER)}}
|
|
| France Telecom R&D Internal Document
| Octet
| {{Yes}}
| {{Yes}}
| {{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.
|-
| {{verth|Lightweight Encoding Rules<br/>(LWER)}}
|
|
| Internal document by INRIA.
| Memory Word
| 
| {{Yes}}
| {{No}}
| Originates from an internal document produced by [[French Institute for Research in Computer Science and Automation|INRIA]] detailing the "Flat Tree Light Weight Syntax" (FTLWS).<ref>{{cite journal |last1=Huitema |first1=C. |last2=Doghri |first2=A. |title=Defining faster transfer syntaxes for the OSI presentation protocol |journal=ACM SIGCOMM Computer Communication Review |date=October 1989 |volume=19 |issue=5 |pages=44–55 |doi=10.1145/74681.74685}}</ref> Abandoned in 1997 due to the superior performance of the Packed Encoding Rules (PER).<ref name=Larmouth99/>{{rp|319}} 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.)
|-
| {{verth|Minimum Bit<br/>Encoding Rules<br/>(MBER)}}
|
|
|
| Bit
| {{No}}
| {{No}}
| {{No}}
| Proposed in the 1980s. Meant to be as compact as possible, like the later Packed Encoding Rules (PER). Never extended to all ASN.1 data types.<ref name="Larmouth99">{{cite book |last1=Larmouth |first1=John |title=ASN.1 Complete |date=1999 |publisher=Open Systems Solutions|isbn=9780122334351}}</ref>{{rp|319}}
|-
| {{verth|High Speed<br/>Coding Rules}}
|
|
| "Coding Rules for High Speed Networks"<ref>{{cite journal |last1=Bever |first1=Martin |last2=Schäffer |first2=Ulrich |title=Coding rules for high speed networks |journal=Proceedings of the IFIP TC6/WG6.5 International Conference on Upper Layer Protocols, Architectures and Applications |date=1 June 1992 |pages=119–132 |url=https://dl.acm.org/doi/10.5555/164099.164117 |publisher=Elsevier Science Publishers B. V.|isbn=978-0-444-89766-4 }}</ref>
|
|
|
| {{No}}
| Definition of these encoding rules were a byproduct of INRIA's work on the Flat Tree Light Weight Syntax (FTLWS).
|}

===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|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|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 <code>.asn1</code><ref>{{cite web |title=Chapter 7. ASN.1 File DataFormat {{!}} Apache Camel Component Reference {{!}} Red Hat Fuse {{!}} 7.2 {{!}} Red Hat Documentation |url=https://docs.redhat.com/en/documentation/red_hat_fuse/7.2/html/apache_camel_component_reference/asn1-dataformat |website=docs.redhat.com}}</ref> and <code>.all</code> have been used for general files. <code>.asn</code> has been used for files only containing module definitions and <code>.prt</code> for files only containing value definitions.<ref name="AsnLib">{{cite web |title=AsnLib: ASN.1 Processing |url=https://www.ncbi.nlm.nih.gov/IEB/ToolBox/SDKDOCS/ASNLIB.HTML |website=www.ncbi.nlm.nih.gov}}</ref>
* BER-encoded data: <code>.ber</code> has been used.<ref>{{cite web |title=Ubuntu Manpage: unber -- the ASN.1 BER Decoder |url=https://manpages.ubuntu.com/manpages/noble/man1/unber.1.html |website=manpages.ubuntu.com}}</ref> There is also a proposed [[MIME type]] <code>application/ber-stream</code> which includes a <code>protocol</code> parameter specifying an associated OID.<ref>{{cite web |last1=Wahl |first1=Mark |title=A MIME Content-Type for ASN.1 PDUs |url=https://datatracker.ietf.org/doc/html/draft-ietf-asid-mime-ber-00 |publisher=Internet Engineering Task Force |date=13 March 1996}}</ref>
** DER-encoded data: <code>.der</code>. For DER-encoded [[X.509]] certificates, <code>.cer</code> and <code>.crt</code> in addition to <code>.der</code>. The MIME type <code>application/x-x509-ca-cert</code> is specifically for DER-encoded certificates, not general DER data.
* Other encoded data: <code>asn1c</code> sample files use <code>.xer</code> for XER, <code>.per</code> for PER, and <code>.coer</code> for COER.

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

<syntaxhighlight lang="asn1">
FooProtocol DEFINITIONS ::= BEGIN

    FooQuestion ::= SEQUENCE {
        trackingNumber INTEGER,
        question       IA5String
    }

    FooAnswer ::= SEQUENCE {
        questionNumber INTEGER,
        answer         BOOLEAN
    }

END
</syntaxhighlight>

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:

<syntaxhighlight lang="asn1">
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
</syntaxhighlight>

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:

<syntaxhighlight lang="asn1">
myQuestion FooQuestion ::= {
    trackingNumber     5,
    question           "Anybody there?"
}
</syntaxhighlight>

To send the myQuestion message through the network, the message is serialized (encoded) as a series of [[byte]]s using one of the [[Abstract Syntax Notation One#Encodings|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.

===Example encoded in DER===
Below is the data structure shown above as myQuestion encoded in [[X.690#DER encoding|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):

<syntaxhighlight lang="xml">
<FooQuestion>
    <trackingNumber>5</trackingNumber>
    <question>Anybody there?</question>
</FooQuestion>
</syntaxhighlight>

===Example encoded in PER, either aligned or unaligned===
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.

== 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 the [https://www.itu.int/en/ITU-T/asn1/Pages/Tools.aspx ITU-T Tool web page].

=== Online tools ===

* [https://amenitypj.in/asn1Play ASN1 Play]
* [https://asn1.netlify.app/ ASN1 Web Tool (very limited)]
* [https://asn1.io/asn1playground/ ASN1 Playground (sandbox)]
* [https://lapo.it/asn1js/ ASN.1 JavaScript decoder]

== Comparison to similar schemes ==
{{main|Comparison of data serialization formats}}
ASN.1 is similar in purpose and use to [[Protocol Buffers|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|JSON schema]] both support similar constraints concepts. Tool support for constraints varies. Microsoft's xsd.exe compiler ignores them.

=== Schema translation ===
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.<ref>{{cite web |title=JSON2ASN |url=https://asn1.io/json2asn/default.aspx |website=asn1.io}}</ref> 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.<ref>{{cite web |title=Proto2ASN |url=https://asn1.io/proto2asn/ |website=asn1.io}}</ref>

=== Schema-optional formats ===

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|JSON schema]] or [[XML schema]].

=== Protocol definitions on different levels ===

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.

==See also==
* [[X.690]]
* [[Information Object Class (ASN.1)]]
* [[Presentation layer]]

==References==
{{Reflist}}

==External links==
* [http://luca.ntop.org/Teaching/Appunti/asn1.html A Layman's Guide to a Subset of ASN.1, BER, and DER] A good introduction for beginners
* [http://www.itu.int/ITU-T/asn1/introduction/ ITU-T website - Introduction to ASN.1]
* [http://www.pragmadev.com/presentations.html A video introduction to ASN.1]
* [http://www.obj-sys.com/asn1tutorial/asn1only.html ASN.1 Tutorial] Tutorial on basic ASN.1 concepts
* [http://www.oss.com/asn1/resources/asn1-made-simple/introduction.html ASN.1 Tutorial] Tutorial on ASN.1
* [http://lionet.info/asn1c/download.html An open-source ASN.1->C++ compiler; Includes some ASN.1 specs.], [http://lionet.info/asn1c/asn1c.cgi An on-line ASN.1->C++ Compiler] 
* [http://www.marben-products.com/asn.1/services/decoder-asn1.html ASN.1 decoder] Allows decoding ASN.1 encoded messages into XML output.
* [http://asn1-playground.oss.com/ ASN.1 syntax checker and encoder/decoder] Checks the syntax of an ASN.1 schema and encodes/decodes messages.
* [http://3gpp-message-analyser.com/ ASN.1 encoder/decoder of 3GPP messages] Encodes/decodes ASN.1 3GPP messages and allows easy editing of these messages.
* [http://www.oss.com/asn1/resources/books-whitepapers-pubs/asn1-books.html Free books about ASN.1]
* [https://ivmaiasn.sourceforge.net/asn1lnk.html List of ASN.1 tools at IvmaiAsn project]
* [http://www.oss.com/asn1/resources/books-whitepapers-pubs/Overview%20of%20OER.pdf Overview of the Octet Encoding Rules (OER)]
* [http://www.oss.com/asn1/resources/asn1-papers/Overview%20of%20JER.pdf Overview of the JSON Encoding Rules (JER)]
* [https://github.com/jlguenego/asn.1 A Typescript node utility to parse and validate ASN.1 messages]

{{Data Exchange}}
{{Authority control}}

[[Category:ASN.1| ]]
[[Category:Data modeling languages]]
[[Category:Data serialization formats]]
[[Category:ITU-T X Series Recommendations]]