Basic Encoding Rules
 | It has been suggested that PrintableString be merged into this article. (Discuss) Proposed since November 2010. |
The Basic Encoding Rules (BER) is one of the encoding formats defined as part of the ASN.1 standard specified by the ITU in X.690.
Description
The Basic Encoding Rules were the original rules laid out by the ASN.1 standard for encoding abstract information into a concrete data stream. The rules, collectively referred to as a transfer syntax in ASN.1 parlance, specify the exact octet sequences which are used to encode a given data item. The syntax defines such elements as: the representations for basic data types, the structure of length information, and the means for defining complex or compound types based on more primitive types. The BER syntax, 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.
Encoding
The BER format 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.[1]
| 1..(tLen) | (1+tLen)..(1+tLen+lLen) | (1+tLen+lLen+1)..(1+tLen+lLen+1+vLen) |
|---|---|---|
| Type | Length | Value (of given length) |
The encoding of a PDU consists of cascaded TLV encodings; encapsulating types are SEQUENCE, SET and CHOICE.
Type
The type field is an octet specifying the characteristics of the value field.
| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
|---|---|---|---|---|---|---|---|
| Class | P/C | Tag Number | |||||
If Class is set to Universal, the value is of a type native to ASN.1 (e.g. INTEGER). The Application class is only valid for one specific application. Context-specific depends on the context (such as within a sequence, set or choice) and private can be defined in private specifications.
| Class | bit 8 | bit 7 |
|---|---|---|
| Universal | 0 | 0 |
| Application | 0 | 1 |
| Context-specific | 1 | 0 |
| Private | 1 | 1 |
P/C is the primitive/constructed bit; it specifies whether the value is primitive, like an INTEGER, or constructed, which means it again holds TLV values like a SET.
| P/C | bit 6 |
|---|---|
| Primitive | 0 |
| Constructed | 1 |
Number specifies the tag, which gives the exact kind of the value.
| Name | P/C | Number (decimal) | Number (hexadecimal) |
|---|---|---|---|
| EOC (End-of-Content) | P | 0 | 0 |
| BOOLEAN | P | 1 | 1 |
| INTEGER | P | 2 | 2 |
| BIT STRING | P/C | 3 | 3 |
| OCTET STRING | P/C | 4 | 4 |
| NULL | P | 5 | 5 |
| OBJECT IDENTIFIER | P | 6 | 6 |
| Object Descriptor | P/C | 7 | 7 |
| EXTERNAL | C | 8 | 8 |
| REAL (float) | P | 9 | 9 |
| ENUMERATED | P | 10 | A |
| EMBEDDED PDV | C | 11 | B |
| UTF8String | P/C | 12 | C |
| RELATIVE-OID | P | 13 | D |
| (reserved) | - | 14 | E |
| (reserved) | - | 15 | F |
| SEQUENCE and SEQUENCE OF | C | 16 | 10 |
| SET and SET OF | C | 17 | 11 |
| NumericString | P/C | 18 | 12 |
| PrintableString | P/C | 19 | 13 |
| T61String | P/C | 20 | 14 |
| VideotexString | P/C | 21 | 15 |
| IA5String | P/C | 22 | 16 |
| UTCTime | P/C | 23 | 17 |
| GeneralizedTime | P/C | 24 | 18 |
| GraphicString | P/C | 25 | 19 |
| VisibleString | P/C | 26 | 1A |
| GeneralString | P/C | 27 | 1B |
| UniversalString | P/C | 28 | 1C |
| CHARACTER STRING | P/C | 29 | 1D |
| BMPString | P/C | 30 | 1E |
| (use long-form) | - | 31 | 1F |
Additional information from http://luca.ntop.org/Teaching/Appunti/asn1.html:
The P/C (primitive/constructed) bit has value 0 for primitive and 1 for constructed. Some types (such as strings) may be encoded in either primitive or constructed form. When the encoding is primitive, the value field contains the representation of the tagged data item, whereas when the encoding is constructed, the value field contains a sequence of TLVs.
A tag number field of 1F indicates that the tag number is stored in subsequent bytes in base-128 in big-endian order where the 8th bit is 1 if more bytes follow and 0 for the last byte of the tag number.
The length field is encoded either as:
- A single byte with the 8th bit as 0 and the other 7 bits encoding the length.
- A "length of the length field" byte that indicates the number of bytes to follow that represent the length field, followed by that number of bytes encoding the length in big-endian byte order.
- An indefinite-length encoding (only used with constructed encoding) where the length byte is coded as 80 to mean indefinite and a EOC TLV is used as the terminator.
Data (especially members of sequences and sets and choices) can be tagged with a unique tag number (shown in ASN.1 within square brackets []) to distinguish that data from other members. Such tags can be implicit (where they are encoded as the TLV tag of the value instead of using the base type as the TLV tag) or explicit (where the tag is used in a constructed TLV that wraps the base type TLV). 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.
Length
If the first byte of [Length] is 0x00 to 0x7F, it describes the actual length.
If the first byte is 0x80 + n with 0<n<0x7F, the actual length is described in the following 'n' bytes.
The length value 0xFF is reserved for further extensions.[2]
The length value 0x80, used only in constructed form types, is defined as "indefinite length".
Comparison to alternative formats
The key difference between the BER format and the CER or DER formats is the flexibility provided by the Basic Encoding Rules. 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".[1] For example, when encoding a constructed value (that is, a value that is made up of multiple smaller, already-encoded values), the sender can use one of three different forms to specify the length of the data.[1] 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.
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.[3] 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.[4] In addition, there is a standard mapping to convert an XML Schema to an ASN.1 schema, which can then be encoded using BER.[5]
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.
- The public key certificate standard X.509 also uses ASN.1 with BER as its encoding.
- 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 (Transferred Account Procedures), NRTRDE (Near Real Time Roaming Data Exchange) files are encoded using BER. [1]
See also
- Canonical Encoding Rules
- Distinguished Encoding Rules
- Packed Encoding Rules
- SNMP
- Kerberos
- Serialization
- Peter Gutmann's 'X.509 Style Guide' [2]
- RSA's 'A Layman's Guide to a Subset of ASN.1, BER, and DER ' [3]
Footnotes
- ^ a b c ITU-T X.690, ISO 8825-1
- ^ "ASN.1 - Communication between Heterogeneous Systems" by Olivier Dubuisson, page 396.
- ^ Lin, Huai-An. “Estimation of the Optimal Performance of ASN.1/BER Transfer Syntax”. ACM Computer Communication Review. July 93, 45 - 58.
- ^ ITU-T Rec. X.892, ISO/IEC 24824-2
- ^ ITU-T X.694, ISO/IEC ISO/IEC 8825-5
External links
- ITU-T X.690, ISO/IEC 8825-1
- ITU-T X.892, ISO/IEC 24824-2
- ITU-T X.694, ISO/IEC ISO/IEC 8825-5
- PKCS #7
- simple BER tutorial
- jASN1 Java ASN.1 BER encoding/decoding library at openmuc.org, LGPL-licensed
References
This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.