Asn 1 Value Assignment Sheet

.

Copyright (C) 1991-1993 RSA Laboratories, a division of RSA Data Security, Inc. License to copy this document is granted provided that it is identified as "RSA Data Security, Inc. Public-Key Cryptography Standards (PKCS)" in all material mentioning or referencing this document.
003-903015-110-000-000

Abstract. This note gives a layman's introduction to a subset of OSI's Abstract Syntax Notation One (ASN.1), Basic Encoding Rules (BER), and Distinguished Encoding Rules (DER). The particular purpose of this note is to provide background material sufficient for understanding and implementing the PKCS family of standards.

1. Introduction

It is a generally accepted design principle that abstraction is a key to managing software development. With abstraction, a designer can specify a part of a system without concern for how the part is actually implemented or represented. Such a practice leaves the implementation open; it simplifies the specification; and it makes it possible to state "axioms" about the part that can be proved when the part is implemented, and assumed when the part is employed in another, higher-level part. Abstraction is the hallmark of most modern software specifications.

One of the most complex systems today, and one that also involves a great deal of abstraction, is Open Systems Interconnection (OSI, described in X.200). OSI is an internationally standardized architecture that governs the interconnection of computers from the physical layer up to the user application layer. Objects at higher layers are defined abstractly and intended to be implemented with objects at lower layers. For instance, a service at one layer may require transfer of certain abstract objects between computers; a lower layer may provide transfer services for strings of ones and zeroes, using encoding rules to transform the abstract objects into such strings. OSI is called an open system because it supports many different implementations of the services at each layer.

OSI's method of specifying abstract objects is called ASN.1 (Abstract Syntax Notation One, defined in X.208), and one set of rules for representing such objects as strings of ones and zeros is called the BER (Basic Encoding Rules, defined in X.209). ASN.1 is a flexible notation that allows one to define a variety data types, from simple types such as integers and bit strings to structured types such as sets and sequences, as well as complex types defined in terms of others. BER describes how to represent or encode values of each ASN.1 type as a string of eight-bit octets. There is generally more than one way to BER-encode a given value. Another set of rules, called the Distinguished Encoding Rules (DER), which is a subset of BER, gives a unique encoding to each ASN.1 value.

The purpose of this note is to describe a subset of ASN.1, BER and DER sufficient to understand and implement one OSI- based application, RSA Data Security, Inc.'s Public-Key Cryptography Standards. The features described include an overview of ASN.1, BER, and DER and an abridged list of ASN.1 types and their BER and DER encodings. Sections 2-4 give an overview of ASN.1, BER, and DER, in that order. Section 5 lists some ASN.1 types, giving their notation, specific encoding rules, examples, and comments about their application to PKCS. Section 6 concludes with an example, X.500 distinguished names.

Advanced features of ASN.1, such as macros, are not described in this note, as they are not needed to implement PKCS. For information on the other features, and for more detail generally, the reader is referred to CCITT Recommendations X.208 and X.209, which define ASN.1 and BER. Terminology and notation. In this note, an octet is an eight- bit unsigned integer. Bit 8 of the octet is the most significant and bit 1 is the least significant.

The following meta-syntax is used for in describing ASN.1 notation:

BIT monospace denotes literal characters in the type
and value notation; in examples, it generally
denotes an octet value in hexadecimal
n1 bold italics denotes a variable
[] bold square brackets indicate that a term is optional
{} bold braces group related terms
| bold vertical bar delimits alternatives with a group
... bold ellipsis indicates repeated occurrences
= bold equals sign expresses terms as subterms

2. Abstract Syntax Notation One

Abstract Syntax Notation One, abbreviated ASN.1, is a notation for describing abstract types and values.

In ASN.1, a type is a set of values. For some types, there are a finite number of values, and for other types there are an infinite number. A value of a given ASN.1 type is an element of the type's set. ASN.1 has four kinds of type: simple types, which are "atomic" and have no components; structured types, which have components; tagged types, which are derived from other types; and other types, which include the CHOICE type and the ANY type. Types and values can be given names with the ASN.1 assignment operator (::=) , and those names can be used in defining other types and values.

Every ASN.1 type other than CHOICE and ANY has a tag, which consists of a class and a nonnegative tag number. ASN.1 types are abstractly the same if and only if their tag numbers are the same. In other words, the name of an ASN.1 type does not affect its abstract meaning, only the tag does. There are four classes of tag:

Universal, for types whose meaning is the same in all applications; these types are only defined in X.208.

Application, for types whose meaning is specific to an application, such as X.500 directory services; types in two different applications may have the same application-specific tag and different meanings.

Private, for types whose meaning is specific to a given enterprise.

Context-specific, for types whose meaning is specific to a given structured type; context-specific tags are used to distinguish between component types with the same underlying tag within the context of a given structured type, and component types in two different structured types may have the same tag and different meanings.

The types with universal tags are defined in X.208, which also gives the types' universal tag numbers. Types with other tags are defined in many places, and are always obtained by implicit or explicit tagging (see Section 2.3). Table 1 lists some ASN.1 types and their universal-class tags.

TypeTag number
(decimal)
Tag number
(hexadecimal)
2
3
4
5
6
and 16
and 17
19
20
22
23

Table 1. Some types and their universal-class tags.

ASN.1 types and values are expressed in a flexible, programming-language-like notation, with the following special rules:

  • Layout is not significant; multiple spaces and line breaks can be considered as a single space.
  • Comments are delimited by pairs of hyphens (--), or a pair of hyphens and a line break.
  • Identifiers (names of values and fields) and type references (names of types) consist of upper- and lower-case letters, digits, hyphens, and spaces; identifiers begin with lower-case letters; type references begin with upper-case letters.
The following four subsections give an overview of simple types, structured types, implicitly and explicitly tagged types, and other types. Section 5 describes specific types in more detail.

2.1 Simple types

Simple types are those not consisting of components; they are the "atomic" types. ASN.1 defines several; the types that are relevant to the PKCS standards are the following:
an arbitrary string of bits (ones and zeroes).

an arbitrary string of IA5 (ASCII) characters.

an arbitrary integer.

a null value.

an object identifier, which is a sequence of integer components that identify an object such as an algorithm or attribute type.

an arbitrary string of octets (eight-bit values).

an arbitrary string of printable characters.

an arbitrary string of T.61 (eight-bit) characters.

a "coordinated universal time" or Greenwich Mean Time (GMT) value.

Simple types fall into two categories: string types and non- string types. and are string types.

String types can be viewed, for the purposes of encoding, as consisting of components, where the components are substrings. This view allows one to encode a value whose length is not known in advance (e.g., an octet string value input from a file stream) with a constructed, indefinite- length encoding (see Section 3).

The string types can be given size constraints limiting the length of values.

2.2 Structured types

Structured types are those consisting of components. ASN.1 defines four, all of which are relevant to the PKCS standards:
an ordered collection of one or more types.

an ordered collection of zero or more occurrences of a given type.

an unordered collection of one or more types.

an unordered collection of zero or more occurrences of a given type.

The structured types can have optional components, possibly with default values.

2.3 Implicitly and explicitly tagged types

Tagging is useful to distinguish types within an application; it is also commonly used to distinguish component types within a structured type. For instance, optional components of a or type are typically given distinct context-specific tags to avoid ambiguity.

There are two ways to tag a type: implicitly and explicitly.

Implicitly tagged types are derived from other types by changing the tag of the underlying type. Implicit tagging is denoted by the ASN.1 keywords [class number] (see Section 5.1).

Explicitly tagged types are derived from other types by adding an outer tag to the underlying type. In effect, explicitly tagged types are structured types consisting of one component, the underlying type. Explicit tagging is denoted by the ASN.1 keywords [class number] (see Section 5.2).

The keyword [class number] alone is the same as explicit tagging, except when the "module" in which the ASN.1 type is defined has implicit tagging by default. ("Modules" are among the advanced features not described in this note.)

For purposes of encoding, an implicitly tagged type is considered the same as the underlying type, except that the tag is different. An explicitly tagged type is considered like a structured type with one component, the underlying type. Implicit tags result in shorter encodings, but explicit tags may be necessary to avoid ambiguity if the tag of the underlying type is indeterminate (e.g., the underlying type is or ).

2.4 Other types

Other types in ASN.1 include the and types. The type denotes a union of one or more alternatives; the type denotes an arbitrary value of an arbitrary type, where the arbitrary type is possibly defined in the registration of an object identifier or integer value.

3. Basic Encoding Rules

The Basic Encoding Rules for ASN.1, abbreviated BER, give one or more ways to represent any ASN.1 value as an octet string. (There are certainly other ways to represent ASN.1 values, but BER is the standard for interchanging such values in OSI.)

There are three methods to encode an ASN.1 value under BER, the choice of which depends on the type of value and whether the length of the value is known. The three methods are primitive, definite-length encoding; constructed, definite- length encoding; and constructed, indefinite-length encoding. Simple non-string types employ the primitive, definite-length method; structured types employ either of the constructed methods; and simple string types employ any of the methods, depending on whether the length of the value is known. Types derived by implicit tagging employ the method of the underlying type and types derived by explicit tagging employ the constructed methods.

In each method, the BER encoding has three or four parts:

Identifier octets. These identify the class and tag number of the ASN.1 value, and indicate whether the method is primitive or constructed.

Length octets. For the definite-length methods, these give the number of contents octets. For the constructed, indefinite-length method, these indicate that the length is indefinite.

Contents octets. For the primitive, definite-length method, these give a concrete representation of the value. For the constructed methods, these give the concatenation of the BER encodings of the components of the value.

End-of-contents octets. For the constructed, indefinite- length method, these denote the end of the contents. For the other methods, these are absent.

The three methods of encoding are described in the following sections.

3.1 Primitive, definite-length method

This method applies to simple types and types derived from simple types by implicit tagging. It requires that the length of the value be known in advance. The parts of the BER encoding are as follows:

Identifier octets. There are two forms: low tag number (for tag numbers between 0 and 30) and high tag number (for tag numbers 31 and greater).

Low-tag-number form. One octet. Bits 8 and 7 specify the class (see Table 2), bit 6 has value "0," indicating that the encoding is primitive, and bits 5-1 give the tag number.
ClassBit 8Bit 7
universal00
application01
context-specific10
private11

Table 2. Class encoding in identifier octets.

High-tag-number form. Two or more octets. First octet is as in low-tag-number form, except that bits 5-1 all have value "1." Second and following octets give the tag number, base 128, most significant digit first, with as few digits as possible, and with the bit 8 of each octet except the last set to "1."

Length octets. There are two forms: short (for lengths between 0 and 127), and long definite (for lengths between 0 and 2^1008 -1).

Short form. One octet. Bit 8 has value "0" and bits 7-1 give the length.

Long form. Two to 127 octets. Bit 8 of first octet has value "1" and bits 7-1 give the number of additional length octets. Second and following octets give the length, base 256, most significant digit first.

Contents octets. These give a concrete representation of the value (or the value of the underlying type, if the type is derived by implicit tagging). Details for particular types are given in Section 5.

3.2 Constructed, definite-length method

This method applies to simple string types, structured types, types derived simple string types and structured types by implicit tagging, and types derived from anything by explicit tagging. It requires that the length of the value be known in advance. The parts of the BER encoding are as follows:

Identifier octets. As described in Section 3.1, except that bit 6 has value "1," indicating that the encoding is constructed.

Length octets. As described in Section 3.1.

Contents octets. The concatenation of the BER encodings of the components of the value:

  • For simple string types and types derived from them by implicit tagging, the concatenation of the BER encodings of consecutive substrings of the value (underlying value for implicit tagging).
  • For structured types and types derived from them by implicit tagging, the concatenation of the BER encodings of components of the value (underlying value for implicit tagging).
  • For types derived from anything by explicit tagging, the BER encoding of the underlying value.
Details for particular types are given in Section 5.

3.3 Constructed, indefinite-length method

This method applies to simple string types, structured types, types derived simple string types and structured types by implicit tagging, and types derived from anything by explicit tagging. It does not require that the length of the value be known in advance. The parts of the BER encoding are as follows:

Identifier octets. As described in Section 3.2.

Length octets. One octet, .

Contents octets. As described in Section 3.2.

End-of-contents octets. Two octets, .

Since the end-of-contents octets appear where an ordinary BER encoding might be expected (e.g., in the contents octets of a sequence value), the 00 and 00 appear as identifier and length octets, respectively. Thus the end-of-contents octets is really the primitive, definite-length encoding of a value with universal class, tag number 0, and length 0.

4. Distinguished Encoding Rules

The Distinguished Encoding Rules for ASN.1, abbreviated DER, are a subset of BER, and give exactly one way to represent any ASN.1 value as an octet string. DER is intended for applications in which a unique octet string encoding is needed, as is the case when a digital signature is computed on an ASN.1 value. DER is defined in Section 8.7 of X.509.

DER adds the following restrictions to the rules given in Section 3:

  1. When the length is between 0 and 127, the short form of length must be used
  2. When the length is 128 or greater, the long form of length must be used, and the length must be encoded in the minimum number of octets.
  3. For simple string types and implicitly tagged types derived from simple string types, the primitive, definite-length method must be employed.
  4. For structured types, implicitly tagged types derived from structured types, and explicitly tagged types derived from anything, the constructed, definite-length method must be employed.

Other restrictions are defined for particular types (such as and ), and can be found in Section 5.

5. Notation and encodings for some types

This section gives the notation for some ASN.1 types and describes how to encode values of those types under both BER and DER.

The types described are those presented in Section 2. They are listed alphabetically here.

Each description includes ASN.1 notation, BER encoding, and DER encoding. The focus of the encodings is primarily on the contents octets; the tag and length octets follow Sections 3 and 4. The descriptions also explain where each type is used in PKCS and related standards. ASN.1 notation is generally only for types, although for the type , value notation is given as well.

5.1 Implicitly tagged types

An implicitly tagged type is a type derived from another type by changing the tag of the underlying type.

Implicit tagging is used for optional components with underlying type other than throughout PKCS, and for the extendedCertificate alternative of PKCS #7's type.

ASN.1 notation:

[[class] number]Type

class = | |

where Type is a type, class is an optional class name, and number is the tag number within the class, a nonnegative integer.

In ASN.1 "modules" whose default tagging method is implicit tagging, the notation [[class] number] Type is also acceptable, and the keyword is implied. (See Section 2.3.) For definitions stated outside a module, the explicit inclusion of the keyword is preferable to prevent ambiguity.

If the class name is absent, then the tag is context- specific. Context-specific tags can only appear in a component of a structured or type.

Example: PKCS #8's type has an optional component with an implicit, context-specific tag:

PrivateKeyInfo ::= SEQUENCE { version Version, privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, privateKey PrivateKey, attributes [0] IMPLICIT Attributes OPTIONAL }

Here the underlying type is , the class is absent (i.e., context-specific), and the tag number within the class is 0.

BER encoding. Primitive or constructed, depending on the underlying type. Contents octets are as for the BER encoding of the underlying value.

Example: The BER encoding of the attributes component of a value is as follows:

  • the identifier octets are if the underlying value has a primitive BER encoding and if the underlying value has a constructed BER encoding
  • the length and contents octets are the same as the length and contents octets of the BER encoding of the underlying value

DER encoding. Primitive or constructed, depending on the underlying type. Contents octets are as for the DER encoding of the underlying value.

5.2 Explicitly tagged types

Explicit tagging denotes a type derived from another type by adding an outer tag to the underlying type.

Explicit tagging is used for optional components with underlying type throughout PKCS, and for the version component of X.509's type.

ASN.1 notation:

[[class] number]Type

class =

where Type is a type, class is an optional class name, and number is the tag number within the class, a nonnegative integer.

If the class name is absent, then the tag is context- specific. Context-specific tags can only appear in a component of a or type.

In ASN.1 "modules" whose default tagging method is explicit tagging, the notation [[class] number] Type is also acceptable, and the keyword is implied. (See Section 2.3.) For definitions stated outside a module, the explicit inclusion of the keyword is preferable to prevent ambiguity.

Example 1: PKCS #7's type has an optional content component with an explicit, context-specific tag:

ContentInfo ::= SEQUENCE { contentType ContentType, content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }

Here the underlying type is the class is absent (i.e., context-specific), and the tag number within the class is 0.

Example 2: X.509's type has a version component with an explicit, context-specific tag, where the keyword is omitted:

Certificate ::= ... version [0] Version DEFAULT v1988, ...

The tag is explicit because the default tagging method for the ASN.1 "module" in X.509 that defines the type is explicit tagging.

BER encoding. Constructed. Contents octets are the BER encoding of the underlying value.

Example: the BER encoding of the content component of a value is as follows:

  • identifier octets are
  • length octets represent the length of the BER encoding of the underlying value
  • contents octets are the BER encoding of the underlying value

DER encoding. Constructed. Contents octets are the DER encoding of the underlying value.

5.3 ANY

The type denotes an arbitrary value of an arbitrary type, where the arbitrary type is possibly defined in the registration of an object identifier or associated with an integer index.

The type is used for content of a particular content type in PKCS #7's type, for parameters of a particular algorithm in X.509's type, and for attribute values in X.501's and types. The type is used by PKCS #6, #7, #8, #9 and #10, and the type is used in X.501 distinguished names.

ASN.1 notation:

identifier]

where identifier is an optional identifier.

In the form, the actual type is indeterminate.

The identifier form can only appear in a component of a or type for which identifier identifies some other component, and that other component has type or (or a type derived from either of those by tagging). In that form, the actual type is determined by the value of the other component, either in the registration of the object identifier value, or in a table of integer values.

Example: X.509's type has a component of type :

AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL }

Here the actual type of the component depends on the value of the component. The actual type would be defined in the registration of object identifier values for the component.

BER encoding. Same as the BER encoding of the actual value.

Example: The BER encoding of the value of the component is the BER encoding of the value of the actual type as defined in the registration of object identifier values for the component.

DER encoding. Same as the DER encoding of the actual value.

5.4 BIT STRING

The type denotes an arbitrary string of bits (ones and zeroes). A value can have any length, including zero. This type is a string type.

The type is used for digital signatures on extended certificates in PKCS #6's type, for digital signatures on certificates in X.509's type, and for public keys in certificates in X.509's type.

ASN.1 notation:

Example: X.509's type has a component of type :

SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, publicKey BIT STRING }

BER encoding. Primitive or constructed. In a primitive encoding, the first contents octet gives the number of bits by which the length of the bit string is less than the next multiple of eight (this is called the "number of unused bits"). The second and following contents octets give the value of the bit string, converted to an octet string. The conversion process is as follows:

  1. The bit string is padded after the last bit with zero to seven bits of any value to make the length of the bit string a multiple of eight. If the length of the bit string is a multiple of eight already, no padding is done.
  2. The padded bit string is divided into octets. The first eight bits of the padded bit string become the first octet, bit 8 to bit 1, and so on through the last eight bits of the padded bit string.

In a constructed encoding, the contents octets give the concatenation of the BER encodings of consecutive substrings of the bit string, where each substring except the last has a length that is a multiple of eight bits.

Example: The BER encoding of the value "011011100101110111" can be any of the following, among others, depending on the choice of padding bits, the form of length octets, and whether the encoding is primitive or constructed:

03 04 06 6e 5d c0DER encoding
03 04 06 6e 5d e0padded with "100000"
03 81 04 06 6e 5d c0long form of length octets
23 09 03 03 00 6e 5d 03 02 06 c0constructed encoding: "0110111001011101" + "11"

DER encoding. Primitive. The contents octects are as for a primitive BER encoding, except that the bit string is padded with zero-valued bits.

Example: The DER encoding of the value "011011100101110111" is

03 04 06 6e 5d c0

5.5 CHOICE

The type denotes a union of one or more alternatives.

The type is used to represent the union of an extended certificate and an X.509 certificate in PKCS #7's type.

ASN.1 notation:

{
[identifier1] Type1,
...,
[identifiern] Typen }

where identifier1 , ..., identifiern are optional, distinct identifiers for the alternatives, and Type1, ..., Typen are the types of the alternatives. The identifiers are primarily for documentation; they do not affect values of the type or their encodings in any way.

The types must have distinct tags. This requirement is typically satisfied with explicit or implicit tagging on some of the alternatives.

Example: PKCS #7's type is a type:

ExtendedCertificateOrCertificate ::= CHOICE { certificate Certificate, -- X.509 extendedCertificate [0] IMPLICIT ExtendedCertificate }

Here the identifiers for the alternatives are and , and the types of the alternatives are and .

BER encoding. Same as the BER encoding of the chosen alternative. The fact that the alternatives have distinct tags makes it possible to distinguish between their BER encodings.

Example: The identifier octets for the BER encoding are if the chosen alternative is certificate, and if the chosen alternative is

DER encoding. Same as the DER encoding of the chosen alternative.

5.6 IA5String

The type denotes an arbtrary string of IA5 characters. IA5 stands for International Alphabet 5, which is the same as ASCII. The character set includes non- printing control characters. An value can have any length, including zero. This type is a string type.

The is used in PKCS #9's electronic-mail address, unstructured-name, and unstructured-address attributes.

ASN.1 notation:

BER encoding. Primitive or constructed. In a primitive encoding, the contents octets give the characters in the IA5 string, encoded in ASCII. In a constructed encoding, the contents octets give the concatenation of the BER encodings of consecutive substrings of the IA5 string.

Example: The BER encoding of the value "test1@rsa.com" can be any of the following, among others, depending on the form of length octets and whether the encoding is primitive or constructed:

16 0d 74 65 73 74 31 40 72 73 61 2e 63 6f 6dDER encoding
16 81 0d 74 65 73 74 31 40 72 73 61 2e 63 6f 6dlong form of length octets
36 13 16 05 74 65 73 74 31 16 01 40 16 07 72 73 61 2e 63 6f 6dconstructed encoding: "test1" + "@" + "rsa.com"

DER encoding. Primitive. Contents octets are as for a primitive BER encoding.

Example: The DER encoding of the IA5String value "test1@rsa.com" is

16 0d 74 65 73 74 31 40 72 73 61 2e 63 6f 6d

5.7 INTEGER

The type denotes an arbitrary integer. values can be positive, negative, or zero, and can have any magnitude.

The type is used for version numbers throughout PKCS, cryptographic values such as modulus, exponent, and primes in PKCS #1's and types and PKCS #3's type, a message-digest iteration count in PKCS #5's type, and version numbers and serial numbers in X.509's type.

ASN.1 notation:

[{ identifier1(value1) ... identifiern(valuen) }]

where identifier1, ..., identifiern are optional distinct identifiers and value1, ..., valuen are optional integer values. The identifiers, when present, are associated with values of the type.

Example: X.509's Version type is an type with identified values:

Version ::= INTEGER { v1988(0) } The identifier is associated with the value 0. X.509's type uses the identifier to give a default value of 0 for the version component: Certificate ::= ... version Version DEFAULT v1988, ...

BER encoding. Primitive. Contents octets give the value of the integer, base 256, in two's complement form, most significant digit first, with the minimum number of octets. The value 0 is encoded as a single octet.

Some example BER encodings (which also happen to be DER encodings) are given in Table 3.

Integer
value
BER encoding
0
127
128
256
-128
-129

Table 3. Example BER encodings of INTEGER values.

DER encoding. Primitive. Contents octets are as for a primitive BER encoding.

5.8 NULL

The type denotes a null value.

The type is used for algorithm parameters in several places in PKCS.

ASN.1 notation:

BER encoding. Primitive. Contents octets are empty.

Example: The BER encoding of a value can be either of the following, as well as others, depending on the form of the length octets:

05 00 05 81 00

DER encoding. Primitive. Contents octets are empty; the DER encoding of a NULL value is always

5.9 OBJECT IDENTIFIER

The type denotes an object identifier, a sequence of integer components that identifies an object such as an algorithm, an attribute type, or perhaps a registration authority that defines other object identifiers. An value can have any number of components, and components can generally have any nonnegative value. This type is a non-string type.

values are given meanings by registration authorities. Each registration authority is responsible for all sequences of components beginning with a given sequence. A registration authority typically delegates responsibility for subsets of the sequences in its domain to other registration authorities, or for particular types of object. There are always at least two components.

The type is used to identify content in PKCS #7's type, to identify algorithms in X.509's type, and to identify attributes in X.501's and types. The type is used by PKCS #6, #7, #8, #9, and #10, and the type is used in X.501 distinguished names. values are defined throughout PKCS.

ASN.1 notation:

The ASN.1 notation for values of the type is

{ [identifier] component1 ... componentn }

componenti = identifieri | identifieri (valuei) | valuei

where identifier, identifier1, ..., identifiern are identifiers, and value1, ..., valuen are optional integer values.

The form without identifier is the "complete" value with all its components; the form with identifier abbreviates the beginning components with another object identifier value. The identifiers identifier1, ..., identifiern are intended primarily for documentation, but they must correspond to the integer value when both are present. These identifiers can appear without integer values only if they are among a small set of identifiers defined in X.208.

Example: The following values both refer to the object identifier assigned to RSA Data Security, Inc.:

{ iso(1) member-body(2) 840 113549 } { 1 2 840 113549 }

(In this example, which gives ASN.1 value notation, the object identifier values are decimal, not hexadecimal.) Table 4 gives some other object identifier values and their meanings.

Object identifier valueMeaning
{ 1 2 }ISO member bodies
{ 1 2 840 }US (ANSI)
{ 1 2 840 113549 }RSA Data Security, Inc.
{ 1 2 840 113549 1 }RSA Data Security, Inc. PKCS
{ 2 5 }directory services (X.500)
{ 2 5 8 }directory services-algorithms

Table 4. Some object identifier values and their meanings.

BER encoding. Primitive. Contents octets are as follows, where value1, ..., valuen denote the integer values of the components in the complete object identifier:

  1. The first octet has value 40 * value1 + value2. (This is unambiguous, since value1 is limited to values 0, 1, and 2; value2 is limited to the range 0 to 39 when value1 is 0 or 1; and, according to X.208, n is always at least 2.)
  2. The following octets, if any, encode value3, ..., valuen. Each value is encoded base 128, most significant digit first, with as few digits as possible, and the most significant bit of each octet except the last in the value's encoding set to "1."

Example: The first octet of the BER encoding of RSA Data Security, Inc.'s object identifier is 40 * 1 + 2 = 42 = . The encoding of 840 = 6 * 128 + 4816 is and the encoding of 113549 = 6 * 1282 + 7716 * 128 + d16 is This leads to the following BER encoding:

06 06 2a 86 48 86 f7 0d

DER encoding. Primitive. Contents octets are as for a primitive BER encoding.

5.10 OCTET STRING

The type denotes an arbitrary string of octets (eight-bit values). An value can have any length, including zero. This type is a string type.

The type is used for salt values in PKCS #5's type, for message digests, encrypted message digests, and encrypted content in PKCS #7, and for private keys and encrypted private keys in PKCS #8.

ASN.1 notation:

({size | size1..size2})]

where size, size1, and size2 are optional size constraints. In the (size) form, the octet string must have size octets. In the (size1..size2) form, the octet string must have between size1 and size2 octets. In the form, the octet string can have any size.

Example: PKCS #5's type has a component of type :

PBEParameter ::= SEQUENCE { salt OCTET STRING SIZE(8), iterationCount INTEGER }

Here the size of the salt component is always eight octets.

BER encoding. Primitive or constructed. In a primitive encoding, the contents octets give the value of the octet string, first octet to last octet. In a constructed encoding, the contents octets give the concatenation of the BER encodings of substrings of the value.

Example: The BER encoding of the value can be any of the following, among others, depending on the form of length octets and whether the encoding is primitive or constructed:

04 08 01 23 45 67 89 ab cd efDER encoding
04 81 08 01 23 45 67 89 ab cd eflong form of length octets
24 0c 04 04 01 23 45 67 04 04 89 ab cd efconstructed encoding: 01 ... 67 + 89 ... ef

DER encoding. Primitive. Contents octets are as for a primitive BER encoding.

Example: The BER encoding of the value is

04 08 01 23 45 67 89 ab cd ef

5.11 PrintableString

The type denotes an arbitrary string of printable characters from the following character set:

(space)

This type is a string type.

The type is used in PKCS #9's challenge- password and unstructured-address attributes, and in several X.521 distinguished names attributes.

ASN.1 notation:

BER encoding. Primitive or constructed. In a primitive encoding, the contents octets give the characters in the printable string, encoded in ASCII. In a constructed encoding, the contents octets give the concatenation of the BER encodings of consecutive substrings of the string.

Example: The BER encoding of the value "Test User 1" can be any of the following, among others, depending on the form of length octets and whether the encoding is primitive or constructed:

13 0b 54 65 73 74 20 55 73 65 72 20 31DER encoding
13 81 0b 54 65 73 74 20 55 73 65 72 20 31long form of length octets
33 0f 13 05 54 65 73 74 20 13 06 55 73 65 72 20 31constructed encoding: "Test " + "User 1"

DER encoding. Primitive. Contents octets are as for a primitive BER encoding.

Example: The DER encoding of the value "Test User 1" is

13 0b 54 65 73 74 20 55 73 65 72 20 31

5.12 SEQUENCE

The type denotes an ordered collection of one or more types.

The type is used throughout PKCS and related standards.

ASN.1 notation:

{
[identifier1] Type1 [{value1}],
...,
[identifiern] Typen [{
valuen}]}

where identifier1 , ..., identifiern are optional, distinct identifiers for the components, Type1, ..., Typen are the types of the components, and value1, ..., valuen are optional default values for the components. The identifiers are primarily for documentation; they do not affect values of the type or their encodings in any way.

The qualifier indicates that the value of a component is optional and need not be present in the sequence. The qualifier also indicates that the value of a component is optional, and assigns a default value to the component when the component is absent.

The types of any consecutive series of components with the or qualifier, as well as of any component immediately following that series, must have distinct tags. This requirement is typically satisfied with explicit or implicit tagging on some of the components.

Example: X.509's type is a type with two components:

Validity ::= SEQUENCE { start UTCTime, end UTCTime }

Here the identifiers for the components are start and end, and the types of the components are both .

BER encoding. Constructed. Contents octets are the concatenation of the BER encodings of the values of the components of the sequence, in order of definition, with the following rules for components with the and qualifiers:

  • if the value of a component with the or qualifier is absent from the sequence, then the encoding of that component is not included in the contents octets
  • if the value of a component with the qualifier is the default value, then the encoding of that component may or may not be included in the contents octets

DER encoding. Constructed. Contents octets are the same as the BER encoding, except that if the value of a component with the qualifier is the default value, the encoding of that component is not included in the contents octets.

5.13 SEQUENCE OF

The type denotes an ordered collection of zero or more occurrences of a given type.

The type is used in X.501 distinguished names.

ASN.1 notation:

Type

where Type is a type.

Example: X.501's type consists of zero or more occurences of the type, most significant occurrence first:

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

BER encoding. Constructed. Contents octets are the concatenation of the BER encodings of the values of the occurrences in the collection, in order of occurence.

DER encoding. Constructed. Contents octets are the concatenation of the DER encodings of the values of the occurrences in the collection, in order of occurence.

5.14 SET

The type denotes an unordered collection of one or more types.

The type is not used in PKCS.

ASN.1 notation:

{
[identifier1] Type1 [{value1}],
...,
[identifiern] Typen [{
valuen}]}

where identifier1, ..., identifiern are optional, distinct identifiers for the components, Type1, ..., Typen are the types of the components, and value1, ..., valuen are optional default values for the components. The identifiers are primarily for documentation; they do not affect values of the type or their encodings in any way.

The qualifier indicates that the value of a component is optional and need not be present in the set. The qualifier also indicates that the value of a component is optional, and assigns a default value to the component when the component is absent.

The types must have distinct tags. This requirement is typically satisfied with explicit or implicit tagging on some of the components.

BER encoding. Constructed. Contents octets are the concatenation of the BER encodings of the values of the components of the set, in any order, with the following rules for components with the and qualifiers:

  • if the value of a component with the or qualifier is absent from the set, then the encoding of that component is not included in the contents octets
  • if the value of a component with the qualifier is the default value, then the encoding of that component may or may not be included in the contents octets

DER encoding. Constructed. Contents octets are the same as for the BER encoding, except that:

  1. If the value of a component with the qualifier is the default value, the encoding of that component is not included.
  2. There is an order to the components, namely ascending order by tag.

5.15 SET OF

The type denotes an unordered collection of zero or more occurrences of a given type.

The type is used for sets of attributes in PKCS #6, #7, #8, #9 and #10, for sets of message-digest algorithm identifiers, signer information, and recipient information in PKCS #7, and in X.501 distinguished names.

ASN.1 notation:

Type

where Type is a type.

Example: X.501's type consists of zero or more occurrences of the type, where the order is unimportant:

RelativeDistinguishedName ::= SET OF AttributeValueAssertion

BER encoding. Constructed. Contents octets are the concatenation of the BER encodings of the values of the occurrences in the collection, in any order.

DER encoding. Constructed. Contents octets are the same as for the BER encoding, except that there is an order, namely ascending lexicographic order of BER encoding. Lexicographic comparison of two different BER encodings is done as follows: Logically pad the shorter BER encoding after the last octet with dummy octets that are smaller in value than any normal octet. Scan the BER encodings from left to right until a difference is found. The smaller-valued BER encoding is the one with the smaller-valued octet at the point of difference.

5.16 T61String

The type denotes an arbtrary string of T.61 characters. T.61 is an eight-bit extension to the ASCII character set. Special "escape" sequences specify the interpretation of subsequent character values as, for example, Japanese; the initial interpretation is Latin. The character set includes non-printing control characters. The type allows only the Latin and Japanese character interepretations, and implementors' agreements for directory names exclude control characters [NIST92]. A value can have any length, including zero. This type is a string type.

The type is used in PKCS #9's unstructured-address and challenge-password attributes, and in several X.521 attributes.

ASN.1 notation:

BER encoding. Primitive or constructed. In a primitive encoding, the contents octets give the characters in the T.61 string, encoded in ASCII. In a constructed encoding, the contents octets give the concatenation of the BER encodings of consecutive substrings of the T.61 string.

Example: The BER encoding of the value "cl'es publiques" (French for "public keys") can be any of the following, among others, depending on the form of length octets and whether the encoding is primitive or constructed:

14 0f 63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73DER encoding
14 81 0f 63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73long form of length octets
34 15 14 05 63 6c c2 65 73 14 01 20 14 09 70 75 62 6c 69 71 75 65 73constructed encoding: "cl'es" + " " + "publiques"

The eight-bit character c2 is a T.61 prefix that adds an acute accent (') to the next character.

DER encoding. Primitive. Contents octets are as for a primitive BER encoding.

Example: The DER encoding of the value "cl'es publiques" is

14 0f 63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73

5.17 UTCTime

The type denotes a "coordinated universal time" or Greenwich Mean Time (GMT) value. A value includes the local time precise to either minutes or seconds, and an offset from GMT in hours and minutes. It takes any of the following forms:

YYMMDDhhmmZ
YYMMDDhhmm+hh'mm'
YYMMDDhhmm-hh'mm'
YYMMDDhhmmssZ
YYMMDDhhmmss+hh'mm'
YYMMDDhhmmss-hh'mm'

where:

YY is the least significant two digits of the year

MM is the month (01 to 12)

DD is the day (01 to 31)

hh is the hour (00 to 23)

mm are the minutes (00 to 59)

ss are the seconds (00 to 59)

Z indicates that local time is GMT, + indicates that local time is later than GMT, and - indicates that local time is earlier than GMT

hh' is the absolute value of the offset from GMT in hours

mm' is the absolute value of the offset from GMT in minutes

This type is a string type.

The type is used for signing times in PKCS #9's signing-time attribute and for certificate validity periods in X.509's type.

ASN.1 notation:

BER encoding. Primitive or constructed. In a primitive encoding, the contents octets give the characters in the string, encoded in ASCII. In a constructed encoding, the contents octets give the concatenation of the BER encodings of consecutive substrings of the string. (The constructed encoding is not particularly interesting, since values are so short, but the constructed encoding is permitted.)

Example: The time this sentence was originally written was 4:45:40 p.m. Pacific Daylight Time on May 6, 1991, which can be represented with either of the following values, among others:

"910506164540-0700"

"910506234540Z"

These values have the following BER encodings, among others:

17 0d 39 31 30 35 30 36 32 33 34 35 34 30 5a 17 11 39 31 30 35 30 36 31 36 34 35 34 30 2D 30 37 30 30

DER encoding. Primitive. Contents octets are as for a primitive BER encoding.

6. An example

This section gives an example of ASN.1 notation and DER encoding: the X.501 type .

6.1 Abstract notation

This section gives the ASN.1 notation for the X.501 type . Name ::= CHOICE { RDNSequence } RDNSequence ::= SEQUENCE OF RelativeDistinguishedName RelativeDistinguishedName ::= SET OF AttributeValueAssertion AttributeValueAssertion ::= SEQUENCE { AttributeType, AttributeValue } AttributeType ::= OBJECT IDENTIFIER AttributeValue ::= ANY

The type identifies an object in an X.500 directory. is a type consisting of one alternative: . (Future revisions of X.500 may have other alternatives.)

The type gives a path through an X.500 directory tree starting at the root. is a type consisting of zero or more occurences of .

The type gives a unique name to an object relative to the object superior to it in the directory tree.


Previous: Modules Up: Modules and Assignments Next: Value Assignment


Type Assignment

  A type assignment consists of a type reference (the name of the type), the character sequence ::= (‘‘is defined as’’), and the appropriate type. Each of the components must be separated by at least one space. The type reference must be a character string consisting of only upper and lower case letters, digits 0 to 9, or a hyphen. None of the other ASN.1 characters : ; = , < . ( ) [ ] ' " may be used. A type reference must begin with an upper case letter, not end with a hyphen, and not contain two consecutive hyphens. Comments in ASN.1 begin with two consecutive hyphens and end either with two consecutive hyphens or the end of a line. In the module body (from the below Figure that was repeated from the previous page), the name ItemId has type SEQUENCE and StoreLocation has type ENUMERATED. There are four component values in the sequence: partnumber, quantity, wholesaleprice, and saleprice. StoreLocation has the three component values Baltimore, Philadelphia, and Washington.

  InventoryList {1 2 0 0 6 1} DEFINITIONS ::= BEGIN { ItemId ::= SEQUENCE { partnumber IA5String, quantity INTEGER, wholesaleprice REAL, saleprice REAL } StoreLocation ::= ENUMERATED { Baltimore (0), Philadelphia (1), Washington (2) } } END
This site was developed from:
Computer Networks and Open Systems
An Application Development Perspective

by
Lillian N. Cassel
Richard H. Austing

Jones & Bartlett Publisher
ISBN 0-7637-1122-5

This site is hosted by:


One thought on “Asn 1 Value Assignment Sheet

Leave a Reply

Your email address will not be published. Required fields are marked *