Misplaced Pages

#238761

55-691: The Basic Encoding Rules (BER) were the original rules laid out by the ASN.1 standard for encoding data into a binary format. The rules, collectively referred to as a transfer syntax in ASN.1 parlance, specify the exact octets (8-bit bytes) used to encode data. X.680 defines a syntax for declaring data types, for example: booleans, numbers, strings, and compound structures. Each type definition also includes an identifying number. X.680 defines several primitive data types, for example: BooleanType, IntegerType, OctetStringType. (ASN.1 also provides for constructed types built from other types.) Types are associated with

110-419: A class . For example, the primitive types are part of the universal class. The three other classes ( application , private , and context-specific ) are essentially different scopes to support customization for specific applications. Combined, the class and type form a tag , which therefore corresponds to a unique data definition. X.690 includes rules for encoding those tags, data values (content), and

165-477: 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

220-404: A choice between encoding rules, the X.690 standards document provides the following guidance: The distinguished encoding rules is more suitable than the canonical encoding rules if the encoded value is small enough to fit into the available memory and there is a need to rapidly skip over some nested values. The canonical encoding rules is more suitable than the distinguished encoding rules if there

275-456: 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

330-405: A number of octets. This does not encode the length at all, but that the content octets finish at marker octets. This applies to constructed types and is typically used if the content is not immediately available at encoding time. It consists of a single octet, in which bit 8 is 1, and bits 1–7 are 0. Then, two end-of-contents octets must terminate the content octets. The contents octets encode

385-538: 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. This

440-512: 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

495-563: A series of decimal values ranging from 0 to 255, each separated by a full stop (dot). Using octets with all eight bits set, the representation of the highest-numbered IPv4 address is 255.255.255.255 . An IPv6 address consists of sixteen octets, displayed in hexadecimal representation (two hexits per octet), using a colon character (:) after each pair of octets (16 bits are also known as hextet ) for readability, such as 2001:0db8:0000:0000:0123:4567:89ab:cdef . Abstract Syntax Notation One Abstract Syntax Notation One ( ASN.1 )

550-536: 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,

605-412: A single octet in which bit 8 is 0, and bits 1–7 encode the length (which may be 0) as a number of octets. The long form consists of 1 initial octet followed by 1 or more subsequent octets, containing the length. In the initial octet, bit 8 is 1, and bits 1–7 (excluding the values 0 and 127) encode the number of octets that follow. The following octets encode, as big-endian, the length (which may be 0) as

SECTION 10

#1732851200239

660-481: 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: 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): Alternatively, if Packed Encoding Rules are employed,

715-424: Is a unit of digital information in computing and telecommunications that consists of eight bits . The term is often used when the term byte might be ambiguous, as the byte has historically been used for storage units of a variety of sizes. The term octad(e) for eight bits is no longer common. The international standard IEC 60027-2, chapter 3.8.2, states that a byte is an octet of bits. However,

770-443: Is a common perception of BER as being "inefficient" compared to alternative encoding rules. It has been argued by some that this perception is primarily due to poor implementations, not necessarily any inherent flaw in the encoding rules. These implementations rely on the flexibility that BER provides to use encoding logic that is easier to implement, but results in a larger encoded data stream than necessary. Whether this inefficiency

825-604: 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

880-452: Is a need to encode values that are so large that they cannot readily fit into the available memory or it is necessary to encode and transmit a part of a value before the entire value is available. The basic encoding rules is more suitable than the canonical or distinguished encoding rules if the encoding contains a set value or set-of value and there is no need for the restrictions that the canonical and distinguished encoding rules impose. There

935-425: 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

990-400: Is a standard mapping to convert an XML Schema to an ASN.1 schema, which can then be encoded using BER. Despite its perceived problems, BER is a popular format for transmitting data, particularly in systems with different native data encodings. By comparison, the more definite DER encoding is widely used to transfer digital certificates such as X.509 . Octet (computing) The octet

1045-538: Is a subset of BER providing for exactly one way to encode an ASN.1 value. DER is intended for situations when a unique encoding is needed, such as in cryptography , and ensures that a data structure that needs to be digitally signed produces a unique serialized representation. DER can be considered a canonical form of BER. For example, in BER a Boolean value of true can be encoded as any of 255 non-zero byte values, while in DER there

1100-462: 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. Assuming a message that complies with the Foo Protocol and that will be sent to

1155-511: 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

SECTION 20

#1732851200239

1210-624: Is frequently used in the Request for Comments (RFC) publications of the Internet Engineering Task Force to describe storage sizes of network protocol parameters. The earliest example is RFC   635 from 1974. In 2000, Bob Bemer claimed to have earlier proposed the usage of the term octet for "8-bit bytes" when he headed software operations for Cie. Bull in France in 1965 to 1966. In France , French Canada and Romania , octet

1265-428: 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

1320-659: Is one way to encode a boolean value of true. The most significant DER encoding constraints are: DER is widely used for digital certificates such as X.509 . The key difference between the BER format and the CER or DER formats is the flexibility provided by the Basic Encoding Rules. BER, as explained above, is the basic set of encoding rules given by ITU-T X.690 for the transfer of ASN.1 data structures. It gives senders clear rules for encoding data structures they want to send, but also leaves senders some encoding choices. As stated in

1375-457: 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. 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 recommendations provide

1430-566: Is reality or perception, it has led to a number of alternative encoding schemes, such as the Packed Encoding Rules , which attempt to improve on BER performance and size. Other alternative formatting rules, which still provide the flexibility of BER but use alternative encoding schemes, are also being developed. The most popular of these are XML-based alternatives, such as the XML Encoding Rules and ASN.1 SOAP . In addition, there

1485-407: 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

1540-430: Is to be encoded as a type identifier, a length description, the actual data elements, and, where necessary, an end-of-content marker. These types of encodings are commonly called type–length–value (TLV) encodings. However, in BER's terminology, it is identifier-length-contents . This type of format would allow a receiver to decode the ASN.1 information from an incomplete stream, without requiring any pre-knowledge of

1595-647: Is used in common language instead of byte when the eight-bit sense is required; for example, a megabyte (MB) is termed a megaoctet (Mo). A variable-length sequence of octets, as in Abstract Syntax Notation One (ASN.1), is referred to as an octet string. Historically, in Western Europe , the term octad (or octade ) was used to specifically denote eight bits, a usage no longer common. Early examples of usage exist in British, Dutch and German sources of

1650-492: 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

1705-405: The hexadecimal , decimal , or octal number systems . The binary value of all eight bits set (or activated) is 11111111 2 , equal to the hexadecimal value FF 16 , the decimal value  255 10 , and the octal value  377 8 . One octet can be used to represent decimal values ranging from 0 to 255. The term octet (symbol: o ) is often used when the use of byte might be ambiguous. It

X.690 - Misplaced Pages Continue

1760-425: The indefinite form of Length. The BER identifier octets encode the ASN.1 tags . The list of Universal Class tags can be found at Rec. ITU-T X.680, clause 8, table 1. The following tags are native to ASN.1: The identifier octets encode the ASN.1 tag's class number and type number. It also encodes whether the contents octets represent a constructed or primitive value. The Identifier spans one or more octets. In

1815-608: The 1960s and 1970s, and throughout the documentation of Philips mainframe computers . Similar terms are triad for a grouping of three bits and decade for ten bits. Unit multiples of the octet may be formed with SI prefixes and binary prefixes (power of 2 prefixes) as standardized by the International Electrotechnical Commission in 1998. The octet is used in representations of Internet Protocol computer network addresses. An IPv4 address consists of four octets, usually displayed individually as

1870-518: The BER standard. CER and DER differ in the set of restrictions that they place on the sender. The basic difference between CER and DER is that DER uses definitive length form and CER uses indefinite length form in some precisely defined cases. That is, DER always has leading length information, while CER uses end-of-contents octets instead of providing the length of the encoded data. Because of this, CER requires less metadata for large encoded values, while DER does it for small ones. In order to facilitate

1925-476: The X.690 standard, "Alternative encodings are permitted by the basic encoding rules as a sender's option. Receivers who claim conformance to the basic encoding rules shall support all alternatives". A receiver must be prepared to accept all legal encodings in order to legitimately claim BER-compliance. By contrast, both CER and DER restrict the available length specifications to a single option. As such, CER and DER are restricted forms of BER and serve to disambiguate

1980-484: 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

2035-426: The basic encoding rules, eliminating the rest of the options. CER is useful when the encodings must be preserved; e.g., in security exchanges. DER (Distinguished Encoding Rules) is a restricted variant of BER for producing unequivocal transfer syntax for data structures described by ASN.1 . Like CER , DER encodings are valid BER encodings. DER is the same thing as BER with all but one sender's options removed. DER

2090-410: 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: (in this case, each octet is padded individually with null bits on their unused most significant bits). Most of the tools supporting ASN.1 do

2145-418: The class and primitive/constructed as before, and bits 1–5 are 1. The tag number is encoded in the following octets, where bit 8 of each is 1 if there are more octets, and bits 1–7 encode the tag number. The tag number bits combined, big-endian, encode the tag number. The least number of following octets should be encoded; that is, bits 1–7 should not all be 0 in the first following octet. There are two forms of

2200-526: The element data value. Note that there may be no contents octets (hence, the element has a length of 0) if only the existence of the ASN.1 object, or its emptiness, is to be noted. For example, this is the case for an ASN.1 NULL value. CER (Canonical Encoding Rules) is a restricted variant of BER for producing unequivocal transfer syntax for data structures described by ASN.1 . Whereas BER gives choices as to how data values may be encoded, CER (together with DER ) selects just one encoding from those allowed by

2255-408: 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

X.690 - Misplaced Pages Continue

2310-415: 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

2365-488: 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

2420-467: 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: 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

2475-486: The following: A list of tools supporting ASN.1 can be found on the ITU-T Tool web page . 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

2530-440: 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

2585-496: The initial octet, bit 6 encodes whether the type is primitive or constructed, bit 7–8 encode the tag's class, and bits 1–5 encode the tag's type. The following values are possible: If the tag's type fits in the 5-bits (0-30 10 ), then the Identifier spans just one byte: Short Form . If the tag's type is too large for the 5-bit tag field (> 30 10 ), it has to be encoded in further octets: Long Form . The initial octet encodes

2640-421: The length octets: The definite form and the indefinite form. This encodes the number of content octets and is always used if the type is primitive or constructed and data are immediately available. There is a short form and a long form, which can encode different ranges of lengths. Numeric data is encoded as unsigned integers with the least significant bit always first (to the right). The short form consists of

2695-588: The lengths of that encoded data. BER, along with two subsets of BER (the Canonical Encoding Rules and the Distinguished Encoding Rules ), are defined by the ITU-T 's X.690 standards document, which is part of the ASN.1 document series. Basic Encoding Rules specifies in general terms, a partially self-describing and self-delimiting protocol for encoding ASN.1 data structures. Each data element

2750-516: 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. Below is the data structure shown above as myQuestion encoded in DER format (all numbers are in hexadecimal): DER

2805-537: 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

SECTION 50

#1732851200239

2860-410: The receiving party, this particular message ( protocol data unit (PDU)) is: 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

2915-452: 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

2970-447: The size, content, or semantic meaning of the data, though some specifics of the protocol would need to be provided or reverse-engineered from representative samples of traffic or software. Data encoding consists of three or four components, in the following order: Note that if a Length is zero, then there are no Contents octets, e.g. the NULL type. The End-of-Contents octets are only used for

3025-558: The unit byte has historically been platform -dependent and has represented various storage sizes in the history of computing . Due to the influence of several major computer architectures and product lines, the byte became overwhelmingly associated with eight bits. This meaning of byte is codified in such standards as ISO/IEC 80000-13 . While byte and octet are often used synonymously, those working with certain legacy systems are careful to avoid ambiguity. Octets can be represented using number systems of varying bases such as

#238761