octet string что это
Octet string что это
Для октетов длины примитивного метода имеется два формата: короткий (один октет для длин 0-127) и длинный (2-127 октетов). Для короткой формы 8-ой бит октета всегда равен нулю. Для длинной формы восьмой бит первого октета всегда равен 1, биты 1-7 содержат код числа дополнительных октетов длины. Старшая цифра записывается первой.
Конструктивный метод с заданной длиной
Этот метод используется для простых строчных и структурированных типов, типов, производных от простых строчных типов, и некоторых других. Здесь октеты идентификатора и октеты длины имеют формат, идентичный используемому примитивным методом, за исключением того, что бит 6 первого октета идентификатора равен 1.
Конструктивный метод кодирования с незаданной длиной
Метод используется для простых строчных типов, структурированных типов и типов, полученных из простых и структурированных типов с помощью неявной пометки. Октеты идентификатора идентичны предшествующему. Октет длины содержит код 80. Два октета конца содержательной части содержат 00 00.
Нотация типов, помеченных неявно, имеет вид:
[[class] number] IMPLICIT Type
class = UNIVERSAL | APPLICATION | PRIVITE
Если имя класса отсутствует, тогда метка является контекстно-ориентированной. Такие метки могут появляться только в структурных компонентах или в типе CHOICE. Например:
PrivateKeyInfo ::= SEQUENCE <
version Version,
privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
privateKey PrivateKey,
attributes [0] IMPLICIT Attributes OPTIONAL >
Здесь исходным (порождающим) типом является Attributes, класс отсутствует (т.е. контекстно-ориентированный), а числовая метка равна нулю. Кодирование компоненты attributes величины PrivateKeyInfo осуществляется следующим образом.
Октеты идентификатора равны 80, если значение порождающей величины Attributes имеет конструктивное BER-кодирование. Октеты длины и содержимого строго соответствуют октетам порождающей величины Attributes.
Непосредственная (явная) пометка используется для опционных компонент SEQUENCE c порождающим типом ANY и для компонент version типа Certificate (X.509 и RFC-1114). Нотация типов, помеченных явно, имеет формат.
class = UNIVERSAL | APPLICATION | PRIVATE
ContentInfo ::= SEQUENCE <
ContebtType ContentType,
Content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL >
Тип ContentInfo имеет опционную компоненту content с явной контекстно-ориентированной меткой. Здесь порождающим типом является ANY DEFINED BY contentType, класс отсутствует, а числовая метка в пределах класса равна 0.
Другим примером может являться тип Certificate [X.509], имеющий компоненту с явной контекстно-ориентированной меткой (ключевое слово EXPLICIT опущено).
Certificate ::= .
Version [0] Version DEFAULT v1988,
.
BER-кодирование величин, помеченных явно, является всегда конструктивным. Октеты содержимого идентичны соответствующим октетам порождающей величины. Например, BER-кодирование компоненты content величины ContentInfo имеет следующий вид.
Октеты идентификатора равны нулю, Октеты длины представляют длину BER-кодирования порождающей величины ANY DEFINED BY contentType.
Тип ANY обозначает произвольную величину произвольного типа, где произвольный тип возможно определен при регистрации идентификатора объекта или является целочисленным индексом. Нотация типа ANY имеет формат:
ANY [DEINED BY identifier ]
AlgorithmIdentifier ::= SEQUENCE <
algorithm OBJECT IDENTIFIER,
parameter ANY DEFINED BY algorithm OPTIONAL >
Здесь истинный тип компоненты parameter зависит от величины компоненты algorithm. Истинный тип будет определен при регистрации объекта величины идентификатора длякомпоненты algorithm.
Тип BIT STRING обозначает произвольные битовые последовательности произвольной длины (включая ноль). Тип BIT STRING используется для цифровых сигнатур типа ExtendedCertificate или Certificate [X.509]. Нотация BIT STRING имеет формат.
Например, тип SubjectPublicKeyInfo имеет компоненту типа BIT STRING:
SubjectPublicKeyInfo ::= SEQUENCE <
Algorithm AlgorithmIdentifier,
PublicKey BIT STRING >
BER-кодирование величины BIT STRING может быть примитивным или конструктивным. При примитивном кодировании первый октет содержимого несет в себе длину битовой строки в октетах. В последующих октетах записывается сама битовая последовательность. Процедура кодирования может включать в себя дополнение битовой строки до целого числа октетов нулями (если это необходимо). Строка делится на октеты.
При конструктивном кодировании октеты содержимого представляют собой соединение последовательности субстрок, только последняя из которых содержит код длины, выраженный в октетах. Например, при BER-кодировании значения BIT STRING «0111 1101 1001 1111 11» может быть представлена в одном из следующих видов, в зависимости от выбора схемы дополнения до целого числа октетов, от формата октетов длины и от метода кодирования примитивный/конструктивный).
Дополнение кодом «100000»
03 81 04 06 7D 9F C0
Длинная форма представления октетов длины
23 09
03 03 00 7D 9F
03 02 06 C0
Конструктивное кодирование «01111101 1001 1111″ +»11»
Этот тип служит для объединения одной или более альтернатив. Нотация типа CHOICE имеет формат.
BER-кодирование величины IA5String может быть примитивным или структурированным. При примитивном кодировании октеты содержимого представляют собой символы IA5 в ASCII-кодов. При конструктивном кодировании октеты содержимого представляют собой соединение ряда IA5-субстрок. Рассмотрим примеры представления значения IA5-строки «test1@rsa.com».
12 0D 74 65 73 74 31 40 72 73 61 2E 63 6F 6D
DER-кодирование
12 05 74 65 73 74 31
12 01 40
12 07 72 73 61 2E 63 6F 6D
кодирование: «test1»
+ «@» +
«rsa.com»
DER-кодирование является всегда примитивным, октеты содержимого идентичны случаю BER-кодирования.
Тип INTEGER представляет любые целые числа (положительные, отрицательные или 0). Тип INTEGER используется для номеров версий, криптографических параметров (показателей, модулей) и типов RSAPublicKey, RSAPrivatKey, DHParameter PBEParameter. Нотация типа INTEGER имеет формат:
Идентификатору v1988 поставлено в соответствие значение 0. Тип Certificate RFC-1114 использует идентификатор v1988для присвоения значения по умолчанию компоненту version:
Certificate
version Version DEFAULT v1988,
.
BER-кодирование значения INTEGER является всегда примитивным. Октеты содержимого представляют значение целого по модулю 256 в форме дополнения по модулю 2. Старшая цифра является первой. Значение нуль кодируется одним октетом 00. Примеры BER-кодирования (совпадающего в данном случае с DER-кодированием) представлены в таблице 4.4.13.2.3.
Таблица 4.4.13.2.3. Примеры BER-кодирования
Инфраструктура Открытого Ключа (часть 1)
ASN.1: спецификация базовой нотации
Введение
[] – квадратные скобки указывают на то, что терм является необязательным;
<> – фигурные скобки группируют родственные термы;
| – вертикальная черта выделяет альтернативные значения;
= – знак равенства описывает терм как подтерм.
Определены следующие простые типы:
INTEGER – любое целое число;
BIT STRING – произвольная строка бит;
OCTET STRING – произвольная последовательность октетов ;
OBJECT IDENTIFIER – последовательность компонентов, однозначно идентифицирующих объект;
PrintableString – последовательность печатных символов;
IA5String – произвольная строка символов IA5 (ASCII);
UTCTime – универсальное время (по Гринвичу; GMT).
Для строчных типов может быть введено ограничение на максимальный размер.
В ASN.1 определено четыре структурных типа:
SEQUENCE – упорядоченный набор из одного или более типов, некоторые из которых могут быть объявлены как необязательные.
SEQUENCE OF – упорядоченный набор из нуля или более значений данного типа.
SET – неупорядоченный набор из одного или более типов, некоторые из которых могут быть объявлены как необязательные.
SET OF – неупорядоченный набор из нуля или более значений данного типа.
Структурные типы могут иметь необязательные компоненты, в том числе со значениями по умолчанию.
Тегированный тип является новым типом, который изоморфен старому, но имеет отличный от него тег.
DefinedValue должно быть типом целого и иметь неотрицательное значение.
Octet String: What is it?
I am starting to look into some network programming concepts for a project I am about to take over, and I keep running into this concept of an octet string. Can anyone out there provide some feedback into what this is, and how it relates to network programming?
9 Answers 9
Octet string = sequence of bytes.
«Octet» is standardese for «8-bit byte». It’s supposed to be a less ambiguous term compared to just «byte», because some platforms have bytes of different width (not sure if there are any are still remaining, but they used to exist).
Suppose a representation of binary 00000000 to 11111111 as 0x00 to 0xFF in hexadecimal. Then the octetString is simply 00 to FF.
Binary files can be encoded into octetstrings and sent from a webbclient to a server in the form of an ASCII-string containing the 0-F alphabet, like a8b9457fc6e3e410589f or it’s capitals. There are javascript using BASE-64 encoding used to store pictures in Strings. The larger alphabet, in this case(I think ) A-Z,a-z,0-9, the less data needs to be transferred. every octet has 256 different possible values, and are to be stored in an alphabet of 62 letters, clearly one needs to use more than one letter / octet. Possibly the theoretical number is proportional to log62(256).
The conclusion is that improved readability takes more space than it’s binary version, in the octetstream example it’s twice as long since each ascii char is eight bits and 2 chars (16 bits) represent an octet which is eight bits. Quite inefficient.
A Layman’s Guide to a Subset of ASN.1, BER, and DER
Supersedes June 3, 1991 version, which was also published as NIST/OSI Implementors’ Workshop document SEC-SIG-91-17. PKCS documents are available by electronic mail to
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
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:
| 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
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.
Type Tag number
(decimal)Tag number
(hexadecimal)INTEGER 2 02 BIT STRING 3 03 OCTET STRING 4 04 NULL 5 05 OBJECT IDENTIFIER 6 06 SEQUENCE and SEQUENCE OF 16 10 SET and SET OF 17 11 PrintableString 19 13 T61String 20 14 IA5String 22 16 UTCTime 23 17
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:
2.1 Simple types
BIT STRING, an arbitrary string of bits (ones and zeroes).
IA5String, an arbitrary string of IA5 (ASCII) characters.
INTEGER, an arbitrary integer.
OBJECT IDENTIFIER, an object identifier, which is a sequence of integer components that identify an object such as an algorithm or attribute type.
OCTET STRING, an arbitrary string of octets (eight-bit values).
PrintableString, an arbitrary string of printable characters.
T61String, an arbitrary string of T.61 (eight-bit) characters.
UTCTime, a «coordinated universal time» or Greenwich Mean Time (GMT) value.
Simple types fall into two categories: string types and non- string types. BIT STRING, IA5String, OCTET STRING, PrintableString, T61String, and UTCTime 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
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.
2.3 Implicitly and explicitly tagged types
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 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] EXPLICIT (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 CHOICE or ANY).
2.4 Other types
3. Basic Encoding Rules
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
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.
| Class | Bit 8 | Bit 7 |
| universal | 0 | 0 |
| application | 0 | 1 |
| context-specific | 1 | 0 |
| private | 1 | 1 |
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.»
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
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:
3.3 Constructed, indefinite-length method
Identifier octets. As described in Section 3.2.
Length octets. One octet, 80.
Contents octets. As described in Section 3.2.
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.
4. Distinguished Encoding Rules
DER adds the following restrictions to the rules given in Section 3:
Other restrictions are defined for particular types (such as BIT STRING, SEQUENCE, SET, and SET OF), and can be found in Section 5.
5. Notation and encodings for some types
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 OBJECT IDENTIFIER, value notation is given as well.
5.1 Implicitly tagged types
Implicit tagging is used for optional SEQUENCE components with underlying type other than ANY throughout PKCS, and for the extendedCertificate alternative of PKCS #7’s ExtendedCertificateOrCertificate type.
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 Section 2.3.) 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’s 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. 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:
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 is used for optional SEQUENCE components with underlying type ANY throughout PKCS, and for the version component of X.509’s Certificate type.
class = UNIVERSAL | APPLICATION | PRIVATE
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 Section 2.3.) For definitions stated outside a module, the explicit inclusion of the keyword EXPLICIT is preferable to prevent ambiguity.
Example 1: PKCS #7’s 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: X.509’s Certificate type has a version component with an explicit, context-specific tag, where the EXPLICIT keyword is omitted:
The tag is explicit because the default tagging method for the ASN.1 «module» in X.509 that defines the Certificate 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 ContentInfo value is as follows:
DER encoding. Constructed. Contents octets are the DER encoding of the underlying value.
5.3 ANY
The ANY type is used for content of a particular content type in PKCS #7’s ContentInfo type, for parameters of a particular algorithm in X.509’s AlgorithmIdentifier type, and for attribute values in X.501’s Attribute and AttributeValueAssertion types. The Attribute type is used by PKCS #6, #7, #8, #9 and #10, and the AttributeValueAssertion type is used in X.501 distinguished names.
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: X.509’s 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.
5.4 BIT STRING
The BIT STRING type is used for digital signatures on extended certificates in PKCS #6’s ExtendedCertificate type, for digital signatures on certificates in X.509’s Certificate type, and for public keys in certificates in X.509’s SubjectPublicKeyInfo type.
Example: X.509’s 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 second and following contents octets give the value of the bit string, converted to an octet string. The conversion process is as follows:
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 |
| padded with «100000» |
| long form of length octets |
| constructed 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 BIT STRING value «011011100101110111» is
5.5 CHOICE
The CHOICE type is used to represent the union of an extended certificate and an X.509 certificate in PKCS #7’s ExtendedCertificateOrCertificate type.
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 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.
5.6 IA5String
The IA5String type is used in PKCS #9’s electronic-mail address, unstructured-name, and unstructured-address attributes.
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@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:
| DER encoding |
| long form of length octets |
| constructed 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
5.7 INTEGER
The INTEGER type is used for version numbers throughout PKCS, cryptographic values such as modulus, exponent, and primes in PKCS #1’s RSAPublicKey and RSAPrivateKey types and PKCS #3’s DHParameter type, a message-digest iteration count in PKCS #5’s PBEParameter type, and version numbers and serial numbers in X.509’s Certificate type.
Example: X.509’s Version type is an INTEGER type with identified values:
The identifier v1988 is associated with the value 0. X.509’s Certificate type uses the identifier v1988 to give a default value of 0 for the version component:
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 00 octet.
Some example BER encodings (which also happen to be DER encodings) are given in Table 3.
Integer
valueBER 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
Table 3. Example BER encodings of INTEGER values.
DER encoding. Primitive. Contents octets are as for a primitive BER encoding.
5.8 NULL
The NULL type is used for algorithm parameters in several places in PKCS.
BER encoding. Primitive. 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. Contents octets are empty; the DER encoding of a NULL value is always 05 00.
5.9 OBJECT IDENTIFIER
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 PKCS #7’s ContentInfo type, to identify algorithms in X.509’s AlgorithmIdentifier type, and to identify attributes in X.501’s Attribute and AttributeValueAssertion types. The Attribute type is used by PKCS #6, #7, #8, #9, and #10, and the AttributeValueAssertion type is used in X.501 distinguished names. OBJECT IDENTIFIER values are defined throughout PKCS.
The ASN.1 notation for values of the OBJECT IDENTIFIER type is
componenti = identifieri | identifieri (valuei) | valuei
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.
| Object identifier value | Meaning | ||||||||||
| ISO member bodies | |||||||||||
| US (ANSI) | |||||||||||
| RSA Data Security, Inc. | |||||||||||
| RSA Data Security, Inc. PKCS | |||||||||||
| DER encoding |
| long form of length octets |
| constructed encoding: «Test » + «User 1» |
DER encoding. Primitive. Contents octets are as for a primitive BER encoding.
Example: The DER encoding of the PrintableString value «Test User 1» is
5.12 SEQUENCE
The SEQUENCE type is used throughout PKCS and related standards.
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: X.509’s 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 UTCTime.
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 OPTIONAL and DEFAULT qualifiers:
DER encoding. Constructed. 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.
5.13 SEQUENCE OF
The SEQUENCE OF type is used in X.501 distinguished names.
where Type is a type.
Example: X.501’s RDNSequence type consists of zero or more occurences of the RelativeDistinguishedName type, most significant occurrence first:
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 SET type is not used in PKCS.
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.
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 OPTIONAL and DEFAULT qualifiers:
DER encoding. Constructed. Contents octets are the same as for the BER encoding, except that:
5.15 SET OF
The SET OF 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.
where Type is a type.
Example: X.501’s RelativeDistinguishedName type consists of zero or more occurrences of the AttributeValueAssertion type, where the order is unimportant:
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 T61String type is used in PKCS #9’s unstructured-address and challenge-password attributes, and in several X.521 attributes.
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’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:
| DER encoding |
| long form of length octets |
| constructed 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 T61String value «cl’es publiques» is
5.17 UTCTime
YYMMDDhhmmZ
YYMMDDhhmm+hh’mm’
YYMMDDhhmm-hh’mm’
YYMMDDhhmmssZ
YYMMDDhhmmss+hh’mm’
YYMMDDhhmmss-hh’mm’
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)
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’s signing-time attribute and for certificate validity periods in X.509’s Validity type.
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. Contents octets are as for a primitive BER encoding.
6. An example
6.1 Abstract notation
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 occurences of RelativeDistinguishedName.
The RelativeDistinguishedName type gives a unique name to an object relative to the object superior to it in the directory tree. RelativeDistinguishedName (root)
|
countryName = "US"
|
organizationName = "Example Organization"
|
commonName = "Test User 1"
Each level corresponds to one RelativeDistinguishedName value, each of which happens for this name to consist of one AttributeValueAssertion 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 commonUnitName are attribute types defined in X.520 as:
6.2.1 AttributeType
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 (in decimal): 40 * 2 + 5 = 85 = 5516; 4; and 6, 10, or 3.
6.2.2 AttributeValue
| "US" |
| "Example Organization" |
| "Test User 1" |
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.
6.2.3 AttributeValueAssertion
| countryName = "US" |
| organizationName = "Example Organization" |
| commonName = "Test User 1" |
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.
6.2.4 RelativeDistinguishedName
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 lengths octets follow the short form, and the contents octets are the DER encodings of the respective AttributeValueAssertion values, since there is only one value in each set.
6.2.5 RDNSequence
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 lengths 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.
6.2.6 Name
attributeType = countryName
attributeValue = "US"
attributeType = commonName
attributeValue = "Test User 1"
References
PKCS #3 RSA Laboratories. PKCS #3: Diffie-Hellman Key- Agreement Standard. Version 1.4, November 1993.
PKCS #5 RSA Laboratories. PKCS #5: Password-Based Encryption Standard. Version 1.5, November 1993.
PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard. Version 1.5, November 1993.
PKCS #7 RSA Laboratories. PKCS #7: Cryptographic Message Syntax Standard. Version 1.5, November 1993.
PKCS #8 RSA Laboratories. PKCS #8: Private-Key Information Syntax Standard. Version 1.2, November 1993.
PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute Types. Version 1.1, November 1993.
PKCS #10 RSA Laboratories. PKCS #10: Certification Request Syntax Standard. Version 1.0, November 1993.
X.200 CCITT. Recommendation X.200: Reference Model of Open Systems Interconnection for CCITT Applications. 1984.
X.208 CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
X.209 CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
X.500 CCITT. Recommendation X.500: The Directory--Overview of Concepts, Models and Services. 1988.
X.501 CCITT. Recommendation X.501: The Directory-- Models. 1988.
X.509 CCITT. Recommendation X.509: The Directory-- Authentication Framework. 1988.
X.520 CCITT. Recommendation X.520: The Directory-- Selected Attribute Types. 1988.
[Kal93] Burton S. Kaliski Jr. Some Examples of the PKCS Standards. RSA Laboratories, November 1993.
[NIST92] NIST. Special Publication 500-202: Stable Implementation Agreements for Open Systems Interconnection Protocols. Part 11 (Directory Services Protocols). December 1992.
Revision history
The June 3, 1991 version is part of the initial public release of PKCS. It was published as NIST/OSI Implementors' Workshop document SEC-SIG-91-17.
November 1, 1993 version
The November 1, 1993 version incorporates several editorial changes, including the addition of a revision history. It is updated to be consistent with the following versions of the PKCS documents:
PKCS #1: RSA Encryption Standard. Version 1.5, November 1993.
PKCS #3: Diffie-Hellman Key-Agreement Standard. Version 1.4, November 1993.
PKCS #5: Password-Based Encryption Standard. Version 1.5, November 1993.
PKCS #6: Extended-Certificate Syntax Standard. Version 1.5, November 1993.
PKCS #7: Cryptographic Message Syntax Standard. Version 1.5, November 1993.
PKCS #8: Private-Key Information Syntax Standard. Version 1.2, November 1993.
PKCS #9: Selected Attribute Types. Version 1.1, November 1993.
PKCS #10: Certification Request Syntax Standard. Version 1.0, November 1993.
The following substantive changes were made:
Section 5: Description of T61String type is added.
Section 6: Names are changed, consistent with other PKCS examples.