]> Verisign

12061 Bluemont Way Reston VA 20190 US bkaliski@verisign.com https://www.verisignlabs.com/

TurboLight Solutions, LLC

US corey.bonnell@turbolightsolutions.com

Keyfactor

AU david.hook@keyfactor.com

Vigil Security, LLC

US housley@vigilsec.com

Internet-Draft This note gives a layman's introduction to a subset of the Abstract Syntax Notation One (ASN.1), Basic Encoding Rules (BER), and Distinguished Encoding Rules (DER). The purpose of this note is to provide background material sufficient for understanding and implementing standards that make use of ASN.1. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This memo offers tutorial information.

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. The Open Systems Interconnection (OSI) series of standards involve a great deal of abstraction. OSI is an internationally standardized architecture for 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) , and one set of rules for representing such objects as strings of ones and zeros is called the BER (Basic Encoding Rules) . ASN.1 is a flexible notation that allows one to define a variety of 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, DER (Distinguished Encoding Rules) , 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 OSI-based applications, Public-Key Cryptography Standards (PKCS), and Internet protocols that make use of ASN.1. 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. Features that are not used in the specifications listed above are not described in this note. For information on the other features, and for more detail generally, the reader is referred to and , which define ASN.1, BER, and DER. 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. Section 6 concludes with an example, X.500 distinguished names.

Background The first version of this document was published on June 3, 1991 as part of the initial public release of PKCS. It was published as NIST/OSI Implementors' Workshop document SEC-SIG-91-17. The second version of this document was published on November 1, 1993 as a RSA Laboratories Technical Note. The third version of this document is the Internet-Draft , which is a republication of the second version. It includes the following notice:

• This document represents a republication of A Layman's Guide to a Subset of ASN.1, BER, and DER, originally authored and published by RSA Security USA LLC. This document is submitted with permission from, and on behalf of RSA Security USA LLC. By publishing this document, change control is transferred to the IETF and the Internet technical community in full conformance with the provisions of BCP 78 and BCP 79.

This document is the fourth version, and the first under the transfer of change control. The changes from the third version include:

• Discussion of CLASS was added as the replacement for ANY following the modern ASN.1 specification;
• Discussion of UTF8String, GeneralizedTime, and RELATIVE-OID were added;
• The use of T61String is discouraged;
• Clarified the allowable numbers in the first and second values of an OBJECT IDENTIFIER; and
• References were updated, and PKCS documents are now referenced by their RFC number.

This work is not a product of the IETF, does not represent a standard, and has not achieved community consensus.

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. When an octet is written in binary, bit 8 is the leftmost bit; for example, the octet 80 has only bit 8 set and the octet 01 has only bit 1 set. Bit numbers are used only to describe the fields within a single octet. A sequence of octets is always written, and transmitted, with the first octet first. The following meta-syntax is used for describing ASN.1 notation in the ASN.1 notation figures and accompanying text: ASN.1 notation meta-syntax.

Notation	Meaning
BIT	all-caps (and monospace HTML and PDF) denotes literal characters in the type and value notation; in examples, it generally denotes an octet value in hexadecimal
n1	lowercase denotes a variable, identifier, or value. In explanatory text the variable is surrounded by single quotes, e.g. 'n1'
Type1	Initial-caps denotes a type. In explanatory text the type is surrounded by single quotes, e.g. 'Type1'
[]	brackets indicate that a term is optional
{}	braces group related terms
|	vertical bar delimits alternatives with a group
...	ellipsis indicates repeated occurrences
=	equals sign expresses terms as subterms

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

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. ASN.1 has two kinds of notation. Type notation describes a type, such as INTEGER or SEQUENCE { ... }. Value notation specifies a particular value of a type. For example, { 2 5 4 } is value notation for a value of type OBJECT IDENTIFIER, and TRUE is value notation for a value of type BOOLEAN. A named value is defined with the assignment operator, as in id-at OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) ds(5) 4 }. Every ASN.1 type other than CHOICE and ANY has a tag, which consists of a class and a nonnegative tag number. An encoding carries its tag instead of a type name, so a decoder uses the tag to learn what kind of value it is. explains how tags distinguish the components of a structured type, and shows how a tag is encoded. There are four classes of tag:

Universal:

for types whose meaning is the same in all applications; these types are specified in .

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 , 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. Some types and their universal-class tags.

Type	Decimal Tag Number	Hexadecimal Tag Number
BOOLEAN	1	01
INTEGER	2	02
BIT STRING	3	03
OCTET STRING	4	04
NULL	5	05
OBJECT IDENTIFIER	6	06
UTF8String	12	0c
RELATIVE-OID	13	0d
SEQUENCE and SEQUENCE OF	16	10
SET and SET OF	17	11
PrintableString	19	13
T61String	20	14
IA5String	22	16
UTCTime	23	17
GeneralizedTime	24	18

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 take one of two forms. A comment begins with a pair of hyphens (--) and ends with another pair of hyphens or a line break, so it is always contained on a single line. A comment can also begin with /* and end with */; this form can span multiple lines.
• Identifiers (names of values and fields) and type references (names of types) consist of upper- and lower-case letters, digits, and hyphens; identifiers begin with lower-case letters; type references begin with upper-case letters. A hyphen can appear within a name, but it cannot be the last character or be followed by another hyphen, since two hyphens begin a comment.

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.

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:

• BIT STRING

  an arbitrary string of bits (ones and zeroes).

• BOOLEAN

  a Boolean value, either true or false.

• IA5String

  an arbitrary string of IA5 (ASCII) characters .

• INTEGER

  an arbitrary integer.

• NULL

  a null value.

• OBJECT IDENTIFIER

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

• RELATIVE-OID

  a relative object identifier, which is a sequence of integer components interpreted relative to some object identifier established by context.

• OCTET STRING

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

• UTF8String

  an arbitrary string of international characters using UTF-8 encoding.

• PrintableString

  an arbitrary string of printable characters. The allowable characters are listed in .

• T61String

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

• UTCTime

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

• GeneralizedTime

  a time value in the local time zone, GMT, or the difference between local and GMT.

Simple types fall into two categories: string types and non-string types. The character string types (IA5String, PrintableString, T61String, and UTF8String) and the time types (GeneralizedTime and UTCTime) are string types because their values are sequences of characters. BIT STRING and OCTET STRING are also string types, although their values are sequences of bits and octets rather than characters. 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.

Structured types Structured types are those consisting of components. ASN.1 defines four, all of which are relevant to the PKCS standards:

• SEQUENCE

  an ordered collection of one or more types.

• SEQUENCE OF

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

• SET

  an unordered collection of one or more types.

• SET OF

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

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

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 SET or SEQUENCE 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] IMPLICIT (see ). 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] EXPLICIT (see ). 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 CHOICE or ANY).

Other types Other types in ASN.1 include the CHOICE and ANY types. The CHOICE type denotes a union of one or more alternatives; the ANY 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.

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, and ASN.1 syntax itself does not dictate the encoding 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 (such as BOOLEAN, INTEGER, NULL, and OBJECT IDENTIFIER) 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 a BIT STRING, the first contents octet is the "unused bits" octet; see .) 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.

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.

• 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".

Class encoding in identifier octets.

Class	Bit 8	Bit 7
universal	0	0
application	0	1
context-specific	1	0
private	1	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. For example, the length for an encoding that has 32 contents octets would encode simply as 20.

• 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. For example, the length for an encoding that has 3200 contents octets would encode simply as 82 0c 80, the first octet indicating that the length is in the following 2 octets and the next two octets give the value of the length.

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 .

Prefixes and Magic Numbers It is worth noting that definite-length encodings, by their nature, are simple enough to parse without the need for a complete ASN.1 decoder and prefixes to the contents octets can often be treated like magic numbers in order to recognise the contents octets that are following. For example, the private key field of an encoded ML-DSA-44 private key, which is defined in as a CHOICE item with the following structure: can be recomposed as a series of contents octets preceded by one of the following prefixes and breakdowns: Prefixes for an ML-DSA private key CHOICE item.

Prefix	CHOICE Item	Breakdown
80 20	seed	tag 0x80, short form, length 1 octet, value 32
04 82 0a 00	expandedKey	tag 0x04, long form, length 3 octets, value 2560
30 82 0a 26	both	tag 0x30, long form, length 3 octets, value 2598

As can be seen from the table, the first octet of each prefix can be used to distinguish the CHOICE item that has been used to describe the ML-DSA-44 private key value. The three-octet lengths for expandedKey and both start with 0x82 and indicate that the real length of the contents octets is two octets long. Consider the both item within the CHOICE, where the contents octets are the encodings of the two elements of the SEQUENCE. These elements have no context-specific tags. The seed inside the SEQUENCE is a plain OCTET STRING, so its prefix is 04 20. It is not the 80 20 prefix of the seed CHOICE item, which carries the [0] tag. The expandedKey inside the SEQUENCE has the same 04 82 0a 00 prefix as the second row. The contents octets of both are therefore the 34 octets of the seed encoding followed by the 2564 octets of the expandedKey encoding, 2598 octets in total.

Constructed, definite-length method This method applies to simple string types, structured types, types derived from 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 , except that bit 6 has value "1", indicating that the encoding is constructed.

length octets.

As described in .

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 example, an OCTET STRING of length 8 encoded as a definite-length constructed encoding would encode as: 24 0c 04 04 00000000 04 04 00000000.

• • 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 .

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 .

length octets.

One octet, 80.

contents octets.

As described in .

end-of-contents octets.

Two octets, 00 00.

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. Considering our previous example of an 8 byte OCTET STRING in constructed form with 4 byte elements, the indefinite length encoding would produce: 24 80 04 04 00000000 04 04 00000000 0000.

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. BER and DER are defined in . DER adds the following restrictions to the rules given in :

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 BOOLEAN, BIT STRING, SEQUENCE, SET, and SET OF), and can be found in .

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 . 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 types OBJECT IDENTIFIER and RELATIVE-OID, value notation is given as well.

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 SEQUENCE components with underlying type other than ANY in many protocols, including and . ASN.1 notation: 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 IMPLICIT is implied (see ). For definitions stated outside a module, the explicit inclusion of the keyword IMPLICIT 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 CHOICE type. Example: PKCS #8 PrivateKeyInfo type has an optional attributes component with an implicit, context-specific tag: Here the underlying type is Attributes, 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. The contents octets are as for the BER encoding of the underlying value. Example: The BER encoding of the attributes component of a PrivateKeyInfo value is as follows:

• • the identifier octets are a0, because Attributes is a SET OF type and its BER encoding is therefore always constructed

• • the length and contents octets are the same as the length and contents octets of the BER encoding of the underlying Attributes value

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

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 SEQUENCE components with underlying type ANY in many protocols, including the content component of the ContentInfo type . It is also used for components of any underlying type when the default tagging for an ASN.1 module is explicit, as is the case for the version component of the TBSCertificate type . ASN.1 notation: 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 SEQUENCE, SET or CHOICE type. In ASN.1 "modules" whose default tagging method is explicit tagging, the notation [[class] number ] Type is also acceptable, and the keyword EXPLICIT is implied (see ). For definitions stated outside a module, the explicit inclusion of the keyword EXPLICIT is preferable to prevent ambiguity. Example 1: The CMS ContentInfo type has an optional content component with an explicit, context-specific tag: Here the underlying type is ANY DEFINED BY contentType, the class is absent (i.e., context-specific), and the tag number within the class is 0. Example 2: the TBSCertificate type has a version component of type Version, which is an INTEGER type (see ), with an explicit, context-specific tag: The tag is explicit because the default tagging method for the ASN.1 module in that defines the TBSCertificate type is explicit tagging.

BER Encoding Constructed. The contents octets are the BER encoding of the underlying value. Example: the BER encoding of the content component of a ContentInfo value is as follows:

• • identifier octets are a0

• • length octets represent the length of the BER encoding of the underlying ANY DEFINED BY contentType value

• • contents octets are the BER encoding of the underlying ANY DEFINED BY contentType value

DER Encoding Constructed. The contents octets are the DER encoding of the underlying value.

ANY In the original ASN.1 specification, the ANY 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. In , the ANY type is used for content of a particular content type within the ContentInfo type. In and , the ANY type is used for parameters of a particular algorithm within the AlgorithmIdentifier type. In , the ANY type is used for attribute values within the Attribute type. ASN.1 notation: where 'identifier' is an optional identifier. In the ANY form, the actual type is indeterminate. The ANY DEFINED BY identifier form can only appear in a component of a SEQUENCE or SET type for which identifier identifies some other component, and that other component has type INTEGER or OBJECT IDENTIFIER (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: The AlgorithmIdentifier type has a component of type ANY: Here the actual type of the parameter component depends on the value of the algorithm component. The actual type would be defined in the registration of object identifier values for the algorithm component.

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

DER Encoding Same as the DER encoding of the actual value. In the modern ASN.1 specification, the CLASS construction replaces the ANY type. Example: The AlgorithmIdentifier type can be implemented as shown below, which is a simplification of the definition in : Of course, the BER and DER encoding are unchanged. The AlgorithmSet makes it easier for implementers to determine all of the algorithm identifiers and the associated type for parameters, if any are defined.

BIT STRING The BIT STRING type denotes an arbitrary string of bits (ones and zeroes). A BIT STRING value can have any length, including zero. This type is a string type. The BIT STRING type is used for digital signatures on certificates and for public keys in the SubjectPublicKeyInfo type . ASN.1 notation: Example: SubjectPublicKeyInfo type has a component of type 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 first contents octet is always encoded; if the length of the bit string is 0 bits, then the first contents octet will have the value 0 and there will be no subsequent contents octets. 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.

Put another way, the first bit of the bit string becomes bit 8, the leftmost and most significant bit, of the first octet. A bit string written left to right therefore reads in the same order as the binary digits of the octets that encode it, and the examples below can be checked by grouping the bits of the string into groups of eight. 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 BIT STRING 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:

DER Encoding Primitive. The contents octets are as for a primitive BER encoding, except that the bit string is padded with zero-valued bits. Additionally, BIT STRINGs that represent named bit lists, such as the value of the Key Usage certificate extension , have all trailing 0 bits removed before they are encoded. Example: The DER encoding of the BIT STRING value "011011100101110111" is: Example: The DER encoding of a Key Usage certificate extension value, asserting only the digitalSignature bit:

BOOLEAN The BOOLEAN type denotes a Boolean value, which is either true or false. This type is a non-string type. The BOOLEAN type is used for flags such as the cA component of the BasicConstraints type . ASN.1 notation: The ASN.1 value notation is TRUE or FALSE.

BER Encoding Primitive. A single octet in length, for FALSE the octet is set to zero, for TRUE, the octet is non-zero.

DER Encoding Primitive. A single octet in length, for FALSE the octet is set to zero, for TRUE, the octet is set to 0xFF. Example: The DER encoding of the BOOLEAN value TRUE is:

CHOICE The CHOICE type denotes a union of one or more alternatives. The CHOICE type is used to represent the union of an extended certificate and an X.509 certificate in the ExtendedCertificateOrCertificate type specified in . ASN.1 notation: 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: In , the ExtendedCertificateOrCertificate type is a CHOICE type: Here the identifiers for the alternatives are certificate and extendedCertificate, and the types of the alternatives are Certificate and [0] IMPLICIT ExtendedCertificate.

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 30 if the chosen alternative is certificate, and a0 if the chosen alternative is extendedCertificate.

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

IA5String The IA5String type denotes an arbitrary 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 IA5String value can have any length, including zero. This type is a string type. The IA5String type is used in the PKCS #9 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 IA5String value "test1@example.com" can be any of the following, among others, depending on the form of length octets and whether the encoding is primitive or constructed:

DER Encoding Primitive. The contents octets are as for a primitive BER encoding. Example: The DER encoding of the IA5String value "test1@example.com" is

INTEGER The INTEGER type denotes an arbitrary integer. INTEGER values can be positive, negative, or zero, and can have any magnitude. The INTEGER type is used for version numbers in many protocols, including and . The INTEGER type is used for cryptographic values such as modulus, exponent, and primes in the PKCS #1 RSAPublicKey and RSAPrivateKey types . The INTEGER type is used for a message-digest iteration count in PKCS #5 PBEParameter type . ASN.1 notation: 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. INTEGER is always signed. Example: Version type is an INTEGER type with identified values: The identifier v1 is associated with the value 0. The TBSCertificate type uses the identifier v1 to give a default value of 0 for the version component:

BER Encoding Primitive. The 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 00 octet. Some example BER encodings (which also happen to be DER encodings) are given in Table 3. Example BER encodings of INTEGER values.

Integer value	BER encoding
0	02 01 00
127	02 01 7F
128	02 02 00 80
256	02 02 01 00
-128	02 01 80
-129	02 02 FF 7F

DER Encoding Primitive. The contents octets are as for a primitive BER encoding.

NULL The NULL type denotes a null value. The NULL type is used in several places as a required placeholder for algorithm parameters, including . ASN.1 notation:

BER Encoding Primitive. The contents octets are empty. Example: The BER encoding of a NULL value can be either of the following, as well as others, depending on the form of the length octets:

DER Encoding Primitive. The contents octets are empty; the DER encoding of a NULL value is always 05 00.

OBJECT IDENTIFIER The OBJECT IDENTIFIER 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 OBJECT IDENTIFIER value can have any number of components, and components can generally have any nonnegative value. This type is a non-string type. OBJECT IDENTIFIER 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 OBJECT IDENTIFIER type is used to identify content in ContentInfo type , to identify algorithms in AlgorithmIdentifier type and . ASN.1 notation: The ASN.1 notation for values of the OBJECT IDENTIFIER type is where 'identifier', 'identifier1', ..., 'identifierN' are identifiers, 'value1', ..., 'valueN' are optional integer values, and each 'componentI', for I from 1 to N, takes one of the three forms shown. 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 . Example: The following values both refer to the object identifier assigned to RSA Data Security, Inc.: (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. Some object identifier values and their meanings.

Object identifier value	Meaning
{ 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

BER Encoding Primitive. The contents octets are as follows, where 'value1', ..., 'valueN' denote the integer values of the components in the complete object identifier:

1. The first two components ('value1' and 'value2') are encoded as a single value 40 * 'value1' + 'value2', then encoded using the same base-128, most-significant-digit-first scheme described in step 2. When 'value1' is 0 or 1, 'value2' is limited to the range 0 to 39, so this combined value fits in a single octet (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 , N is always at least 2.). When 'value1' is 2, 'value2' is unbounded, so 'value1' and 'value2' may require multiple octets.
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". As a consequence of encoding each component with as few digits as possible, the first octet of a component's encoding is never 0x80 (128 decimal).

Example: The first octet of the BER encoding of RSA Data Security, Inc.'s object identifier is 40 * 1 + 2 = 42 = 2a (hexadecimal). The encoding of 840 = 6 * 128 + 48 (hexadecimal) is 86 48 and the encoding of 113549 = 6 * 128^2 + 77 (hexadecimal) * 128 + d (hexadecimal) is 86 f7 0d. This leads to the following BER encoding:

DER Encoding Primitive. The contents octets are as for a primitive BER encoding.

OCTET STRING The OCTET STRING type denotes an arbitrary string of octets (eight-bit values). An OCTET STRING value can have any length, including zero. This type is a string type. The OCTET STRING type is used for salt values in the PBEParameter type . The OCTET STRING type is used for message digests, encrypted message digests, and encrypted content in . The OCTET STRING type is used for private keys and encrypted private keys in PKCS #8 . ASN.1 notation: where 'size', 'size1', and 'size2' are optional size constraints. In the OCTET STRING SIZE (size) form, the octet string must have 'size' octets. In the OCTET STRING SIZE (size1..size2) form, the octet string must have between 'size1' and 'size2' octets. In the OCTET STRING form, the octet string can have any size. Example: The PBEParameter type in has a component of type OCTET STRING: 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 OCTET STRING value. Example: The BER encoding of the OCTET STRING value 01 23 45 67 89 ab cd ef can be any of the following, among others, depending on the form of length octets and whether the encoding is primitive or constructed:

DER Encoding Primitive. The contents octets are as for a primitive BER encoding. Example: The DER encoding of the OCTET STRING value 01 23 45 67 89 ab cd ef is

PrintableString The PrintableString type denotes an arbitrary string of printable characters from the following character set: This type is a string type. The PrintableString type is used in PKCS #9 challenge-password and unstructured-address attributes, and in several 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 PrintableString 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:

DER Encoding Primitive. The contents octets are as for a primitive BER encoding. Example: The DER encoding of the PrintableString value "Test User 1" is

RELATIVE-OID The RELATIVE-OID type denotes a relative object identifier, a sequence of integer components that identifies an object relative to some object identifier that is established by context. A RELATIVE-OID value has at least one component. Components can have any nonnegative value. This type is a non-string type. Unlike the OBJECT IDENTIFIER type, a RELATIVE-OID value is not complete on its own. It is meaningful only with respect to a base object identifier known from the context in which the value appears. The special encoding of the first two components used for OBJECT IDENTIFIER (see ) does not apply. ASN.1 notation: The ASN.1 notation for values of the RELATIVE-OID type is where 'identifier1', ..., 'identifierN' are identifiers, and 'value1', ..., 'valueN' are optional integer values. As with OBJECT IDENTIFIER, the identifiers are intended primarily for documentation, but they must correspond to the integer value when both are present. Example: If the base object identifier established by context is that assigned to RSA Data Security, Inc., { 1 2 840 113549 }, then the following RELATIVE-OID value identifies { 1 2 840 113549 1 1 }: (In this example, which gives ASN.1 value notation, the relative object identifier values are decimal, not hexadecimal.)

BER Encoding Primitive. The contents octets encode 'value1', ..., 'valueN', where 'value1', ..., 'valueN' denote the integer values of the components in the relative object identifier. 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". As a consequence of encoding each component with as few digits as possible, the first octet of a component's encoding is never 0x80 (128 decimal). Unlike OBJECT IDENTIFIER, the first two components are not combined; every component is encoded independently. Example: The BER encoding of the RELATIVE-OID value { 32473 3 2 } encodes 32473 = 1 * 128^2 + 125 * 128 + 89 (decimal) as 81 fd 59, 3 as 03, and 2 as 02. This leads to the following BER encoding:

DER Encoding Primitive. The contents octets are as for a primitive BER encoding.

SEQUENCE The SEQUENCE type denotes an ordered collection of one or more types. The SEQUENCE type is used throughout by just about every standard that makes use of ASN.1. ASN.1 notation: 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 OPTIONAL qualifier indicates that the value of a component is optional and need not be present in the sequence. The DEFAULT 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 OPTIONAL or DEFAULT 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: Validity type is a SEQUENCE type with two components: Here the identifiers for the components are start and end, and the types of the components are both Time.

BER Encoding Constructed. The 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 OPTIONAL and DEFAULT qualifiers:

• if the value of a component with the OPTIONAL or DEFAULT 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 DEFAULT qualifier is the default value, then the encoding of that component may or may not be included in the contents octets

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

SEQUENCE OF The SEQUENCE OF type denotes an ordered collection of zero or more occurrences of a given type. The SEQUENCE OF type is used in distinguished names . ASN.1 notation: where 'Type' is a type, and where 'size', 'size1', and 'size2' are optional size constraints. In the SEQUENCE SIZE (size1..size2) OF form, the SEQUENCE must have between 'size1' and 'size2' items present. In the SEQUENCE SIZE (size) OF form, the SEQUENCE must have exactly 'size' items present. In the SEQUENCE OF form, the SEQUENCE can have any number of items, including zero. Example: The RDNSequence type consists of zero or more occurrences of the RelativeDistinguishedName type, most significant occurrence first: Example: The Extensions type in requires that at least one item be present in the SEQUENCE OF: To require exactly a given number of items, use a single size value instead of a range. For example, the following (illustrative, not taken from a published specification) type always contains exactly two integers: There are some widely used ASN.1 specifications that define an OPTIONAL SEQUENCE OF component without a size constraint. In this case, the sender can encode either an empty SEQUENCE, or it can elect to not encode the SEQUENCE. Absent some requirement established in the prose of the specification, it is preferable to not encode the empty SEQUENCE OF, as it minimizes the size of the message.

BER Encoding Constructed. The contents octets are the concatenation of the BER encodings of the values of the occurrences in the collection, in order of occurrence.

DER Encoding Constructed. The contents octets are the concatenation of the DER encodings of the values of the occurrences in the collection, in order of occurrence.

SET The SET type denotes an unordered collection of one or more types. The SET type is used in the ESSSecurityLabel type . ASN.1 notation: 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 OPTIONAL qualifier indicates that the value of a component is optional and need not be present in the set. The DEFAULT 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. Example. The SET type is used in the ESSSecurityLabel type .

BER Encoding Constructed. The 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 OPTIONAL and DEFAULT qualifiers:

• • if the value of a component with the OPTIONAL or DEFAULT 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 DEFAULT qualifier is the default value, then the encoding of that component may or may not be included in the contents octets

DER Encoding Constructed. The contents octets are the same as for the BER encoding, except that:

1. If the value of a component with the DEFAULT 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 (care: the CONSTRUCTED bit is not part of the tag value, see below). By ascending order, imagine every set element's encoding is padded with zeroes so that every encoding is the same length and then each padded encoding is treated as an INTEGER with the smallest encodings sorted to the start of the SET.

A simple pseudo-code version of the sort (in-place) would look like:

Pseudo-code for sorting SET components for DER

CONSTRUCTED is the constructed-encoding bit of the identifier octet (see ). Length() returns the length of an array, Min() returns the mathematical minimum of two values and DER() returns the DER encoding of the ASN1Object passed to it, and the ~ operator provides the one's complement of a value, as it does in languages like C, Java, and C#. Likewise for & - the bitwise AND. The comparison stops at the last octet the two encodings have in common. This is consistent with the padding described above because, for two definite-length DER encodings with the same tag, the length octets differ before the contents octets do, so one encoding can never be a strict prefix of the other. NOTE: As you can see from the LessThanOrEqual() function, SET elements in DER encodings are ordered first according to their tags (class and number), but the CONSTRUCTED bit is not part of the tag. Links to examples of different implementations of the DER SET sort can be found in . For SET OF (see below), this is unimportant. All elements have the same tag and DER requires them to either all be in constructed form or all in primitive form, according to that tag. The elements are effectively ordered according to their contents octets. For SET, the elements will have distinct tags, and each will be in constructed or primitive form accordingly. Failing to ignore the CONSTRUCTED bit could therefore lead to ordering inversions, so in general it is best to make sure it is not present in the encoding of the tag.

SET OF The SET OF type denotes an unordered collection of zero or more occurrences of a given type. The SET OF type is used for sets of attributes in PKCS #9 . The SET OF type is used for sets of message-digest algorithm identifiers, signer information, and recipient information in . ASN.1 notation: where 'Type' is a type, and where 'size', 'size1', and 'size2' are optional size constraints. In the SET SIZE (size1..size2) OF form, the SET must have between 'size1' and 'size2' items present. In the SET SIZE (size) OF form, the SET must have exactly 'size' items present. In the SET OF form, the SET can have any number of items, including zero. Example: The RelativeDistinguishedName type consists of one or more occurrences of the AttributeTypeAndValue type, where the order is unimportant: To require exactly a given number of items, use a single size value instead of a range. For example, the following (illustrative, not taken from a published specification) type always contains exactly two integers, in no particular order:

BER Encoding Constructed. The contents octets are the concatenation of the BER encodings of the values of the occurrences in the collection, in any order.

DER Encoding Constructed. The 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. There are some widely used ASN.1 specifications that define an OPTIONAL SET OF component without a size constraint. In this case, the sender can encode either an empty SET, or it can elect to not encode the SET. Absent some requirement established in the prose of the specification, it is preferable to not encode the empty SET OF, as it minimizes the size of the message.

T61String The T61String type denotes an arbitrary string of T.61 characters. T.61 is an eight-bit extension to the ASCII character set. Special "escape" sequences shift the character interpretation dynamically, so that subsequent character values are interpreted as, for example, Japanese; the initial interpretation is Latin. The character set includes non-printing control characters. The T61String type allows only the Latin and Japanese character interpretations, and implementors' agreements for directory names exclude control characters . A T61String value can have any length, including zero. This type is a string type. The T61String type is used in PKCS #9 unstructured-address and challenge-password attributes , and in several attributes documented in . Note: The use of T61String is generally discouraged, and the use of UTF8String is preferred. 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 T61String value "clés 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: The eight-bit character c2 is a T.61 prefix that adds an acute accent (') to the next character.

DER Encoding Primitive. The contents octets are as for a primitive BER encoding. Example: The DER encoding of the T61String value "clés publiques" is

UTCTime The UTCTime type denotes a "coordinated universal time" or Greenwich Mean Time (GMT) value. A UTCTime 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: where:

• YY is the least significant two digits of the year (00 to 99)

• 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 UTCTime type is used for signing times in PKCS #9 signing-time attribute and for certificate validity periods in Validity 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 UTCTime 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 UTCTime values, among others: These values have the following BER encodings, among others:

DER Encoding Primitive. The contents octets are as for a primitive BER encoding, except that the optional parts of the BER forms are fixed. The time is always in GMT, so the string always ends with Z, and the seconds are always present. The only DER form is therefore: Midnight is encoded as YYMMDD000000Z. Example: The DER encoding of the UTCTime value "910506234540Z" is

GeneralizedTime The GeneralizedTime type consists of a calendar date and time. A GeneralizedTime value includes the local time, which can be as precise as fractions of seconds but need not be. A GeneralizedTime value can include midnight at the start of a day, but it excludes midnight at the end of a day. A GeneralizedTime value uses one of the following three forms:

1. a local time of day;
2. a local time of day with the difference between local time and UTC; or
3. a UTC time of day.

Accuracy of the time takes one of the following three forms:

1. hours, minutes, and seconds, with fractions of a second to any number of decimal places;
2. hours and minutes, with fractions of a minute to any number of decimal places; or
3. hours, with fractions of an hour to any number of decimal places.

This type is a string type. It uses a subset of VisibleString. The VisibleString starts with a four-digit representation of the year, a two-digit representation of the month, and a two-digit representation of the day, without use of separators. The VisibleString continues with the time of day to an accuracy of one hour, one minute, one second, or fractions of a second, using either comma or full stop as the decimal sign. What follows the time of day depends on which of the three forms is used. For a local time of day, nothing follows it. For a UTC time of day, the VisibleString ends with the upper-case letter Z. For a local time of day with the difference between local time and UTC, the VisibleString ends with the signed difference (a plus or minus sign followed by hours and minutes), with the minutes component optionally omitted if the difference is an integral number of hours. All possible forms of GeneralizedTime cannot be enumerated, but it is worth noting that requires that dates in 2050 and later be encoded as GeneralizedTime using the following form, which is the UTCTime form with a four-digit year: The GeneralizedTime type is used for certificate validity periods in Validity type . ASN.1 notation:

BER Encoding Primitive or constructed. In a primitive encoding, the contents octets give the characters in the string, encoded in VisibleString. 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 GeneralizedTime values are usually very short, but the constructed encoding is permitted.) Example: Local time 6 minutes, 27.3 seconds after 9 pm on 6 November 2050. This value has the following BER encoding, among others:

DER Encoding Primitive. The contents octets are as for a primitive BER encoding, except that the optional parts of the BER forms are fixed so that each value has exactly one encoding. The rules are:

• the time is always expressed in UTC, so the string always ends with Z and the local time forms are not used;
• the seconds are always present, so the hours-only and hours-and-minutes accuracies are not used;
• if fractions of a second are present, the decimal sign is a full stop, and the fraction has no trailing zeros; if the fraction is zero, the full stop and fraction are omitted entirely; and
• midnight is encoded as YYYYMMDD000000Z.

Individual protocols may restrict the encoding further. For example, does not allow fractional seconds in certificates. Example: uses the GeneralizedTime value of "99991231235959Z" to indicate that a certificate has no well-defined expiration date. This value has the following DER encoding:

UTF8String The UTF8String type supports the encoding of character sets which covers most of the world's writing systems; see . This type is a string type. The UTF8String type is used with many naming attributes in . ASN.1 notation:

BER Encoding Primitive or constructed. In a primitive encoding, the contents octets give the characters in the UTF-8 string. In a constructed encoding, the contents octets give the concatenation of the BER encodings of consecutive substrings of the UTF-8 string. Example: The character sequence U+D55C U+AD6D U+C5B4 (Korean "hangugeo", meaning "the Korean language") is encoded in UTF-8, and then this value has the following BER encodings, among others:

DER Encoding Primitive. The contents octets are as for a primitive BER encoding. Example: The DER encoding of the UTF8String value U+D55C U+AD6D U+C5B4 is

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

Abstract notation This section gives the ASN.1 notation for the Name type . The Name type identifies an object in an X.500 directory. Name is a CHOICE type consisting of one alternative: RDNSequence. (Future revisions of X.500 may have other alternatives.) The RDNSequence type gives a path through an X.500 directory tree starting at the root. RDNSequence is a SEQUENCE OF type consisting of zero or more occurrences of RelativeDistinguishedName. The RelativeDistinguishedName type gives a unique name to an object relative to the object superior to it in the directory tree. RelativeDistinguishedName is a SET OF type consisting of one or more occurrences of AttributeTypeAndValue. The AttributeTypeAndValue type assigns a value to some attribute of a relative distinguished name, such as country name or common name. AttributeTypeAndValue is a SEQUENCE type consisting of two components, an AttributeType type and an AttributeValue type. The AttributeType type identifies an attribute by object identifier. The AttributeValue type gives an arbitrary attribute value. The actual type of the attribute value is determined by the attribute type.

DER encoding This section gives an example of a DER encoding of a value of type Name, working from the bottom up. The name is that of User 1. The name is represented by the following path: Each level corresponds to one RelativeDistinguishedName value, each of which happens for this name to consist of one AttributeTypeAndValue value. The AttributeType value is before the equals sign, and the AttributeValue value (a printable string for the given attribute types) is after the equals sign. The countryName, organizationName, and commonName are attribute types defined in as: Note: joint-iso-ccitt and joint-iso-itu-t are interchangeable for (2).

AttributeType The three AttributeType values are OBJECT IDENTIFIER values, so their DER encoding follows the primitive, definite-length method: The identifier octets follow the low-tag form, since the tag is 6 for OBJECT IDENTIFIER. Bits 8 and 7 have value "0," indicating universal class, and bit 6 has value "0," indicating that the encoding is primitive. The length octets follow the short form. The contents octets are the concatenation of three octet strings derived from subidentifiers: 40 * 2 + 5 = 85 = 55 (hexadecimal); 4; and 6, 10, or 3.

AttributeValue The three AttributeValue values are PrintableString values, so their encodings follow the primitive, definite-length method: The identifier octets follow the low-tag-number form, since the tag for PrintableString, 19 (decimal), is between 0 and 30. Bits 8 and 7 have value "0" since PrintableString is in the universal class. Bit 6 has value "0" since the encoding is primitive. The length octets follow the short form, and the contents octets are the ASCII representation of the attribute value.

AttributeTypeAndValue The three AttributeTypeAndValue values are SEQUENCE values, so their DER encodings follow the constructed, definite-length method: The identifier octets follow the low-tag-number form, since the tag for SEQUENCE, 16 (decimal), is between 0 and 30. Bits 8 and 7 have value "0" since SEQUENCE is in the universal class. Bit 6 has value "1" since the encoding is constructed. The length octets follow the short form, and the contents octets are the concatenation of the DER encodings of the attributeType and attributeValue components.

RelativeDistinguishedName The three RelativeDistinguishedName values are SET OF values, so their DER encodings follow the constructed, definite-length method: The identifier octets follow the low-tag-number form, since the tag for SET OF, 17 (decimal), is between 0 and 30. Bits 8 and 7 have value "0" since SET OF is in the universal class. Bit 6 has value "1" since the encoding is constructed. The length octets follow the short form, and the contents octets are the DER encodings of the respective AttributeTypeAndValue values, since there is only one value in each set.

RDNSequence The RDNSequence value is a SEQUENCE OF value, so its DER encoding follows the constructed, definite-length method: The identifier octets follow the low-tag-number form, since the tag for SEQUENCE OF, 16 (decimal), is between 0 and 30. Bits 8 and 7 have value "0" since SEQUENCE OF is in the universal class. Bit 6 has value "1" since the encoding is constructed. The length octets follow the short form, and the contents octets are the concatenation of the DER encodings of the three RelativeDistinguishedName values, in order of occurrence.

Name The Name value is a CHOICE value, so its DER encoding is the same as that of the RDNSequence value: If pretty-printed in strict order, this would provide an X.500 Name that looked like: Occasionally, just occasionally you will also come across a '+' syntax in X.500 Names so instead the name might look like: This case is interesting, the reason for this being that the '+' means the last two attribute value pairs end up in the same RDN, or more specifically the same SET as can be seen in the encoding below. While the above is a correct definite-length encoding of this X.500 name, it is not the correct DER encoding, which looks like: If pretty-printed directly, this would give: The difference between the two encodings being that the SET has been correctly sorted for DER encoding in the final encoding. There are a few morals to this particular tale. As you can imagine '+' in an X.500 name is best avoided as sometimes people forget about the sorting or insist on definite-length encoding to preserve order requiring DER encoding to be done every time for signature generation and verification. Ideally if you have to include a '+' (it really does happen) it is also better to write out the X.500 name in DER format at the start, so anyone else trying to verify a signature that might be associated with the use of the name will always get a correct result. Where it is not possible to write out the X.500 name in DER format, so anyone checking the subsequent encoding will be presented with a definite-length encoding instead, special care must be taken to calculate and evaluate any signatures or MACs based on the name using the DER encoding, rather than the definite-length encoding, otherwise recipients will not be able to verify the data. One final note, as Name is of type CHOICE, whenever it is tagged it will always encode as explicitly tagged, even if it's in a module that starts with a definitions block reading DEFINITIONS IMPLICIT TAGS ::=. This convention is followed as CHOICE encodings need to maintain the original encoding of the ASN.1 primitive, or structure, making up the CHOICE. Overwriting the tag by following the implicit tagging rule could change the meaning of the CHOICE item completely!

Useful Links The following table provides alternate implementations of the DER SET sort for a variety of languages. Example Implementations of DER SET Sorting.

Language	Project	Link
C	OpenSSL
C#	Bouncy Castle
Java	Bouncy Castle
Rust	Rust Crypto

IANA Considerations This document has no IANA actions.

Security Considerations Security considerations are discussed throughout this memo. Implementations that employ ASN.1 need to take care when parsing and decoding data to avoid buffer overflows, denial of service through resource exhaustion, and arbitrary code execution. These considerations are not unique to ASN.1; they need to be considered by all data parsers and decoders. In relation to resource exhaustion, while ASN.1 allows for arbitrary nesting of constructed objects and very large lengths of individual data objects, we recommend that limits for both these are enforced appropriate for the use-case the parser, or decoder, is used for. Such limits can provide a useful early warning of corrupted data while also (usually) providing a recoverable situation for the parser, or decoder, encountering the issue. In addition to issues with nesting, the need to sort sets for DER can also cause issues if a large set is presented in a situation where DER encoding is required, such as with a signature verification. In situations where ASN.1 encodings are possibly being accepted from unknown third parties, a more sophisticated algorithm, such as a stable Dual-Pivot Quicksort, should be utilized. Doing so may avoid worst-case situations resulting in high CPU and/or memory usage when producing or verifying the sorted, distinguished encoded value for a SET type. Implementers of ASN.1 parsers and decoders are encouraged to use fuzz testing to identify security vulnerabilities and other flaws.

References Normative References ITU-T ITU-T In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This memo represents a republication of PKCS #9 v2.0 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from that specification. This memo provides information for the Internet community. ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. This document supplements RFC 3279. It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified. [STANDARDS-TRACK] In the original Enhanced Security Services for S/MIME document (RFC 2634), a structure for cryptographically linking the certificate to be used in validation with the signature was introduced; this structure was hardwired to use SHA-1. This document allows for the structure to have algorithm agility and defines a new attribute for this purpose. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. [STANDARDS-TRACK] The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message authentication schemes, and ASN.1 syntax identifying the techniques. This document represents a republication of PKCS #5 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 2898. Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described. Verisign, Inc. This note gives a layman's introduction to a subset of the 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 RSA Data Security, Inc. Public Key Cryptography Standards (PKCS) family of standards. This document represents a republication of A Layman's Guide to a Subset of ASN.1, BER, and DER, originally authored and published by RSA Security USA LLC. This document is submitted with permission from, and on behalf of RSA Security USA LLC. By publishing this document, change control is transferred to the IETF and the Internet technical community in full conformance with the provisions of BCP 78 and BCP 79. NIST ITU-T ITU-T OpenSSL Project n.d. Bouncy Castle n.d. Bouncy Castle n.d. RustCrypto n.d.

Acknowledgments The authors thank Adrian Farrel, Alex Railean, Carl Wallace, Daniel Van Geest, Eliot Lear, Joe Mandel, Lijun Liao, Mike StJohns, Sean Turner, and Zaid AlBanna for their reviews and insightful feedback which meaningfully improved this document.