X.690
X.690 is an ITU-T standard specifying several ASN.1 encoding formats:
- Basic Encoding Rules
- Canonical Encoding Rules
- Distinguished Encoding Rules
BER encoding
The format for Basic Encoding Rules specifies a self-describing and self-delimiting format for encoding ASN.1 data structures. Each data element is 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 or TLV encodings. This format allows a receiver to decode the ASN.1 information from an incomplete stream, without requiring any pre-knowledge of the size, content, or semantic meaning of the data.Encoding structure
The encoding of data generally consists of four components which appear in the following order:| Identifier octets Type | Length octets Length | Contents octets Value | End-of-contents octets |
The End-of-contents octets are optional and only used if the indefinite length form is used.
The Contents octet may also be omitted if there is no content to encode like in the NULL type.
Identifier octets
Types
Data can be tagged with a unique tag number to distinguish that data from other members. Such tags can be implicit or explicit. The default tagging style is explicit, unless implicit is set at ASN.1 module-level. Such tags have a default class of context-specific, but that can be overridden by using a class name in front of the tag.The encoding of a choice value is the same as the encoding of a value of the chosen type. The encoding may be primitive or constructed, depending on the chosen type. The tag used in the identifier octets is the tag of the chosen type, as specified in the ASN.1 definition of the chosen type.
The following tags are native to ASN.1:
The list of Universal Class tag assignments can be found at Rec. ITU-T X.680, clause 8, table 1 .
Encoding
The identifier octets encode the element type as an ASN.1 tag, consisting of the class and number, and whether the contents octets represent a constructed or primitive value.Note that some types can have values with either primitive or constructed encodings.
It is encoded as 1 or more octets.
In the initial octet, bit 6 encodes whether the type is primitive or constructed, bit 7–8 encode the class of the type, and bits 1–5 encode the tag number.
The following values are possible:
| Class | Value | Description |
| Universal | 0 | The type is native to ASN.1 |
| Application | 1 | The type is only valid for one specific application |
| Context-specific | 2 | Meaning of this type depends on the context |
| Private | 3 | Defined in private specifications |
| P/C | Value | Description |
| Primitive | 0 | The contents octets directly encode the element value. |
| Constructed | 1 | The contents octets contain 0, 1, or more element encodings. |
Long form
If the tag number is too large for the 5-bit tag field, it has to be encoded in further octets.The initial octet encodes 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.
Length octets
There are two forms of the length octets: The definite form and the indefinite form.Definite 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.
The short form consists of a single octet in which bit 8 is 0, and bits 1–7 encode the length as a number of octets.
The long form consist 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 encode the number of octets that follow.
The following octets encode, as big-endian, the length as a number of octets.
Indefinite form
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 single octet, in which bit 8 is 1, and bits 1–7 are 0. Then, 2 [|end-of-contents octets] must terminate the content octets.
Contents octets
The contents octets encode the element data value.Note that there may be no contents octets 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] encoding
CER 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 selects just one encoding from those allowed by the basic encoding rules, eliminating rest of the options. CER is useful when the encodings must be preserved; e.g., in security exchanges.[|DER] encoding
DER 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 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 is one way to encode a boolean value of true.
The most significant DER encoding constraints are:
- Length encoding must use the definite form
- * Additionally, the shortest possible length encoding must be used
- Bitstring, octetstring, and restricted character strings must use the primitive encoding
- Elements of a Set are encoded in sorted order, based on their tag value
BER, CER and DER compared
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 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 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 a choice between encoding rules, the X.690 standards document provides the following guidance:
Criticisms of BER encoding
There 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 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 is a standard mapping to convert an XML Schema to an ASN.1 schema, which can then be encoded using BER.
Usage
Despite its perceived problems, BER is a popular format for transmitting data, particularly in systems with different native data encodings.- The SNMP and LDAP protocols specify ASN.1 with BER as their required encoding scheme.
- The EMV standard for credit and debit cards uses BER to encode data onto the card
- The digital signature standard PKCS #7 also specifies ASN.1 with BER to encode encrypted messages and their digital signature or digital envelope.
- Many telecommunication systems, such as ISDN, toll-free call routing, and most cellular phone services use ASN.1 with BER to some degree for transmitting control messages over the network.
- GSM TAP, NRTRDE files are encoded using BER.