RFC 4506 XDR: External Data Representation Standard

Network Working Group                                 M. Eisler, Ed.
Request for Comments: 4506                   Network Appliance, Inc.
STD: 67                                                     May 2006
Obsoletes: 1832
Category: Standards Track

XDR – стандарт внешнего представления данных

XDR: External Data Representation Standard

PDF

Статус документа

Этот документ содержит проект стандартного протокола для сообщества Internet и служит запросом для обсуждения в целях развития протокола. Информацию о текущем состоянии стандартизации протокола можно найти в документе Internet Official Protocol Standards (STD 1). Документ может распространяться свободно.

Авторские права

Copyright (C) The Internet Society (2006).

Тезисы

В этом описан стандартный протокол XDR1 в его современном состоянии. Документ служит заменой RFC 1832.

Оглавление

Удалено из версии HTML.

1. Введение

XDR является стандартом для описания и представления данных. Он полезен при обмене данными между компьютерами с разной архитектурой и применяется при взаимодействии таких систем, как SUN WORKSTATION, VAX, IBM-PC, Cray. XDR работает на уровне представления ISO и является аналогом X.409, ISO ASN2. Основное различие между ними заключается в том, что XDR использует неявную типизацию, а X.409 — явную.

XDR использует язык описания формата данных. Этот язык служит лишь для этой цели и не может применяться для программирования. Этот язык обеспечивает компактное описание сложных форматов данных. Графическое представление форматов (неформальный язык) с ростом сложности формата становится непонятным. Язык XDR похож на язык программирования C [KERN], как Courier [COUR] похож на Mesa. Протоколы типа ONC RPC3 и NFS4 используются в XDR для описания формата данных.

Стандарт XDR использует допущение о переносимости байтов (или октетов), которые определяются, как 8 битов данных. Конкретное устройство кодирует байты в различных средах так, чтобы другие устройства могли их декодировать без потери информации. Например, стандарт Ethernet использует формат представления little-endian [COHE], когда младший бит указывается первым.

2. Отличия от RFC 1832

Этот документ не вносит технических изменений в RFC 1832 и публикуется с целью включения вопросов согласования с IANA, дополнительных вопросов безопасности и разделения нормативных и дополнительных ссылок.

3. Размер базового блока

Для представления всех объектов требуется блок из 4 байтов (или 32 битов) данных. Байты нумеруются от 0 до n-1. Байты считываются или записываются в некий байтовый поток так, что байт m всегда предшествует байту m+1. Если для хранения данных нужно n байтов и n не кратно 4, после n байтов данных будет размещено (r) (от 1 до 3 байтов5) с нулевыми значениями для того, чтобы общее число байтов было кратно 4.

В документе приводятся простые графические схемы для пояснения и сравнения. В большинстве иллюстраций каждый прямоугольник обозначает 1 байт. Скобки между прямоугольниками-байтами указывают на возможность присутствия (при необходимости) других байтов.

        +--------+--------+...+--------+--------+...+--------+
        | байт 0 | байт 1 |...|байт n-1|    0   |...|    0   |   BLOCK
        +--------+--------+...+--------+--------+...+--------+
        |<-----------n байтов--------->|<------r байтов----->|
        |<------------n+r (где (n+r) mod 4 = 0)>------------>|

4. Типы данных XDR

В последующих параграфах описываются типы данных, определенные в стандарте XDR, приведено их формальное определение и графическое представление.

Для каждого типа данных в языке показана общая декларация парадигмы. Отметим, что угловые скобки (< и >) означают последовательность данных переменного размера, а квадратные скобки ([ и ]) указывают последовательность данных фиксированного размера. Буквы n, m и r обозначают целые числа (integer). Полная спецификация языка и более формальные определения терминов (таких, как «идентификатор» и «декларация») приведены в разделе 6. Спецификация языка XDR.

Для некоторых типов данных приведены более конкретные примеры. Расширенные примеры описания данных даны в разделе 7. Пример описания данных XDR.

4.1. Integer — целое число

Целое число со знаком в XDR представляет собой 32 бита данных, с помощью которых можно представить значения в диапазоне [-2147483648, 2147483647]. Целое число представляется в форме дополнения до двух. Старший байт имеет номер 0, младший — 3. Представление целых чисел показано ниже:

         int identifier;

           (MSB)                   (LSB)
         +-------+-------+-------+-------+
         |байт 0 |байт 1 |байт 2 |байт 3 |                      INTEGER
         +-------+-------+-------+-------+
         <------------32 бита------------>

4.2. Unsigned Integer — целое число без знака

Целое число без знака в XDR представляет собой 32 бита, с помощью которых можно представить значения из диапазона [0, 4294967295]. Старший байт числа имеет номер 0, младший — 3. Представление показано ниже.

            unsigned int identifier;
              (MSB)                   (LSB)
            +-------+-------+-------+-------+
            |байт 0 |байт 1 |байт 2 |байт 3 |           UNSIGNED INTEGER
            +-------+-------+-------+-------+
            <------------32 бита------------>

4.3. Enumeration — перечисление

Перечисляемые элементы используют такое же представление, как целые числа со знаком. Перечисляемые элементы служат для описания подмножеств целых чисел. Перечисляемые данные декларируются следующим образом:

enum { name-identifier = constant, ... } identifier;

Например, три цвета red, yellow, blue можно описать, как перечисляемый тип:

enum { RED = 2, YELLOW = 3, BLUE = 5 } colors;

Будет ошибкой представление в качестве перечисляемого любого целого числа, не указанного при объявлении типа.

4.4. Boolean — логическое значение

Логические значения достаточно важны и часто используются, поэтому в стандарте для них выделен свой тип. Логические значения декларируются следующим образом:

bool identifier;

Это эквивалентно:

enum { FALSE = 0, TRUE = 1 } identifier;

4.5. Hyper Integer и Unsigned Hyper Integer

Стандарт также определяет 64-битовые (8 батов) целые числа, называемые hyper integer и unsigned hyper integer. Эти форматы являются простым расширением описанных выше форматов integer и unsigned integer. Числа представляются в форме дополнения до двух. Старший и младший байты имеют номера 0 и 7, соответственно.

   hyper identifier; unsigned hyper identifier;

        (MSB)                                                   (LSB)
      +-------+-------+-------+-------+-------+-------+-------+-------+
      |байт 0 |байт 1 |байт 2 |байт 3 |байт 4 |байт 5 |байт 6 |байт 7 |
      +-------+-------+-------+-------+-------+-------+-------+-------+
      <----------------------------64 бита---------------------------->
                                                 HYPER INTEGER
                                                 UNSIGNED HYPER INTEGER

4.6. Floating-Point — число с плавающей запятой

Стандарт определяет тип данных с плавающей запятой — float (32 бита или 4 байта). Для этого типа используется представление IEEE для нормализованных чисел одинарной точности с плавающей запятой [IEEE]. Приведенные ниже три поля определяют число с плавающей запятой.

S — знак (0 для положительных чисел, 1 для отрицательных). 1 бит.

E — показатель степени (основание 2). 8 битов. Степени 0 соответствует значение 127 (Bias).

F — дробная часть мантиссы (основание 2). 23 бита.

Следовательно, число с плавающей запятой можно выразить формулой:

(-1)S * 2(E-Bias) * 1,F

Числа этого типа декларируются следующим образом:

         float identifier;

         +-------+-------+-------+-------+
         |байт 0 |байт 1 |байт 2 |байт 3 |              SINGLE-PRECISION
         S|   E   |           F          |         FLOATING-POINT NUMBER
         +-------+-------+-------+-------+
         1|<- 8 ->|<-------23 бита------>|
         <------------32 бита------------>

Как старший и младший байты целого числа имеют номера 0 и 3, старший и младший биты числа одинарной точности с плавающей запятой имеют номера 0 и 31. Первый (старший) бит полей S, E и F имеет смещение 0, 1 и 9, соответственно. Отметим, что эти смещения указывают математические позиции битов, а не их реальное расположение, которое зависит от среды.

Представление 0 со знаком, бесконечности со знаком (переполнение) и денормализованных чисел (опустошение6) описаны в стандарте [IEEE]. В соответствии со спецификацией IEEE, значение NaN7 зависит от системы и не должно интерпретироваться в XDR, как нечто, отличное от NaN.

4.7. Double-Precision Floating-Point (двойная точность)

Стандарт определяет представления чисел с плавающей запятой двойной точности — double (64 бита или 8 байтов). Представление использует стандарт IEEE для нормализованных чисел с плавающей запятой двойной точности [IEEE]. Для представления чисел используется три поля:

S — знак (0 для положительных чисел, 1 для отрицательных). 1 бит.

E — показатель степени (основание 2). 11 битов. Степени 0 соответствует значение 1023 (Bias).

F — дробная часть мантиссы (основание 2). 52 бита.

Следовательно, число с плавающей запятой можно выразить формулой:

(-1)S * 2(E-Bias) * 1,F

Числа этого типа декларируются следующим образом:

         double identifier;

         +------+------+------+------+------+------+------+------+
         |байт 0|байт 1|байт 2|байт 3|байт 4|байт 5|байт 6|байт 7|
         S|    E   |                    F                        |
         +------+------+------+------+------+------+------+------+
         1|<--11-->|<-----------------52 бита------------------->|
         <-----------------------64 бита------------------------->
                                        DOUBLE-PRECISION FLOATING-POINT

Как старший и младший байты целого числа имеют номера 0 и 3, старший и младший биты числа двойной точности с плавающей запятой имеют номера 0 и 63. Первый (старший) бит полей S, E и F имеет смещение 0, 1 и 12, соответственно. Отметим, что эти смещения указывают математические позиции битов, а не их реальное расположение, которое зависит от среды.

Представление 0 со знаком, бесконечности со знаком (переполнение) и денормализованных чисел (опустошение8) описаны в стандарте [IEEE]. В соответствии со спецификацией IEEE, значение NaN9 зависит от системы и не должно интерпретироваться в XDR, как нечто, отличное от NaN.

4.8. Quadruple-Precision Floating-Point (4-кратная точность)

Стандарт определяет представления чисел с плавающей запятой 4-кратной точности — quadruple (128 битов или 16 байтов). Представление чисел аналогично представлению чисел с плавающей запятой одинарной или двойной точности с использованием формата IEEE. Для представления чисел используется три поля:

S — знак (0 для положительных чисел, 1 для отрицательных). 1 бит.

E — показатель степени (основание 2). 15 битов. Степени 0 соответствует значение 16383 (Bias).

F — дробная часть мантиссы (основание 2). 112 битов.

Следовательно, число с плавающей запятой можно выразить формулой:

(-1)S * 2(E-Bias) * 1,F

Числа этого типа декларируются следующим образом:

         quadruple identifier;

         +------+------+------+------+------+------+-...--+------+
         |байт 0|байт 1|байт 2|байт 3|байт 4|байт 5| ...  |байт15|
         S|    E       |                  F                      |
         +------+------+------+------+------+------+-...--+------+
         1|<----15---->|<-------------112 битов----------------->|
         <-----------------------128 битов----------------------->
                                      QUADRUPLE-PRECISION FLOATING-POINT

Как старший и младший байты целого числа имеют номера 0 и 3, старший и младший биты числа 4-кратной точности с плавающей запятой имеют номера 0 и 127. Первый (старший) бит полей S, E и F имеет смещение 0, 1 и 16, соответственно. Отметим, что эти смещения указывают математические позиции битов, а не их реальное расположение, которое зависит от среды.

Представление 0 со знаком, бесконечности со знаком (переполнение) и денормализованных чисел аналогичны числам с плавающий запятой одинарной и двойной точности [SPAR], [HPRE]. В соответствии со спецификацией IEEE, значение NaN для чисел 4-кратной точности зависит от системы и не должно интерпретироваться в XDR, как нечто, отличное от NaN.

4.9. Неинтерпретируемые данные фиксированного размера

Иногда между машинами требуются передавать не интерпретируемые данные фиксированного размера. Такие «непрозрачные» (opaque) данные декларируются следующим образом:

opaque identifier[n];

где постоянная n задает (фиксированное) число байтов, которые должны содержаться в непрозрачных данных. Если n не кратно 4, после n следует r (от 110 до 3) байтов с нулевыми значениями, служащих для выравнивания размера до значения, кратного 4.

          0        1     ...
      +--------+--------+...+--------+--------+...+--------+
      | байт 0 | байт 1 |...|байт n-1|    0   |...|    0   |
      +--------+--------+...+--------+--------+...+--------+
      |<-----------n байтов--------->|<------r байтов----->|
      |<------------n+r (где (n+r) mod 4 = 0)------------->|
                                                   FIXED-LENGTH OPAQUE

4.10. Неинтерпретируемые данные переменного размера

Стандарт также поддерживает непрозрачные данные переменного (заданного) размера, определяемые, как последовательность из n (нумерация от 0 до n-1) произвольных байтов. Последовательность начинается с беззнакового целого числа n (см. выше), за которым следует n байтов данных.

Байт m в последовательности всегда предшествует байту m+1, а байт 0 всегда следует за полем размера (счетчик). Если значение n не кратно 4, к последовательности добавляется r (от 111 до 3) байтов со значением 0 для выравнивания размера по границе 4-байтового слова. Непрозрачные данные переменного размера декларируются следующим образом:

opaque identifier<m>;

или

opaque identifier<>;

Постоянная m обозначает верхнюю границу числа байтов, которые могут содержаться в последовательности. Если m не задано (второй вариант декларации), предполагается максимальный размер 232 — 1.

Постоянную m обычно можно найти в спецификации протокола. Например, протокол подачи может декларировать максимальный размер передаваемых данных 8192 байта следующим образом:

         opaque filedata<8192>;

            0     1     2     3     4     5   ...
         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
         |        размер n       |байт0|байт1|...| n-1 |  0  |...|  0  |
         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
         |<-------4 байта------->|<------n байтов----->|<---r байтов-->|
                                 |<-----n+r (где (n+r) mod 4 = 0)----->|
                                                  VARIABLE-LENGTH OPAQUE

Превышение указанного в декларации максимального значения размера данных является ошибкой.

4.11. String — строка

Стандарт определяет строку из n (с номерами от 0 до n-1) символов ASCII, где размер строки задается целым числом без знака n (см. выше), а за ним следует n байтов самой строки. Байт m всегда предшествует в строке байту m+1, а байт 0 всегда следует за полем размера строки. Если значение n не кратно 4, после n байтов к строке добавляется r (от 11 до 3) байтов заполнения для выравнивания до размера, кратного 4. Строка байтов декларируется, как:

string object<m>;

или

string object<>;

Постоянная m обозначает верхнюю границу числа байтов, которые могут содержаться в последовательности. Если m не задано (второй вариант декларации), предполагается максимальный размер 232 — 1. Постоянную m обычно можно найти в спецификации протокола. Например, протокол подачи может декларировать максимальный размер имени файла 255 байтов, как показано ниже:

         string filename<255>;

            0     1     2     3     4     5   ...
         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
         |        размер n       |байт0|байт1|...| n-1 |  0  |...|  0  |
         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
         |<-------4 байта------->|<------n байтов----->|<---r байтов-->|
                                 |<-----n+r (где (n+r) mod 4 = 0)----->|
                                                                  STRING

Превышение указанного в декларации максимального значения размера данных является ошибкой.

4.12. Массив фиксированного размера

Декларация массива фиксированного размера из однородных элементов имеет вид:

type-name identifier[n];

Массивы фиксированного размера с элементами, имеющими номера от 0 до n-1 представляются путем кодирования (представления) отдельных элементов в порядке роста порядковых номеров от 0 до n-1. Размер каждого элемента в байтах кратен 4. Все элементы массива являются однотипными, но их размеры могут различаться. Например, в массиве строк все элементы имеют тип string, но могут различаться по размерам.

         +---+---+---+---+---+---+---+---+...+---+---+---+---+
         |   элемент 0   |   элемент 1   |...|  элемент n-1  |
         +---+---+---+---+---+---+---+---+...+---+---+---+---+
         |<--------------------n элементов------------------>|

                                               FIXED-LENGTH ARRAY

 

4.13. Массив переменного размера

Counted-массивы обеспечивают возможность создания массивов с переменным числом однотипных элементов. Массив представляется числом элементов n (целое число без знака), за которым следуют элементы массива с номерами от 0 до n-1. Декларация массива переменного размера имеет вид:

type-name identifier<m>;

или

type-name identifier<>;

Постоянная m задает максимально допустимое число элементов массива. Если значение m не задано (второй вариант) предполагается максимальное число элементов 232 — 1.

           0  1  2  3
         +--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
         |     n     | элемент 0 | элемент 1 |...|элемент n-1|
         +--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
         |<-4 байта->|<--------------n элементов------------>|
                                                         COUNTED ARRAY

Если значение n превышает максимальное число элементов массива, возникает ошибка.

4.14. Structure — структура

Структуры декларируются следующим образом:

         struct {
            component-declaration-A;
            component-declaration-B;
            ...
         } identifier;

Компоненты структуры кодируются в порядке их объявления в декларации структуры. Размер каждого компонента кратен 4 байтам, но компоненты могут иметь разные размеры.

         +-------------+-------------+...
         | компонент A | компонент B |...                      STRUCTURE
         +-------------+-------------+...

4.15. Discriminated Union — объединение с дискриминантом

Объединение этого типа состоит из дискриминанта, за которым следует тип, выбранный из множества предопределенных типов в соответствии со значением дискриминанта. Дискриминант может относиться к типу int, unsigned int или перечисляемому типу (например, bool). Типам компонент объединения (их называют arm — ветвь) предшествуют значения дискриминанта, определяющие их представление. Объединение с дискриминантом декларируется следующим образом:

         union switch (discriminant-declaration) {
         case discriminant-value-A:
            arm-declaration-A;
         case discriminant-value-B:
            arm-declaration-B;
         ...
         default: default-declaration;
         } identifier;

За каждым ключевым словом case следует корректное значение дискриминанта. Принятая по умолчанию ветвь (arm) является необязательной. Если она не задана, корректное представление объединения не может принимать неуказанных значений дискриминанта. Размер принимаемой ветви всегда кратен 4 байтам.

Объединение с дискриминантом представляется дискриминантом, за которым следует представление принимаемой ветви.

           0   1   2   3
         +---+---+---+---+---+---+---+---+
         |  discriminant |  implied arm  |          DISCRIMINATED UNION
         +---+---+---+---+---+---+---+---+
         |<---4 байта--->|

 

4.16. Void — пустой тип

В XDR пустой (void) тип имеет размер 0 байтов. Пустой тип полезен для описания операций, которые не принимают данных на входе и/или не возвращают их на выходе. Этот тип также полезен в объединениях, где некоторые ветви включают данные, а другие не включают. Декларация пустого типа имеет вид:

void;

Пустой тип можно представить следующим образом:

           ++
           ||                                                     VOID
           ++
         --><-- 0 байтов

 

4.17. Constant — константа

Декларация константы имеет вид:

const name-identifier = n;

Ключевое слово const служит для определения символьного имени константы, не декларируя каких-либо данных. Символьное имя может использоваться вместо константы в любом месте. Приведенный ниже пример определяет константу DOZEN со значением 12.

const DOZEN = 12;

4.18. Typedef — определение типа

Определение типа (typedef) не служит для декларирования каких-либо данных, но позволяет определять новые идентификаторы для декларирования данных. Синтаксис определения типа имеет вид:

typedef declaration;

Имя нового типа реально является именем переменной в декларативной части typedef. Например, можно определить новое имя типа eggbox на основе существующего типа egg:

typedef egg eggbox[DOZEN];

Переменные, декларируемые с использованием нового имени типа, имеют тот же тип, который указан для нового имени типа в typedef, если рассматривать его, как переменную. Например, две приведенных ниже декларации являются эквивалентными объявлениями переменной fresheggs:

eggbox fresheggs; egg fresheggs[DOZEN];

Для случаев, когда typedef включает определение struct, enum или union, существует другой (предпочтительный) синтаксис. В общем случае typedef вида:

typedef <<struct, union, or enum definition>> identifier;

можно преобразовать в другую форму, удалив часть typedef и поместив идентификатор после ключевого слова struct, union или enum вместо указания идентификатора в конце декларации. Ниже показаны два варианта определения типа bool:

         typedef enum {    /* использование typedef */
            FALSE = 0,
            TRUE = 1
         } bool;

         enum bool {       /* предпочтительный вариант */
            FALSE = 0,
            TRUE = 1
         };

Второй вариант является более предпочтительным, поскольку для определения нового имени типа не нужно просматривать декларацию до конца.

4.19. Optional-Data

Optional-data представляет собой один из вариантов объединения, который используется достаточно часто и по этой причине для него имеется специальный синтаксис декларирования. Декларация вида:

type-name *identifier;

эквивалентна декларации объединения:

         union switch (bool opted) {
         case TRUE:
            type-name element;
         case FALSE:
            void;
         } identifier;

Она также эквивалентна приведенной ниже декларации массива переменного размера, поскольку логическую переменную opted можно рассматривать, как размер массива:

type-name identifier<1>;

Тип Optional-data не интересен сам по себе, но он часто применяется для описания рекурсивных структур данных типа связанных списков или деревьев. Например, ниже определен тип stringlist, представляющий собой список (возможно пустой) строк произвольной длины:

        struct stringentry {
           string item<>;
           stringentry *next;
        };

        typedef stringentry *stringlist;

Эту декларацию можно заменить эквивалентной декларацией объединения:

         union stringlist switch (bool opted) {
         case TRUE:
            struct {
               string item<>;
               stringlist next;
            } element;
         case FALSE:
            void;
         };

 

или массива переменного размера:

struct stringentry {
string item<>;
stringentry next<1>;
};
typedef stringentry stringlist<1>;

Оба эти варианта «скрывают» тип stringlist, поэтому явная декларация optional-data является более предпочтительной. Тип optional-data также коррелирует с представлением рекурсивных структур данных в языках программирования высокого уровня (типа Pascal или C) с помощью указателей. Фактически синтаксис совпадает с синтаксисом языка C для указателей.

4.20. Направления дальнейшего развития

В стандарте XDR нет представления битовых полей и битовых массивов, поскольку стандарт базируется на байтовом представлении. Отсутствуют также упакованные (с двоичным кодированием) десятичные дроби.

Назначением стандарта XDR не было описание всех типов данных, которые могут передаваться между машинами. Стандарт, скорее, описывает наиболее распространенные типы данных языков высокого уровня типа Pascal или C, чтобы написанные на этих языках приложения могли обмениваться данными через ту или иную среду.

Можно представить расширения XDR, которые позволят описать практически все существующие протоколы (такие, как TCP). Минимальным требованием для реализации этого является поддержка различных размеров блока и разного порядка байтов. Описанный здесь вариант XDR можно рассматривать, как 4-байтовый вариант big-endian более широкого семейства XDR.

5. Обсуждение

(1) Зачем нужен язык описания данных? Чем плохи диаграммы?

Существует множество преимуществ использования языков описания данных типа XDR по сравнению с использованием диаграмм. Языки являются более формальными, чем диаграммы и позволяют снизить число неоднозначностей в описаниях. Язык проще для понимания и позволяет меньше думать о мелких деталях битового представления данных. Кроме того, существуют близкие аналогии между типами XDR и типами данных в языках высокого уровня таких, как C или Pascal. Это существенно упрощает реализацию модулей кодирования и декодирования данных XDR. Наконец, спецификация языка, как таковая, представляет собой строку ASCII, которая может предаваться между машинами для интерпретации «на лету».

(2) Почему в XDR применяется только один порядок байтов?

Поддержка разных вариантов порядка байтов требует наличия протоколов верхнего уровня для определения используемого порядка байтов. Поскольку XDR не является протоколом, он не может реализовать такую функцию. Преимущество использования единственного порядка байтов заключается в том, что данные в формате XDR могут быть записаны, например, на магнитную ленту и любая машина сможет интерпретировать их, поскольку для определения порядка данных не требуется протокол верхнего уровня.

(3) Почему XDR использует порядок байтов big-endian, а не little-endian?

Разве это «справедливо» по отношению с машинам типа VAX(r), которые вынуждены преобразовывать порядок байтов?

Выбор любого из двух порядков будет «несправедливым» по отношению к части машин. Многие архитектуры, включая Motorola 68000 и IBM 370, поддерживают порядок байтов big-endian.

(4) Почему XDR использует 4-байтовые блоки?

Выбор размера блока XDR является компромиссом. Выбор меньшего размера (скажем, 2) позволил бы представлять более экономно, но вызвал бы проблемы на машинах, которые не выравнивают данные по такой границе. Выбор большего размера (скажем, 8) обеспечил бы соответствие с выравниванием данных практически на всех машинах, но привел бы к неоправданному росту заполнения. Поэтому было выбрано компромиссное значение. 4-байтовые блоки обеспечивают достаточно экономное представление данный и выравнивание по 4-байтовой границе поддерживается большинством машин за исключением такой «экзотики», как 8-байтовые Cray.

(5) Зачем данные переменного размера дополняются нулями?

Желательно обеспечить одинаковое представление одних и тех же данных на всех машинах, поскольку это упрощает сравнение данных и вычисление контрольных сумм. Заполнение нулями неиспользуемых байтов обеспечивает однотипность представления.

(6) Почему не используется явной типизации данных?

Издержки на типизацию данных превосходят незначительные преимущества, которые она может дать. Одной из сложностей, связанных с типизацией, является необходимость поддержки поля типа. Другие издержки связаны с интерпретацией поля типа и соответствующими операциями. Кроме того, большинство протоколов знает ожидаемый тип данных, поэтому типизация будет избыточной информацией. Однако можно получить преимущества типизации данных и при использовании XDR. Одним из вариантов является представление строки, описывающей представляемые данные XDR, и самих данных. Другим вариантом является является присвоение значений для всех типов XDR и определение универсального типа, который служит дискриминантом значений, описывающих типы данных.

6. Спецификация языка XDR

6.1. Соглашения о нотации

В данной спецификации для описания языка XDR применяется расширенная нотация BNF12. Ниже приведено краткое описание нотации:

  1. Символы |, (, ), [, ], » и * имеют специальные значения.

  2. Терминальными символами являются строки любых символов, заключенные в двойные кавычки («).

  3. Нетерминальными символами являются строки символов, не имеющих специального значения.

  4. Варианты разделяются символом |.

  5. Необязательные элементы заключаются в квадратные скобки.

  6. Элементы группируются путем заключения их в скобки.

  7. Символ *, следующий за неким элементом, означает возможность вхождения любого числа таких элементов.

В качестве примера расмотрим запись:

"a " "very" (", " "very")* [" cold " "and "] " rainy " ("day" | "night")

которой соответствует бесконечное множество строк. Варианты таких строк включают:

"a very rainy day"
"a very, very rainy day"
"a very cold and rainy day"
"a very, very, very cold and rainy night"

6.2. Лексические замечания

  1. Комментарии начинаются символами /* и завершаются символами */.

  2. Пробельные символы служат в качестве разделителей элементов, а в остальном игнорируются.

  3. Идентификатор представляет собой букву, за которой могут следовать дополнительные буквы, цифры и символы подчеркивания (_). Регистр букв в идентификаторах не принимается во внимание.

  4. Десятичная константа выражает число по основанию 10 и представляет собой последовательность цифр. Первая цифра последовательности должна быть отлична от 0, последовательности может предшествовать знак минус (-).

  5. Шестнадцатеричная константа выражает число по основанию 16 и должна начинаться с последовательности 0x, за которой следует одна или множество шестнадцатеричных «цифр» (A, B, C, D, E, F, a, b, c, d, e, f, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9).

  6. Восьмеричная константа выражает число по основанию 8 и всегда начинается с символа 0, за которым следует одна или множество восьмеричных цифр (0, 1, 2, 3, 4, 5, 6, 7).

6.3. Синтаксическая информация

Декларация:

type-specifier identifier
| type-specifier identifier "[" value "]"
| type-specifier identifier "<" [ value ] ">"
| "opaque" identifier "[" value "]"
| "opaque" identifier "<" [ value ] ">"
| "string" identifier "<" [ value ] ">"
| type-specifier "*" identifier
| "void"

Значение:

constant
| identifier

Константа:

decimal-constant | hexadecimal-constant | octal-constant

Спецификатор типа:

[ "unsigned" ] "int"
| [ "unsigned" ] "hyper"
| "float"
| "double"
| "quadruple"
| "bool"
| enum-type-spec
| struct-type-spec
| union-type-spec
| identifier

Спецификация перечисляемого типа:

"enum" enum-body

Перечисление:

"{"
( identifier "=" value )
( "," identifier "=" value )*
"}"

Спецификация структуры:

"struct" struct-body

Структура:

"{"
( declaration ";" )
( declaration ";" )*
"}"

Спецификация объединения:

"union" union-body

Объединение:

"switch" "(" declaration ")" "{"
case-spec
case-spec *
[ "default" ":" declaration ";" ]
"}"

Спецификация вариантов:

( "case" value ":")
( "case" value ":") *
declaration ";"

Определение постоянной:

"const" identifier "=" constant ";"

Определение типа:

"typedef" declaration ";"
| "enum" identifier enum-body ";"
| "struct" identifier struct-body ";"
| "union" identifier union-body ";"

Определение:

type-def
| constant-def

Спецификация:

definition *

6.4. Замечания по синтаксису

  1. Следующие слова являются ключевыми и не могут использоваться в качестве идентификаторов: bool, case, const, default, double, quadruple, enum, float, hyper, int, opaque, string, struct, switch, typedef, union, unsigned и void.

  2. В качестве значений размера массивов могут использоваться только числа без знака. При использовании идентификатора в качестве размера этот идентификатор должен быть объявлен, как константа без знака с помощью определения const.

  3. Идентификаторы констант и типов в рамках данной спецификации используют общее пространство имен и должны быть уникальными в зоне их действия.

  4. Аналогично имена переменных должны быть уникальными в рамках структур и объединений. Вложенные структуры и объединения создают новые области действия переменных.

  5. Дискриминант объединения должен иметь тип, приводимый к целому числу. Т. е. он может относиться к типам int, unsigned int, bool, перечисляемым или typedef. Такое же требованием применяется к вариантам. Кроме того, каждое значение варианта может использоваться в декларации объединения не более одного раза.

7. Пример описания данных XDR

Ниже приведено краткое описание данных XDR для файла (file), который может передаваться с одной машины на другую.

         const MAXUSERNAME = 32;     /* максимальный размер имени пользователя */
         const MAXFILELEN = 65535;   /* максимальный размер файла              */
         const MAXNAMELEN = 255;     /* максимальный размер имени файла        */

         /*
          * Типы файлов:
          */
         enum filekind {
            TEXT = 0,       /* ascii-данные */
            DATA = 1,       /* raw-данные   */
            EXEC = 2        /* исполняемый  */
         };

         /*
          * Информация о файлах по их типам
          */
         union filetype switch (filekind kind) {
         case TEXT:
            void;                           /* нет дополнительной информации */
         case DATA:
            string creator<MAXNAMELEN>;     /* создатель данных              */
         case EXEC:
            string interpretor<MAXNAMELEN>; /* программный интерпретатор     */
         };

         /*
          * Полный файл:
          */
         struct file {
            string filename<MAXNAMELEN>; /* имя файла          */
            filetype type;               /* информация о файле */
            string owner<MAXUSERNAME>;   /* владелец файла     */
            opaque data<MAXFILELEN>;     /* дата файла         */

 

Предположим, что пользователь с именем john хочет сохранить свою программу sillyprog на языке lisp, содержащую просто строку данных (quit). Ниже показано представление файла:

Смещение

HEX-байты

ASCII

Комментарии

0

00 00 00 09

….

Размер имени файла (9)

4

73 69 6c 6c

sill

Символы имени файла

8

79 70 72 6f

ypro

… дополнительные символы …

12

67 00 00 00

g…

… и 3 байта заполнения (0)

16

00 00 00 02

….

Тип файла (EXEC = 2)

20

00 00 00 04

….

Размер имени интерпретатора (4)

24

6c 69 73 70

lisp

Имя интерпретатора

28

00 00 00 04

….

Размер имени владельца (4)

32

6a 6f 68 6e

john

Имя владельца

36

00 00 00 06

….

Число байтов данных в файле

40

28 71 75 69

(qui

Байты данных файла …

44

74 29 00 00

t)..

… и 2 байта заполнения (0)

8. Вопросы безопасности

XDR является языком описания данных, а не протоколом и, следовательно, не связан напрямую с вопросами безопасности. Протоколы, передающие данные в формате XDR (например, NFSv4), сами отвечают за вопросы безопасности при передаче данных.

Следует аккуратно кодировать и декодировать данные. Известные риски, которых можно избежать, включают:

  • Атаки на переполнение буфера. По возможности протоколы следует определять с явными пределами (путем использования нотации <[ значение ]> вместо < >) для элементов с типами данных переменного размера. Независимо от возможности явного ограничения переменных размеров элемента данного протокола, декодеры должны проверять размеры данных на входе в части предотвращения выхода за размеры приемных буферов.

  • Нулевые октеты в значении типа string. Если естественным для декодера форматом являются строки, завершающиеся nul-символом, видимый размер декодированного объекта будет меньше объема памяти, выделенного для строки. Некоторые интерфейсы возвращения (deallocation) памяти поддерживают параметр размера. При обращении к такому интерфейсу вызывающая сторона будет скорей всего передавать размер строки до первого nul-символа, добавляя к нему 1. Это несоответствие может приводить к «утечке» памяти (поскольку возвращаться памяти будет меньше, чем было выделено), которая может приводить к системным отказам и атакам с целью отказа в обслуживании.

  • Декодирование корректных символов ASCII, которые являются недопустимыми с точки зрения приложения. Например, некоторые операционные системы трактуют символ /, как разделитель компонент имени пути к файлу. Для протоколов, которые кодируют строки аргументов файловых операций, декодер должен обеспечить отсутствие символов / внутри компонент имени. В противном случае может быть создан файл с недопустимым символом / в имени, который будет сложено удалить и это, по сути, может служить атакой с целью отказа в обслуживании.

  • Отказы в обслуживании, вызываемые рекурсивными подпрограммами кодирования и декодирования. Рекурсивное кодирование и декодирование может обрабатывать структурированные данные, которые сами по себе могут включать прямые или непрямые ссылки на структурированные данные (например, связные списки):

              struct m {
                int x;
                struct m *next;
              };

Программа кодирования или декодирования может рекурсивно вызывать сама себя каждый арз при обнаружении другого элемента struct m. Атакующий может создать длинный связный список элементов struct m в запросе или отклике и такой список может привести к переполнению стека для кодера или декодера. Программы кодирования-декодирования следует создавать без использования рекурсии или ограничивать длину списков13.

9. Согласование с IANA

В будущем возможно (и весьма вероятно) добавление новых типов данных в XDR. Процесс добавления новых типов осуществляется в рамках стандартизации RFC и не включает регистрацию новых типов в IANA. Проекты стандартов RFC, которые обновляются или заменяются данным документов, должны быть отмечены соответствующим образом в базе данных RFC.

10. Торговые знаки и их владельцы

SUN WORKSTATION Sun Microsystems, Inc.

VAX Hewlett-Packard Company

IBM-PC International Business Machines Corporation

Cray Cray Inc.

NFS Sun Microsystems, Inc.

Ethernet Xerox Corporation.

Motorola 68000 Motorola, Inc.

IBM 370 International Business Machines Corporation

11. Стандарт ANSI/IEEE 754-1985

Определения NaN, нулей со знаком, бесконечности и денормализованных чисел для удобства заимствованы из [IEEE]. Определения чисел с плавающей запятой 4-кратной точности аналогичны определениям чисел обычной и двойной точности в [IEEE].

Ниже S обозначает бит знака, E — показатель степени, а F — дробную часть числа. Символ u указывает бит с неопределенным значения (0 или 1).

Для чисел с плавающей запятой:

Тип

S (1бит)

E (8 битов)

F (23 бита)

signalling NaN

u

255 (макс) (не менее 1 бита)

.0uuuuu—u

quiet NaN

u

255 (макс)

.1uuuuu—u

Отрицательная бесконечность

1

255 (макс)

.000000—0

Положительная бесконечность

0

255 (макс)

.000000—0

Отрицательный 0

1

0

.000000—0

Положительный 0

0

0

.000000—0

Для чисел с плавающей запятой двойной точности:

Тип

S (1бит)

E (11 битов)

F (52 бита)

signalling NaN

u

2047 (макс) (не менее 1 бита)

.0uuuuu—u

quiet NaN

u

2047 (макс)

.1uuuuu—u

Отрицательная бесконечность

1

2047 (макс)

.000000—0

Положительная бесконечность

0

2047 (макс)

.000000—0

Отрицательный 0

1

0

.000000—0

Положительный 0

0

0

.000000—0

Для чисел с плавающей запятой 4-кратной точности:

Тип

S (1бит)

E (15 битов)

F (112 битов)

signalling NaN

u

32767 (макс) (не менее 1 бита)

.0uuuuu—u

quiet NaN

u

32767 (макс)

.1uuuuu—u

Отрицательная бесконечность

1

32767 (макс)

.000000—0

Положительная бесконечность

0

32767 (макс)

.000000—0

Отрицательный 0

1

0

.000000—0

Положительный 0

0

0

.000000—0

Субнормальные числа представляются следующим образом:

Точность

Показатель

Значение

Одинарная

0

(-1)S * 2-126 * 0,F

Двойная

0

(-1)S * 2-1022 * 0,F

Четырехкратная

0

(-1)S * 2-16382 * 0,F

12. Нормативные документы

[IEEE] «IEEE Standard for Binary Floating-Point Arithmetic», ANSI/IEEE Standard 754-1985, Institute of Electrical and Electronics Engineers, August 1985.

13. Дополнительная литература

[KERN] Brian W. Kernighan & Dennis M. Ritchie, «The C Programming Language», Bell Laboratories, Murray Hill, New Jersey, 1978.

[COHE] Danny Cohen, «On Holy Wars and a Plea for Peace», IEEE Computer, October 1981.

[COUR] «Courier: The Remote Procedure Call Protocol», XEROX Corporation, XSIS 038112, December 1981.

[SPAR] «The SPARC Architecture Manual: Version 8», Prentice Hall, ISBN 0-13-825001-4.

[HPRE] «HP Precision Architecture Handbook», June 1987, 5954-9906.

14. Благодарности

Bob Lyon представлял Sun в рабочей группе ONC RPC в 1980-х. Компания Sun Microsystems, Inc. значится разработчиком RFC 1014. Raj Srinivasan и другие участники рабочей группы ONC RPC редактировали RFC 1014 в RFC 1832, который послужил основой для данного документа. Mike Eisler и Bill Janssen представили обзоры по реализациям данного стандарта. Kevin Coffman, Benny Halevy и Jon Peterson рассмотрели документ и дали свои замечания. Peter Astrand и Bryan Olson отметили несколько ошибок в RFC 1832, которые были исправлены в этом документе.

Адрес редактора

Mike Eisler

5765 Chase Point Circle

Colorado Springs, CO 80919

USA

Phone: 719-599-9026

EMail: email2mre-rfc4506@yahoo.com

Отправляйте комментарии по адресу: nfsv4@ietf.org

Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).

1External Data Representation Standard — Стандарт внешнего представления данных.

2Abstract Syntax Notation.

3Remote Procedure Call — удаленный вызов процедур.

4Network File System — сетевая файловая система.

5В оригинале сказано от 0 до 3, но 0 байтов добавляется при n кратном 4, а в начале предложения сказано «Если n не кратно 4». Особенности языка. Прим. перев.

6Underflow.

7Not a number — не число.

8Underflow.

9Not a number — не число.

10В оригинале сказано от 0, но в этом случае n будет кратно 4. Прим. перев.

11В оригинале сказано от 0, но в этом случае n будет кратно 4. Прим. перев.

12Back-Naur Form — форма Бэкуса-Наура.

13Глубину рекурсии. Прим. перев.




RFC 4491 Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile

Network Working Group                                   S. Leontiev, Ed.
Request for Comments: 4491                                    CRYPTO-PRO
Updates: 3279                                        D. Shefanovski, Ed.
Category: Standards Track                        Mobile TeleSystems OJSC
                                                                May 2006


           Using the GOST R 34.10-94, GOST R 34.10-2001, and
                  GOST R 34.11-94 Algorithms with the
               Internet X.509 Public Key Infrastructure
                      Certificate and CRL Profile

PDF

Статус документа

В этом документе приведена спецификация проекта стандартного протокола Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущий статус стандартизации протокола можно узнать из текущей версии документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2006).

Тезисы

Этот документ дополняет RFC 3279, описывая форматы представления, идентификаторы и форматы параметров для алгоритмов GOST R 34.10-94, GOST R 34.10-2001 и GOST R 34.11-94 для их применения в инфраструктуре открытых ключей Internet X.509 (PKI1).

Оглавление

Исключено в версии HTML.

1. Введение

Этот документ дополняет RFC 3279 [PKALGS] и описывает соглашения по использованию алгоритмов подписи GOST R 34.10-94 [GOST3431095, GOSTR341094] и GOST R 34.10-2001 [GOST3431004, GOSTR341001], алгоритмов создания производных ключей VKO GOST R 34.10-94 и VKO GOST R 34.10-2001, а также необратимых хэш-функций GOST R 34.11-94 [GOST3431195, GOSTR341194] в инфраструктуре открытых ключей Internet X.509 PKI [PROFILE].

Данный документ обеспечивает дополнительную информацию и спецификации, требуемые российским «Соглашением о совместимости СКЗИ».

Указаны идентификаторы алгоритмов и связанные параметры для субъектов открытых ключей, которые используют алгоритмы GOST R 34.10-94 [GOSTR341094]/VKO GOST R 34.10-94 [CPALGS] и GOST R 34.10-2001 [GOSTR341001]/VKO GOST R 34.10-2001 [CPALGS], а также формат представления для подписей, создаваемых этими алгоритмами. Указаны также идентификаторы алгоритмов для использования необратимой хэш-функции GOST R 34.11-94 с алгоритмами подписи GOST R 34.10-94 и GOST R 34.10-2001.

Данная спецификация определяет содержимое полей signatureAlgorithm, signatureValue, signature и subjectPublicKeyInfo в сертификатах и списках отзыва (CRL) X.509. Для каждого алгоритма представлены подходящие варианты расширения сертификата keyUsage.

Модули ASN.1, включающие все использованные в этом документе определения, можно найти в [CPALGS].

1.1. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].

2. Поддержка алгоритмов

В этом разделе приведен обзор криптографических алгоритмов, которые могут использоваться с сертификатами Internet X.509 и профилями CRL [PROFILE]. Описаны необратимые хэш-функции и алгоритмы цифровой подписи, которые могут применяться для подписывания сертификатов и CRLs, а также приведены идентификаторы объектов (OID) и представления ASN.1 для открытых ключей, содержащихся в сертификатах.

Удостоверяющие центры (CA2) и/или приложения, соответствующие этому стандарту, должны поддерживать хотя бы один из указанных алгоритмов открытых ключей и подписи.

2.1. Необратимая хэш-функция

В этом разделе описано использование необратимой и не имеющей коллизий хэш-функции GOST R 34.11-94, единственной, которая может применяться с алгоритмами цифровой подписи GOST R 34.10-94/2001. Данные, которые хэшируются для подписания сертификатов и CRL, полностью описаны в RFC 3280 [PROFILE].

2.1.1. Необратимая хэш-функция GOST R 34.11-94

Хэш-функция GOST R 34.11-94 разработана Главным управлением безопасности связи Федерального агентства правительственной связи и информации, а также Всероссийским НИИ Стандартизации. Алгоритм GOST R 34.11-94 дает на выходе 256-битовое хэш-значение для произвольного конечного размера входных данных. Данный документ не включает полной спецификации GOST R 34.11-94, которую можно найти в [GOSTR341194] на русском языке. В работе [Schneier95], параграф 18.11, стр. 454 приведено краткое техническое описание алгоритма на английском языке.

Данная функция должна всегда применяться с набором параметров, идентифицируемым id-GostR3411-94-CryptoProParamSet (см. параграф 8.2 [CPALGS]).

2.2. Алгоритмы подписи

Соответствующие данной спецификации УЦ могут использовать алгоритмы подписи GOST R 34.10-94 и GOST R 34.10-2001 для подписывания сертификатов и CRL.

Эти алгоритмы подписи во всех случаях должны применяться с необратимой хэш-функцией GOST R 34.11-94 как указано в [GOSTR341094] b [GOSTR341001].

В этом разделе определены идентификаторы и параметры алгоритмов для использования в поле signatureAlgorithm структур Certificate и CertificateList.

2.2.1. Алгоритм подписи GOST R 34.10-94

Алгоритм GOST R 34.10-94 разработан Главным управлением безопасности связи Федерального агентства правительственной связи и информации, а также Всероссийским НИИ Стандартизации. В данном документе не приводится полной спецификации алгоритма GOST R 34.10-94, которая дана в [GOSTR341094] на русском языке, а краткое описание на английском языке содержится в работе [Schneier95] (глава 20.3, стр. 495).

Идентификатор объекта ASN.1 для этого алгоритма цифровой подписи приведен ниже.

   id-GostR3411-94-with-GostR3410-94 OBJECT IDENTIFIER ::=
      { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) gostR3411-94-with-gostR3410-94(4) }

Если идентификатор алгоритма id-GostR3411-94-with-GostR3410-94 указан в поле algorithm структуры AlgorithmIdentifier, поле parameters нужно опускать. Т. е., в качестве AlgorithmIdentifier нужно указывать последовательность (SEQUENCE) из одной компоненты OBJECT IDENTIFIER id-GostR3411-94-with-GostR3410-94.

Алгоритм электронной подписи GOST R 34.10-94 создает цифровую подпись в форме двух 256-битовых значений r’ и s. Их представление строками октетов будет занимать 64 октета, из которых первые 32 содержат значение s в представлении big-endian, а вторые 32 октета содержат значение r’ в том же представлении.

Это определение значения подписи напрямую применимо для CMS [CMS], где такие значения представляются в виде строк октетов. Однако значения подписей в сертификатах и CRL [PROFILE] представляются в форме битовых строк и представление в виде строк октетов должно конвертироваться.

Для преобразования строки октетов в битовую строку старший бит первого октета строки нужно поместить в первый бито строки битов и т. д. до младшего бита последнего октета значения подписи, который нужно поместить в последний бит строки битов.

2.2.2. Алгоритм подписи GOST R 34.10-2001

Алгоритм GOST R 34.10-2001 разработан Главным управлением безопасности связи Федерального агентства правительственной связи и информации, а также Всероссийским НИИ Стандартизации. Данный документ не содержит полной спецификации GOST R 34.10-2001, она приведена в [GOSTR341001] (на русском языке).

Идентификатор объекта ASN.1 для этого алгоритма цифровой подписи приведен ниже.

   id-GostR3411-94-with-GostR3410-2001 OBJECT IDENTIFIER ::=
    { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) gostR3411-94-with-gostR3410-2001(3) }

Если идентификатор алгоритма id-GostR3411-94-with-GostR3410-2001 указан в поле algorithm структуры AlgorithmIdentifier, поле parameters нужно опускать. Т. е., в качестве AlgorithmIdentifier нужно указывать последовательность (SEQUENCE) из одной компоненты OBJECT IDENTIFIER id-GostR3411-94-with-GostR3410-2001.

Алгоритм электронной подписи GOST R 34.10-2001 создает цифровую подпись в форме двух 256-битовых значений r и s. Их представление строками октетов будет занимать 64 октета, из которых первые 32 содержат значение s в представлении big-endian, а вторые 32 октета содержат значение r в том же представлении.

Для преобразования строки октетов в битовую строку при использовании в сертификатах и CRL должен использоваться процесс, описанный выше (параграф 2.2.1).

2.3. Алгоритмы открытых ключей субъектов

В этом разделе определены идентификаторы OID и параметры открытых ключей для ключей, использующих алгоритмы GOST R 34.10-94 [GOSTR341094]/VKO GOST R 34.10-94 [CPALGS] и GOST R 34.10-2001 [GOSTR341001]/VKO GOST R 34.10-2001 [CPALGS].

Использование одного ключа для подписи и производного ключа не рекомендуется. Предусмотренное применение ключа может быть указано расширением сертификата keyUsage (см. [PROFILE], параграф 4.2.1.3).

2.3.1. Ключи GOST R 34.10-94

Открытые ключи GOST R 34.10-94 могут применяться с алгоритмом подписи GOST R 34.10-94 [GOSTR341094] и при создании производных ключей с помощью алгоритма VKO GOST R 34.10-94 [CPALGS].

Открытые ключи GOST R 34.10-94 указываются идентификатором OID, приведенным ниже.

   id-GostR3410-94 OBJECT IDENTIFIER ::=
       { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) gostR3410-94(20) }

Поле SubjectPublicKeyInfo.algorithm.algorithm (см. RFC 3280 [PROFILE]) для ключей GOST R 34.10-94 должно иметь значение id-GostR3410-94.

Когда идентификатор алгоритма id-GostR3410-94 указан в поле algorithm структуры AlgorithmIdentifier, поле parameters может быть опущено или иметь значение NULL. В остальных случаях это поле должно иметь приведенную ниже структуру.

    GostR3410-94-PublicKeyParameters ::=
        SEQUENCE {
            publicKeyParamSet
                OBJECT IDENTIFIER,
            digestParamSet
                OBJECT IDENTIFIER,
            encryptionParamSet
                OBJECT IDENTIFIER DEFAULT
                    id-Gost28147-89-CryptoPro-A-ParamSet
        }

где:

  • publicKeyParamSet — идентификатор параметров открытого ключа для GOST R 34.10-94 (см. параграф 8.3 в [CPALGS]);

  • digestParamSet — идентификатор параметров для GOST R 34.11-94 (см. параграф 8.2 в [CPALGS]);

  • encryptionParamSet — идентификатор параметров для GOST 28147-89 [GOST28147] (см. параграф 8.1 в [CPALGS])

Отсутствие параметров нужно обрабатывать в соответствии с параграфом 6.1 RFC 3280 [PROFILE], т. е., параметры наследуются из сертификата эмитента. Когда переменная working_public_key_parameters имеет значение null, сертификат и все подтверждаемые им подписи нужно отвергать.

Открытые ключи GOST R 34.10-94 должны кодироваться в формате ASN.1 DER как OCTET STRING, это представление нужно использовать в качестве содержимого (т. е., значения) компоненты subjectPublicKey (BIT STRING) элемента данных SubjectPublicKeyInfo.

   GostR3410-94-PublicKey ::= OCTET STRING — открытый ключ, Y

Поле GostR3410-94-PublicKey должно содержать 128 октетов (в представлении little-endian) открытого ключа Y = a^x (mod p), где a и p являются параметрами открытого ключа, а x — секретный ключ.

Некоторые приложения, содержащие ошибки, отбрасывают нулевые биты в конце битовой строки (BIT STRING), содержащей открытый ключ. Рекомендуется дополнять строку битов нулями до размера 1048 битов (131 октет) при декодировании с целью обеспечения возможности корректного преобразования инкапсулированной строки октетов (OCTET STRING).

При наличии в сертификате конечного элемента с открытым ключом GOST R 34.10-94 расширения keyUsage могут присутствовать следующие значения:

digitalSignature;

nonRepudiation;

keyEncipherment;

keyAgreement.

Если в сертификате открытого ключа GOST R 34.10-94 имеется расширение keyAgreement или keyEnchiperment, могут присутствовать также следующие значения:

encipherOnly;

decipherOnly.

В расширении keyUsage недопустимо заявлять одновременно encipherOnly и decipherOnly.

При наличии расширения keyUsage в сертификате подписавшего CA или CRL, содержащем открытый ключ GOST R 34.10-94, могут присутствовать также значения:

digitalSignature;

nonRepudiation;

keyCertSign;

cRLSign.

2.3.2. Ключи GOST R 34.10-2001

Открытые ключи GOST R 34.10-2001 могут использоваться с алгоритмом подписи GOST R 34.10-2001 [GOSTR341001] и алгоритмом создания производных ключей VKO GOST R 34.10-2001 [CPALGS].

Открытый ключ GOST R 34.10-2001 идентифицируется значением OID, показанным ниже.

   id-GostR3410-2001 OBJECT IDENTIFIER ::=
       { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) gostR3410-2001(19) }

Поле SubjectPublicKeyInfo.algorithm.algorithm (см. RFC 3280 [PROFILE]) для ключей GOST R 34.10-2001 должно иметь значение id-GostR3410-2001.

Если в поле algorithm структуры AlgorithmIdentifier указан идентификатор алгоритма id-GostR3410-2001, при кодировании поле parameters может быть опущено или установлено в NULL. В остальных случаях это поле должно иметь приведенную ниже структуру.

    GostR3410-2001-PublicKeyParameters ::=
        SEQUENCE {
            publicKeyParamSet
                OBJECT IDENTIFIER,
            digestParamSet
                OBJECT IDENTIFIER,
            encryptionParamSet
                OBJECT IDENTIFIER DEFAULT
                    id-Gost28147-89-CryptoPro-A-ParamSet
        }

где:

  • publicKeyParamSet — идентификатор параметров открытого ключа для GOST R 34.10-2001 (см. параграф 8.4 в [CPALGS])

  • digestParamSet — идентификатор параметров для GOST R 34.11-94 (см. параграф 8.2 в [CPALGS])

  • encryptionParamSet — идентификатор параметров для GOST 28147-89 [GOST28147] (см. параграф 8.1 в [CPALGS])

Отсутствие параметров нужно обрабатывать в соответствии с параграфом 6.1 RFC 3280 [PROFILE], т. е., параметры наследуются из сертификата эмитента. Когда переменная working_public_key_parameters имеет значение null, сертификат и все подтверждаемые им подписи нужно отвергать.

Открытые ключи GOST R 34. 10-2001 должны кодироваться в формате ASN.1 DER как OCTET STRING, это представление нужно использовать в качестве содержимого (т. е., значения) компоненты subjectPublicKey (BIT STRING) элемента данных SubjectPublicKeyInfo.

   GostR3410-2001-PublicKey ::= OCTET STRING — вектор открытого ключа, Q

Согласно [GOSTR341001], открытый ключ является точкой эллиптической кривой Q = (x,y).

Строка GostR3410-2001-PublicKey должна содержать 64 октета, из которых первые 32 являются представлением little-endian для значения x, а оставшиеся 32 октета — представлением little-endian для y. Это соответствует двоичному представлению (<y>256||<x>256) из [GOSTR341001] (параграф 5.3).

Некоторые приложения, содержащие ошибки, отбрасывают нулевые биты в конце битовой строки (BIT STRING), содержащей открытый ключ. Рекомендуется дополнять строку битов нулями до размера 528 битов (66 октетов) при декодировании с целью обеспечения возможности корректного преобразования инкапсулированной строки октетов (OCTET STRING).

Ограничения на keyUsage для ключей GOST R 34.10-2001 совпадают с ограничениями, описанными в параграфе 2.3.1 для ключей GOST R 34.10-94.

3. Вопросы безопасности

Приложениям рекомендуется проверять значения подписей и открытых ключей на предмет соответствия стандартам [GOSTR341001, GOSTR341094] до использования этих значений.

При использовании сертификатов для поддержки цифровых подписей в качестве эквивалента рукописных подписей в контексте российского Федерального закона «Об электронной цифровой подписи» [RFEDSL] сертификат должен включать расширение keyUsage, это должно быть критичным и в keyUsage недопустимо включать keyEncipherment и keyAgreement.

Удостоверяющим центрам (CA) и приложениям рекомендуется обеспечивать уверенность в том, что секретный ключ для создания подписей не используется в течение периода, превосходящего разрешенный (обычно 15 месяцев для алгоритмов GOST R 34.10-94 и GOST R 34.10-2001).

Обсуждение вопросов безопасности, связанных с использованием параметров алгоритма, приведено в разделе «Вопросы безопасности» [CPALGS].

4. Примеры

4.1. Сертификат GOST R 34.10-94

 -----BEGIN CERTIFICATE-----
 MIICCzCCAboCECMO42BGlSTOxwvklBgufuswCAYGKoUDAgIEMGkxHTAbBgNVBAMM
 FEdvc3RSMzQxMC05NCBleGFtcGxlMRIwEAYDVQQKDAlDcnlwdG9Qcm8xCzAJBgNV
 BAYTAlJVMScwJQYJKoZIhvcNAQkBFhhHb3N0UjM0MTAtOTRAZXhhbXBsZS5jb20w
 HhcNMDUwODE2MTIzMjUwWhcNMTUwODE2MTIzMjUwWjBpMR0wGwYDVQQDDBRHb3N0
 UjM0MTAtOTQgZXhhbXBsZTESMBAGA1UECgwJQ3J5cHRvUHJvMQswCQYDVQQGEwJS
 VTEnMCUGCSqGSIb3DQEJARYYR29zdFIzNDEwLTk0QGV4YW1wbGUuY29tMIGlMBwG
 BiqFAwICFDASBgcqhQMCAiACBgcqhQMCAh4BA4GEAASBgLuEZuF5nls02CyAfxOo
 GWZxV/6MVCUhR28wCyd3RpjG+0dVvrey85NsObVCNyaE4g0QiiQOHwxCTSs7ESuo
 v2Y5MlyUi8Go/htjEvYJJYfMdRv05YmKCYJo01x3pg+2kBATjeM+fJyR1qwNCCw+
 eMG1wra3Gqgqi0WBkzIydvp7MAgGBiqFAwICBANBABHHCH4S3ALxAiMpR3aPRyqB
 g1DjB8zy5DEjiULIc+HeIveF81W9lOxGkZxnrFjXBSqnjLeFKgF1hffXOAP7zUM=
 -----END CERTIFICATE-----

   0 30  523: SEQUENCE {
   4 30  442:  SEQUENCE {
   8 02   16:   INTEGER
            :    23 0E E3 60 46 95 24 CE C7 0B E4 94 18 2E 7E EB
  26 30    8:   SEQUENCE {
  28 06    6:    OBJECT IDENTIFIER
            :     id-GostR3411-94-with-GostR3410-94 (1 2 643 2 2 4)
            :    }
  36 30  105:   SEQUENCE {
  38 31   29:    SET {
  40 30   27:     SEQUENCE {
  42 06    3:      OBJECT IDENTIFIER commonName (2 5 4 3)
  47 0C   20:      UTF8String 'GostR3410-94 example'
            :      }
            :     }
  69 31   18:    SET {
  71 30   16:     SEQUENCE {
  73 06    3:      OBJECT IDENTIFIER organizationName (2 5 4 10)
  78 0C    9:      UTF8String 'CryptoPro'
            :      }
            :     }
  89 31   11:    SET {
  91 30    9:     SEQUENCE {
  93 06    3:      OBJECT IDENTIFIER countryName (2 5 4 6)
  98 13    2:      PrintableString 'RU'
            :      }
            :     }
 102 31   39:    SET {
 104 30   37:     SEQUENCE {
 106 06    9:      OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1)
 117 16   24:      IA5String 'GostR3410-94@example.com'
            :      }
            :     }
            :    }
 143 30   30:   SEQUENCE {
 145 17   13:    UTCTime '050816123250Z'
 160 17   13:    UTCTime '150816123250Z'
            :    }
 175 30  105:   SEQUENCE {
 177 31   29:    SET {
 179 30   27:     SEQUENCE {
 181 06    3:      OBJECT IDENTIFIER commonName (2 5 4 3)
 186 0C   20:      UTF8String 'GostR3410-94 example'
            :      }
            :     }
 208 31   18:    SET {
 210 30   16:     SEQUENCE {
 212 06    3:      OBJECT IDENTIFIER organizationName (2 5 4 10)
 217 0C    9:      UTF8String 'CryptoPro'
            :      }
            :     }
 228 31   11:    SET {
 230 30    9:     SEQUENCE {
 232 06    3:      OBJECT IDENTIFIER countryName (2 5 4 6)
 237 13    2:      PrintableString 'RU'
            :      }
            :     }
 241 31   39:    SET {
 243 30   37:     SEQUENCE {
 245 06    9:      OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1)
 256 16   24:      IA5String 'GostR3410-94@example.com'
            :      }
            :     }
            :    }
 282 30  165:   SEQUENCE {
 285 30   28:    SEQUENCE {
 287 06    6:     OBJECT IDENTIFIER id-GostR3410-94 (1 2 643 2 2 20)
 295 30   18:     SEQUENCE {
 297 06    7:      OBJECT IDENTIFIER
            :       id-GostR3410-94-CryptoPro-A-ParamSet
            :        (1 2 643 2 2 32 2)
 306 06    7:      OBJECT IDENTIFIER
            :       id-GostR3411-94-CryptoProParamSet
            :        (1 2 643 2 2 30 1)
            :      }
            :     }
 315 03  132:    BIT STRING 0 unused bits, encapsulates {
 319 04  128:     OCTET STRING
            :      BB 84 66 E1 79 9E 5B 34 D8 2C 80 7F 13 A8 19 66
            :      71 57 FE 8C 54 25 21 47 6F 30 0B 27 77 46 98 C6
            :      FB 47 55 BE B7 B2 F3 93 6C 39 B5 42 37 26 84 E2
            :      0D 10 8A 24 0E 1F 0C 42 4D 2B 3B 11 2B A8 BF 66
            :      39 32 5C 94 8B C1 A8 FE 1B 63 12 F6 09 25 87 CC
            :      75 1B F4 E5 89 8A 09 82 68 D3 5C 77 A6 0F B6 90
            :      10 13 8D E3 3E 7C 9C 91 D6 AC 0D 08 2C 3E 78 C1
            :      B5 C2 B6 B7 1A A8 2A 8B 45 81 93 32 32 76 FA 7B
            :     }
            :    }
            :   }
 450 30    8:  SEQUENCE {
 452 06    6:   OBJECT IDENTIFIER
            :    id-GostR3411-94-with-GostR3410-94 (1 2 643 2 2 4)
            :   }
 460 03   65:  BIT STRING 0 unused bits
            :   11 C7 08 7E 12 DC 02 F1 02 23 29 47 76 8F 47 2A
            :   81 83 50 E3 07 CC F2 E4 31 23 89 42 C8 73 E1 DE
            :   22 F7 85 F3 55 BD 94 EC 46 91 9C 67 AC 58 D7 05
            :   2A A7 8C B7 85 2A 01 75 85 F7 D7 38 03 FB CD 43
            :  }

В подписи приведенного выше сертификата r’ имеет значение

 0x22F785F355BD94EC46919C67AC58D7052AA78CB7852A017585F7D73803FBCD43

s имеет значение

 0x11C7087E12DC02F102232947768F472A818350E307CCF2E431238942C873E1DE

4.2. Сертификат GOST R 34.10-2001

 -----BEGIN CERTIFICATE-----
 MIIB0DCCAX8CECv1xh7CEb0Xx9zUYma0LiEwCAYGKoUDAgIDMG0xHzAdBgNVBAMM
 Fkdvc3RSMzQxMC0yMDAxIGV4YW1wbGUxEjAQBgNVBAoMCUNyeXB0b1BybzELMAkG
 A1UEBhMCUlUxKTAnBgkqhkiG9w0BCQEWGkdvc3RSMzQxMC0yMDAxQGV4YW1wbGUu
 Y29tMB4XDTA1MDgxNjE0MTgyMFoXDTE1MDgxNjE0MTgyMFowbTEfMB0GA1UEAwwW
 R29zdFIzNDEwLTIwMDEgZXhhbXBsZTESMBAGA1UECgwJQ3J5cHRvUHJvMQswCQYD
 VQQGEwJSVTEpMCcGCSqGSIb3DQEJARYaR29zdFIzNDEwLTIwMDFAZXhhbXBsZS5j
 b20wYzAcBgYqhQMCAhMwEgYHKoUDAgIkAAYHKoUDAgIeAQNDAARAhJVodWACGkB1
 CM0TjDGJLP3lBQN6Q1z0bSsP508yfleP68wWuZWIA9CafIWuD+SN6qa7flbHy7Df
 D2a8yuoaYDAIBgYqhQMCAgMDQQA8L8kJRLcnqeyn1en7U23Sw6pkfEQu3u0xFkVP
 vFQ/3cHeF26NG+xxtZPz3TaTVXdoiYkXYiD02rEx1bUcM97i
 -----END CERTIFICATE-----

   0 30  464: SEQUENCE {
   4 30  383:  SEQUENCE {
   8 02   16:   INTEGER
            :    2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21
  26 30    8:   SEQUENCE {
  28 06    6:    OBJECT IDENTIFIER
            :     id-GostR3411-94-with-GostR3410-2001 (1 2 643 2 2 3)
            :    }
  36 30  109:   SEQUENCE {
  38 31   31:    SET {
  40 30   29:     SEQUENCE {
  42 06    3:      OBJECT IDENTIFIER commonName (2 5 4 3)
  47 0C   22:      UTF8String 'GostR3410-2001 example'
            :      }
            :     }
  71 31   18:    SET {
  73 30   16:     SEQUENCE {
  75 06    3:      OBJECT IDENTIFIER organizationName (2 5 4 10)
  80 0C    9:      UTF8String 'CryptoPro'
            :      }
            :     }
  91 31   11:    SET {
  93 30    9:     SEQUENCE {
  95 06    3:      OBJECT IDENTIFIER countryName (2 5 4 6)
 100 13    2:      PrintableString 'RU'
            :      }
            :     }
 104 31   41:    SET {
 106 30   39:     SEQUENCE {
 108 06    9:      OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1)
 119 16   26:      IA5String 'GostR3410-2001@example.com'
            :      }
            :     }
            :    }
 147 30   30:   SEQUENCE {
 149 17   13:    UTCTime '050816141820Z'
 164 17   13:    UTCTime '150816141820Z'
            :    }
 179 30  109:   SEQUENCE {
 181 31   31:    SET {
 183 30   29:     SEQUENCE {
 185 06    3:      OBJECT IDENTIFIER commonName (2 5 4 3)
 190 0C   22:      UTF8String 'GostR3410-2001 example'
            :      }
            :     }
 214 31   18:    SET {
 216 30   16:     SEQUENCE {
 218 06    3:      OBJECT IDENTIFIER organizationName (2 5 4 10)
 223 0C    9:      UTF8String 'CryptoPro'
            :      }
            :     }
 234 31   11:    SET {
 236 30    9:     SEQUENCE {
 238 06    3:      OBJECT IDENTIFIER countryName (2 5 4 6)
 243 13    2:      PrintableString 'RU'
            :      }
            :     }
 247 31   41:    SET {
 249 30   39:     SEQUENCE {
 251 06    9:      OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1)
 262 16   26:      IA5String 'GostR3410-2001@example.com'
            :      }
            :     }
            :    }
 290 30   99:   SEQUENCE {
 292 30   28:    SEQUENCE {
 294 06    6:     OBJECT IDENTIFIER id-GostR3410-2001 (1 2 643 2 2 19)
 302 30   18:     SEQUENCE {
 304 06    7:      OBJECT IDENTIFIER
            :       id-GostR3410-2001-CryptoPro-XchA-ParamSet
            :        (1 2 643 2 2 36 0)
 313 06    7:      OBJECT IDENTIFIER
            :       id-GostR3411-94-CryptoProParamSet
            :        (1 2 643 2 2 30 1)
            :      }
            :     }
 322 03   67:    BIT STRING 0 unused bits, encapsulates {
 325 04   64:     OCTET STRING
            :      84 95 68 75 60 02 1A 40 75 08 CD 13 8C 31 89 2C
            :      FD E5 05 03 7A 43 5C F4 6D 2B 0F E7 4F 32 7E 57
            :      8F EB CC 16 B9 95 88 03 D0 9A 7C 85 AE 0F E4 8D
            :      EA A6 BB 7E 56 C7 CB B0 DF 0F 66 BC CA EA 1A 60
            :     }
            :    }
            :   }
 391 30    8:  SEQUENCE {
 393 06    6:   OBJECT IDENTIFIER
            :    id-GostR3411-94-with-GostR3410-2001 (1 2 643 2 2 3)
            :   }
 401 03   65:  BIT STRING 0 unused bits
            :   3C 2F C9 09 44 B7 27 A9 EC A7 D5 E9 FB 53 6D D2
            :   C3 AA 64 7C 44 2E DE ED 31 16 45 4F BC 54 3F DD
            :   C1 DE 17 6E 8D 1B EC 71 B5 93 F3 DD 36 93 55 77
            :   68 89 89 17 62 20 F4 DA B1 31 D5 B5 1C 33 DE E2
            :  }

В открытом ключе приведенного выше сертификата x имеет значение

 0x577E324FE70F2B6DF45C437A0305E5FD2C89318C13CD0875401A026075689584

y имеет значение

 0x601AEACABC660FDFB0CBC7567EBBA6EA8DE40FAE857C9AD0038895B916CCEB8F

Соответствующий секретный ключ имеет значение d

 0x0B293BE050D0082BDAE785631A6BAB68F35B42786D6DDA56AFAF169891040F77

В приведенном выше сертификате r имеет значение

 0xC1DE176E8D1BEC71B593F3DD36935577688989176220F4DAB131D5B51C33DEE2

s имеет значение

 0x3C2FC90944B727A9ECA7D5E9FB536DD2C3AA647C442EDEED3116454FBC543FDD

5. Благодарности

Этот документ был подготовлен в соответствии с «Соглашением о совместимости СКЗИ», подписанным ФГУП НТЦ «Атлас», ООО «КРИПТО-ПРО», ООО «Фактор-ТС», ЗАО «МО ПНИЭИ», ООО «Инфотекс», ЗАО «СПбРЦЗИ», ООО «Криптоком», ООО «Р-Альфа». Целью этого соглашения является обеспечение взаимной совместимости продукции и решений.

Авторы выражают свою признательность

представительству компании Microsoft в России за предоставление информации о продукции и решениях компании, а также технические консультации в части PKI;

представительству RSA Security в России и компании «Демос» за активное сотрудничество и неоценимую помощь в создании этого документа;

RSA Security Inc за тестирование совместимости предложенных форматов данных при встраивании в продукцию RSA Keon;

Baltimore Technology plc за тестирование совместимости предложенных форматов данных при встраивании в их продукцию UniCERT;

Peter Gutmann за полезную программу dumpasn1;

Russ Housley (Vigil Security, LLC, housley@vigilsec.com) и Василию Сахарову (DEMOS Co Ltd, svp@dol.ru) за поощрение авторов к созданию этого документа;

Григорию Чудову за помощь в прохождении процесса IETF для этого документа;

Дмитрию Приходько (VSTU, PrikhodkoDV@volgablob.ru) за неоценимую помощь в корректуре этого документа и проверку формы и содержания структур ASN.1 упомянутых и использованных в документе.

6. Литература

6.1. Нормативные документы

[GOST28147] «Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования. ГОСТ 28147-89″, Государственный стандарт СССР, Государственный комитет СССР по стандартизации, 1989. (на русском языке)

[GOST3431195] «Информационная технология. Криптографическая защита информации. Функция хэширования.», ГОСТ 34.311-95, Межгосударственный совет по стандартизации, метрологии и сертификации (МГС), Минск, 1995. (на русском языке)

[GOST3431095] «Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма.», ГОСТ 34.310-95, Межгосударственный совет по стандартизации, метрологии и сертификации (МГС), Минск, 1995. (на русском языке)

[GOST3431004] «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи.»3, ГОСТ 34.310-2004, Межгосударственный совет по стандартизации, метрологии и сертификации (МГС), Минск, 2004. (на русском языке)

[GOSTR341094] «Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма.», ГОСТ Р 34.10-94, Государственный стандарт Российской Федерации, Госстандарт России, 1994. (на русском языке)

[GOSTR341001] «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи.», ГОСТ Р 34.10-2001, Государственный стандарт Российской Федерации, Госстандарт России, 2001. (на русском языке)

[GOSTR341194] «Информационная технология. Криптографическая защита информации. Функция хэширования.», ГОСТ Р 34.11-944, Государственный стандарт Российской Федерации, Госстандарт России, 1994. (на русском языке)

[CPALGS] Popov, V., Kurepkin, I., and S. Leontiev, «Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms», RFC 4357, January 2006.

[PKALGS] Bassham, L., Polk, W., and R. Housley, «Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 3279, April 2002.

[PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 3280, April 2002.

[X.660] ITU-T Recommendation X.660 Information Technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), 1997.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

6.2. Дополнительная литература

[Schneier95] B. Schneier, Applied Cryptography, Second Edition, John Wiley & Sons, Inc., 1995.

[RFEDSL] Федеральный закон «Об электронной цифровой подписи» от 10.01.2002 N 1-ФЗ5

[CMS] Housley, R., «Cryptographic Message Syntax (CMS)», RFC 3852, July 2004.

Адреса авторов

Сергей Леонтьев, редактор

CRYPTO-PRO

38, Obraztsova,

Moscow, 127018, Russian Federation

EMail: lse@cryptopro.ru

Денис Стефановский, редактор

Mobile TeleSystems OJSC

4, Marksistskaya Str.,

Moscow, 109147, Russian Federation

EMail: dbs@mts.ru

Григорий Чудов

CRYPTO-PRO

38, Obraztsova,

Moscow, 127018, Russian Federation

EMail: chudov@cryptopro.ru

Александр Афанасьев

Factor-TS

office 711, 14, Presnenskij val,

Moscow, 123557, Russian Federation

EMail: afa1@factor-ts.ru

Николай Никишин

Infotecs GmbH

p/b 35, 80-5, Leningradskij prospekt,

Moscow, 125315, Russian Federation

EMail: nikishin@infotecs.ru

Болеслав Изотов

FGUE STC «Atlas»

38, Obraztsova,

Moscow, 127018, Russian Federation

EMail: izotov@nii.voskhod.ru

Елена Минаева

MD PREI

build 3, 6A, Vtoroj Troitskij per.,

Moscow, Russian Federation

EMail: evminaeva@mail.ru

Игорь Остапенко

MD PREI

Office 600, 14, B.Novodmitrovskaya,

Moscow, Russian Federation

EMail: igori@mo.msk.ru

Сергей Муругов

R-Alpha

4/1, Raspletina,

Moscow, 123060, Russian Federation

EMail: msm@top-cross.ru

Игорь Устинов

Cryptocom

office 239, 51, Leninskij prospekt,

Moscow, 119991, Russian Federation

EMail: igus@cryptocom.ru

Анатолий Еркин

SPRCIS (SPbRCZI)

1, Obrucheva,

St.Petersburg, 195220, Russian Federation

EMail: erkin@nevsky.net

Перевод на русский язык

Николай Малых

nmalykh@gmail.com


Полное заявление авторских прав

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.


Подтверждение

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).


1Public Key Infrastructure.

2Certification authority.

3Название стандарта на английском языке в оригинале указано неверно (см. https://www.rfc-editor.org/errata/eid5099). Прим. перев.

4В оригинале ошибочно указано GOST R 31.10-94 (см. https://www.rfc-editor.org/errata/eid5089). Прим. перев.

5В соответствии с Федеральным законом от 6 апреля 2011 г. N 63-ФЗ утратил силу с 01.07.2013 г. Прим. перев.




RFC 4490 Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)

Network Working Group                                   S. Leontiev, Ed.
Request for Comments: 4490                                G. Chudov, Ed.
Category: Standards Track                                     CRYPTO-PRO
                                                                May 2006

Использование алгоритмов ГОСТ 28147-89, ГОСТ Р R 34.11-94, ГОСТ Р GOST R 34.10-94 и ГОСТ Р 34.10-2001 с синтаксисом криптографический сообщений (CMS)

Using the GOST 28147-89, GOST R 34.11-94,

GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with

Cryptographic Message Syntax (CMS)

PDF

Статус документа

В этом документе приведена спецификация проекта стандартного протокола Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущий статус стандартизации протокола можно узнать из текущей версии документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2006).

Тезисы

Данный документ описывает соглашения по использованию криптографических алгоритмов GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001 и GOST R 34.11-94 с синтаксисом криптографических сообщений (CMS1). CMS применяется для цифровых подписей, дайджестов, аутентификации и шифрования произвольного содержимого сообщений.

Оглавление

Исключено в версии HTML.

1. Введение

Синтаксис криптографических сообщений [CMS] используется для цифровых подписей, дайджестов, аутентификации и шифрования произвольного содержимого сообщений. Эта дополняющая спецификация описывает использование криптографических алгоритмов GOST 28147-89 [GOST28147], GOST R 34.10-94 [GOST3431095, GOSTR341094], GOST R 34.10-2001 [GOST3431004, GOSTR341001] и GOST R 34.11-94 [GOST3431195, GOSTR341194] в CMS, предложенное компанией «Крипто-Про» в рамках «Соглашения о совместимости СКЗИ». Данный документ не описывает упомянутые криптографические алгоритмы, которые определены в соответствующих национальных стандартах.

Значения CMS создаются с использованием синтаксиса ASN.1 [X.208-88] и представления BER [X.209-88]. Данный документ задает идентификаторы для каждого алгоритма, включая ASN.1 для идентификаторов объектов и всех связанных параметров.

Определены поля CMS, используемые каждым алгоритмом.

1.1. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].

2. Алгоритмы хеширования сообщений

В этом разделе описаны соглашения для использования алгоритма GOST R 34.11-94 в CMS.

Хэш-значения «отпечатков» (digest) размещаются в поле digest структуры DigestedData и подписанном атрибуте Message Digest. Кроме того, хэш-значения являются входными данными для алгоритмов подписи.

2.1. Алгоритм GOST R 34.11-94

Хэш-функция GOST R 34.11-94 разработана Главным управлением безопасности связи Федерального агентства правительственной связи и информации, а также Всероссийским НИИ Стандартизации. Алгоритм GOST R 34.11-94 дает на выходе 256-битовое хэш-значение для произвольного конечного размера входных данных. Данный документ не включает полной спецификации GOST R 34.11-94, которую можно найти в [GOSTR341194] на русском языке. В работе [Schneier95], параграф 18.11, стр. 454 приведено краткое техническое описание алгоритма на английском языке.

Идентификатор алгоритма хэширования GOST R 34.11-94 приведен ниже.

   id-GostR3411-94 OBJECT IDENTIFIER ::=
         { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) gostr3411(9) }

В структуре AlgorithmIdentifier должно присутствовать поле parameters и это поле должно иметь значение NULL. Реализации могут воспринимать структуры GOST R 34.11-94 AlgorithmIdentifier как без поля parameters так и со полем, имеющим значение NULL.

Эта функция всегда используется с принятым по умолчанию id-GostR3411-94-CryptoProParamSet (см. параграф 8.2 в [CPALGS]).

При наличии подписанного атрибута хэш DigestedData содержит 32-байтовый «отпечаток» (хэш) в представлении little-endian

   GostR3411-94-Digest ::= OCTET STRING (SIZE (32))

3. Алгоритмы подписи

В этом разделе указаны процедуры CMS для алгоритмов цифровой подписи GOST R 34.10-94 и GOST R 34.10-2001.

Идентификаторы алгоритмов размещаются в поле signatureAlgorithm структуры SignerInfo, вложенной в структуру SignedData. Идентификаторы алгоритма указываются также в поле signatureAlgorithm структуры SignerInfo атрибутов удостоверяющей подписи.

Значения подписи размещаются в поле signature структуры SignerInfo, вложенной в SignedData, а также в поле signature структуры SignerInfo атрибутов удостоверяющей подписи.

3.1. Алгоритм GOST R 34.10-94

Алгоритм GOST R 34.10-94 разработан Главным управлением безопасности связи Федерального агентства правительственной связи и информации, а также Всероссийским НИИ Стандартизации. Этот алгоритм подписи должен использоваться совместно с алгоритмом хеширования сообщений GOST R 34.11-94. В данном документе не приводится полной спецификации алгоритма GOST R 34.10-94, которая приведена в [GOSTR341094] на русском языке, а краткое описание на английском языке содержится в работе [Schneier95] (глава 20.3, стр. 495).

Идентификатор алгоритма открытого ключа для алгоритма цифровой подписи GOST R 34.10-94 приведен ниже

   id-GostR3410-94-signature OBJECT IDENTIFIER ::= id-GostR3410-94

Идентификатор id-GostR3410-94 определен в параграфе 2.3.1 [CPPK].

Алгоритм цифровой подписи GOST R 34.10-2001 создает подпись в виде двух 256-битовых чисел r и s. Ее представление в форме строки октетов включает 64, из которых первые 32 содержат представление s в формате big-endian, а вторые 32 — представление r в том же формате.

   GostR3410-94-Signature ::= OCTET STRING (SIZE (64))

3.2. Алгоритм GOST R 34.10-2001

Алгоритм GOST R 34.10-2001 разработан Главным управлением безопасности связи Федерального агентства правительственной связи и информации, а также Всероссийским НИИ Стандартизации. Этот алгоритм должен применяться вместе с GOST R 34.11-94. Данный документ не содержит полной спецификации GOST R 34.10-2001, она приведена в [GOSTR341001].

Идентификатор алгоритма открытого ключа для GOST R 34.10-2001 приведен ниже.

   id-GostR3410-2001-signature OBJECT IDENTIFIER ::= id-GostR3410-2001

Определение id-GostR3410-2001 дано в параграфе 2.3.2 документа [CPPK].

Алгоритм цифровой подписи GOST R 34.10-2001 создает подпись в виде двух 256-битовых чисел r и s. Ее представление в форме строки октетов включает 64 октета, из которых первые 32 содержат представление s в формате big-endian, а вторые 32 — представление r в том же формате.

   GostR3410-2001-Signature ::= OCTET STRING (SIZE (64))

4. Алгоритмы управления ключами

В этом разделе описаны алгоритмы согласования и доставки ключей, основанные на алгоритмах создания производных ключей VKO GOST R 34.10-94 и VKO GOST R 34.10-2001, а также алгоритмах шифрования ключей CryptoPro и GOST 28147-89, описанных в [CPALGS]. Они должны применяться только с алгоритмом шифрования содержимого GOST 28147-89, рассмотренным в разделе 5 данного документа.

4.1. Алгоритмы согласования ключей

В этом параграфе указаны соглашения, применяемые реализациями CMS, которые поддерживают согласование ключей с использованием алгоритмов VKO GOST R 34.10-94 и VKO GOST R 34.10-2001, описанных в [CPALGS].

Идентификаторы алгоритма согласования ключей размещаются в полях EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm и AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm.

Зашифрованные ключи шифрования содержимого размещаются в поле EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey. Зашифрованные ключи проверки подлинности сообщений размещаются в поле AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey.

4.1.1. Алгоритмы согласования на базе открытых ключей GOST R 34.10-94/2001

Использование поля EnvelopedData RecipientInfos KeyAgreeRecipientInfo описано ниже.

Поле version должно иметь значение 3.

В поле originator должно помещаться значение originatorKey. Поле algorithm в originatorKey должно содержать идентификатор объекта id-GostR3410-94 или id-GostR3410-2001 и соответствующие параметры (определены в параграфах 2.3.1 и 2.3.2 [CPPK]).

В поле originatorKey publicKey должен указываться открытый ключ отправителя.

В поле keyEncryptionAlgorithm должен помещаться идентификатор алгоритма id-GostR3410-94-CryptoPro-ESDH или id-GostR3410-2001-CryptoPro-ESDH в зависимости от алгоритма открытого ключа получателя. Полем идентификатора параметров для этих алгоритмов является KeyWrapAlgorithm и этот параметр должен присутствовать. KeyWrapAlgorithm указывает алгоритм и параметры, применяемые для шифрования ключа шифрования содержимого с помощью парного ключа шифрования ключей, созданного с использованием алгоритма согласования ключей VKO GOST R 34.10-94 или VKO GOST R 34.10-2001.

Синтаксис идентификаторов и параметров алгоритмов показан ниже.

        id-GostR3410-94-CryptoPro-ESDH OBJECT IDENTIFIER ::=
            { iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
              gostR3410-94-CryptoPro-ESDH(97) }

        id-GostR3410-2001-CryptoPro-ESDH OBJECT IDENTIFIER ::=
            { iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
              gostR3410-2001-CryptoPro-ESDH(96) }

        KeyWrapAlgorithm ::= AlgorithmIdentifier

Если keyEncryptionAlgorithm = id-GostR3410-94-CryptoPro-ESDH, в качестве KeyWrapAlgorithm должен указываться идентификатор id-Gost28147-89-CryptoPro-KeyWrap.

        id-Gost28147-89-CryptoPro-KeyWrap OBJECT IDENTIFIER ::=
            { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) keyWrap(13) cryptoPro(1) }

Алгоритм шифрования ключей CryptoPro описан в параграфах 6.3 и 6.4 [CPALGS].

Если keyEncryptionAlgorithm = id-GostR3410-2001-CryptoPro-ESDH, в качестве KeyWrapAlgorithm должен указываться идентификатор алгоритма id-Gost28147-89-CryptoPro-KeyWrap или id-Gost28147-89-None-KeyWrap.

        id-Gost28147-89-None-KeyWrap OBJECT IDENTIFIER ::=
            { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) keyWrap(13) none(0) }

Алгоритм шифрования ключей ГОСТ 28147-89 описан в параграфах 6.1 и 6.2 [CPALGS].

Должны присутствовать параметры алгоритма KeyWrapAlgorithm, синтаксис которых показан ниже.

        Gost28147-89-KeyWrapParameters ::=
          SEQUENCE {
              encryptionParamSet Gost28147-89-ParamSet,
              ukm                OCTET STRING (SIZE (8)) OPTIONAL
          }
          Gost28147-89-ParamSet ::= OBJECT IDENTIFIER

Поле ukm в структуре Gost28147-89-KeyWrapParameters должно отсутствовать.

В структуре KeyAgreeRecipientInfo поле ukm должно присутствовать и включать 8 октетов.

Поле encryptedKey должно инкапсулировать Gost28147-89-EncryptedKey, где поле maskKey должно отсутствовать.

      Gost28147-89-EncryptedKey ::=   SEQUENCE {
        encryptedKey         Gost28147-89-Key,
        maskKey              [0] IMPLICIT Gost28147-89-Key OPTIONAL,
        macKey               Gost28147-89-MAC
      }

Для получения ключа шифрования KEK используется секретный ключ, соответствующий originatorKey publicKey, и открытый ключу получателя с алгоритмом VKO GOST R 34.10-94 или VKO GOST R 34.10-2001 (описаны в [CPALGS]).

Затем применяется алгоритм шифрования ключа, указанный в KeyWrapAlgorithm, для получения CEK_ENC, CEK_MAC, и UKM. Для всех операций шифрования применяется набор параметров encryptionParamSet структуры Gost28147-89-KeyWrapParameters.

Полученный в результате зашифрованный ключ (CEK_ENC) помещается в поле encryptedKey структуры Gost28147-89-EncryptedKey, код mac (CEK_MAC) в поле macKey этой структуры, а UKM в поле ukm структуры KeyAgreeRecipientInfo.

4.2. Алгоритмы доставки ключей

В этом разделе описаны соглашения, используемые реализациями CMS, которые поддерживают доставку ключей с помощью алгоритмов VKO GOST R 34.10-94 и VKO GOST R 34.10-2001, описанных [CPALGS].

Идентификатор алгоритма доставки ключей помещается в поле EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm.

Зашифрованный ключ шифрования содержимого для транспортировки помещается в поле EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey.

4.2.1. Доставка на базе открытых ключей GOST R 34.10-94/2001

Использование поля EnvelopedData RecipientInfos KeyTransRecipientInfo рассмотрено ниже.

Поле version должно иметь значение 0 или 3.

keyEncryptionAlgorithm и параметры алгоритма должны совпадать с алгоритмом открытого ключа получателя и параметрами этого алгоритма.

encryptedKey включает в себя структуру GostR3410-KeyTransport, состоящую из зашифрованного ключа шифрования содержимого, значения MAC для него, параметров алгоритма GOST 28147-89, использованных при шифровании ключа, эфемерного открытого ключа отправителя и ключевого материала UKM (UserKeyingMaterial, см параграф 10.2.6 [CMS]).

Поле transportParameters должно присутствовать.

Поле ephemeralPublicKey должно присутствовать, а его параметры (при наличии) должны совпадать с параметрами открытого ключа получателя.

      GostR3410-KeyTransport ::= SEQUENCE {
        sessionEncryptedKey   Gost28147-89-EncryptedKey,
        transportParameters
          [0] IMPLICIT GostR3410-TransportParameters OPTIONAL
      }

      GostR3410-TransportParameters ::= SEQUENCE {
        encryptionParamSet   OBJECT IDENTIFIER,
        ephemeralPublicKey   [0] IMPLICIT SubjectPublicKeyInfo OPTIONAL,
        ukm                  OCTET STRING
      }

Ключ шифрования ключей KEK получается с использованием секретного ключа, соответствующего GostR3410-TransportParameters ephemeralPublicKey и открытому ключу получателя, на основе алгоритма VKO GOST R 34.10-94 или VKO GOST R 34.10-2001 (см. [CPALGS]).

Затем используется алгоритм CryptoPro для создания CEK_ENC, CEK_MAC и UKM с параметрами GostR3410-TransportParameters encryptionParamSet для всех операций шифрования.

Полученный в результате зашифрованный ключ (CEK_ENC) помещается в поле Gost28147-89-EncryptedKey encryptedKey, значение mac для него (CEK_MAC) — в поле Gost28147-89-EncryptedKey macKey, а UKM — в поле GostR3410-TransportParameters ukm.

5. Алгоритм шифрования содержимого

В этом разделе описаны соглашения, используемые реализациями CMS с поддержкой шифрования содержимого на основе алгоритма GOST 28147-89.

Идентификаторы алгоритма шифрования содержимого помещаются в поля EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm и EncryptedData EncryptedContentInfo contentEncryptionAlgorithm.

Алгоритмы шифрования содержимого применяются для шифрования данных в полях EnvelopedData EncryptedContentInfo encryptedContent и EncryptedData EncryptedContentInfo encryptedContent.

5.1. Алгоритм GOST 28147-89

В этом параграфе описано использование алгоритма GOST 28147-89 для шифрования данных.

Алгоритм GOST 28147-89 полностью описан в документе [GOST28147] (на русском языке).

Этот документ задает для алгоритма идентификатор объекта (OID)

   id-Gost28147-89 OBJECT IDENTIFIER ::=
         { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) gost28147-89(21) }

Параметры алгоритма должны присутствовать и имеют приведенную ниже структуру.

     Gost28147-89-Parameters ::=
       SEQUENCE {
         iv                   Gost28147-89-IV,
         encryptionParamSet   OBJECT IDENTIFIER
        }

     Gost28147-89-IV ::= OCTET STRING (SIZE (8))

Набор encryptionParamSet задает соответствующие параметры Gost28147-89-ParamSetParameters (см. параграф 8.1 в [CPALGS]).

6. Алгоритмы MAC

В этом разделе описаны соглашения, используемые реализациями CMS, которые поддерживают коды аутентификации сообщений (MAC1) на основе GOST R 34.11-94.

Идентификатор алгоритма MAC указывается в поле macAlgorithm структуры AuthenticatedData.

Значения кодов MAC помещаются в поле mac структуры AuthenticatedData.

6.1. HMAC с GOST R 34.11-94

Функция HMAC_GOSTR3411(K,text) основана на хэш-функции GOST R 34.11-94, как определено в разделе 3 [CPALGS].

Идентификатор объекта (OID) для этого алгоритма приведен ниже.

   id-HMACGostR3411-94 OBJECT IDENTIFIER ::=
         { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) hmacgostr3411(10) }

Данный алгоритм использует такие же параметры как алгоритм хеширования GOST R 34.11-94 и те же значения OID для их идентификации (см. [CPPK]).

7. Использование с S/MIME

В этом разделе описано применение определенных в данном документе алгоритмов совместно с S/MIME [RFC3851].

7.1. Параметр micalg

При использовании определенных в этом документе алгоритмов для параметра micalg следует устанавливать значение gostr3411-94, в остальных случаях должно указываться значение unknown.

7.2. Атрибут SMIMECapabilities

Значение SMIMECapability, указывающее поддержку алгоритма хэширования GOST R 34.11-94, представляет собой последовательность (SEQUENCE) с полем capabilityID, содержащим идентификатор алгоритма id-GostR3411-94 без параметров. DER-представление имеет вид

     30 08 06 06  2A 85 03 02  02 09

Значение SMIMECapability, указывающее поддержку алгоритма шифрования GOST 28147-89, представляет собой последовательность (SEQUENCE) с полем capabilityID, содержащим идентификатор алгоритма id-Gost28147-89 без параметров. DER-представление имеет вид

     30 08 06 06  2A 85 03 02  02 15

Если отправитель желает указать поддержку конкретного набора параметров, параметры SMIMECapability должны содержать структуру Gost28147-89-Parameters. Получатели должны игнорировать поле iv в структуре Gost28147-89-Parameters и предполагать, что отправитель поддерживает параметры, указанные в поле encryptionParamSet структуры Gost28147-89-Parameters.

DER-представление для SMIMECapability с индикацией поддержки GOST 28147-89 с id-Gost28147-89-CryptoPro-A-ParamSet (см. [CPALGS]) имеет вид

     30 1D 06 06  2A 85 03 02  02 15 30 13  04 08 00 00
     00 00 00 00  00 00 06 07  2A 85 03 02  02 1F 01

8. Вопросы безопасности

Соответствующие данной спецификации приложения должны использовать уникальные значения для полей ukm и iv. Получатели могут проверять уникальность заданных отправителем значений ukm и iv.

Программным приложениям рекомендуется проверять соответствие значений подписи, открытых ключей субъекта и параметров алгоритма стандартам [GOSTR341001] и [GOSTR341094] до их использования.

Параметры криптографического алгоритма влияют на его стойкость. Использовать параметры, не указанные в [CPALGS] не рекомендуется (см. раздел «Вопросы безопасности» в [CPALGS]).

Использовать один и тот же ключ для подписи и создания ключей не рекомендуется. При использовании подписанных документов CMS в качестве аналога подписанных человеком документов в контексте российского законодательства об электронной подписи [RFEDSL] сертификат подписывающей стороны должен включать расширение keyUsage, которое должно быть критическим, а включение keyEncipherment или keyAgreement в keyUsage недопустимо (см. [PROFILE], параграф 4.2.1.3). Приложение следует подавать на экспертизу в уполномоченную организацию для проверки в соответствии с целью использования и требованиями [RFEDSL], [RFLLIC] и [CRYPTOLIC].

9. Примеры

В приведенных здесь примерах используется тот же формат записи, что и в примерах [RFC4134] и для извлечения кода может применяться та же программа.

Если вы хотите извлечь код без использования программы, скопируйте все строки между маркерами |> и |<, удалите символы перевода страниц, а также символы | в начале каждой строки. В результате будет получен корректный блок данных Base64, который можно обработать любым декодером Base64.

9.1. Подписанное сообщение

Это сообщение подписано с использованием примера сертификата из параграфа 4.2 [CPPK]. Для проверки подписи сообщения можно использовать открытый ключ key (x,y) из того же параграфа.

   0  296: SEQUENCE {
   4    9:  OBJECT IDENTIFIER signedData
  15  281:  [0] {
  19  277:   SEQUENCE {
  23    1:    INTEGER 1
  26   12:    SET {
  28   10:     SEQUENCE {
  30    6:      OBJECT IDENTIFIER id-GostR3411-94
  38    0:      NULL
         :      }
         :     }
  40   27:    SEQUENCE {
  42    9:     OBJECT IDENTIFIER data
  53   14:     [0] {
  55   12:      OCTET STRING 73 61 6D 70 6C 65 20 74 65 78 74 0A
         :      }
         :     }
  69  228:    SET {
  72  225:     SEQUENCE {
  75    1:      INTEGER 1
  78  129:      SEQUENCE {
  81  109:       SEQUENCE {
  83   31:        SET {
  85   29:         SEQUENCE {
  87    3:          OBJECT IDENTIFIER commonName
  92   22:          UTF8String 'GostR3410-2001 example'
         :          }
         :         }
 116   18:        SET {
 118   16:         SEQUENCE {
 120    3:          OBJECT IDENTIFIER organizationName
 125    9:          UTF8String 'CryptoPro'
         :          }
         :         }
 136   11:        SET {
 138    9:         SEQUENCE {
 140    3:          OBJECT IDENTIFIER countryName
 145    2:          PrintableString 'RU'
         :          }
         :         }
 149   41:        SET {
 151   39:         SEQUENCE {
 153    9:          OBJECT IDENTIFIER emailAddress
 164   26:          IA5String 'GostR3410-2001@example.com'
         :          }
         :         }
         :        }
 192   16:       INTEGER
         :        2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21
         :       }
 210   10:      SEQUENCE {
 212    6:       OBJECT IDENTIFIER id-GostR3411-94
 220    0:       NULL
         :       }
 222   10:      SEQUENCE {
 224    6:       OBJECT IDENTIFIER id-GostR3410-2001
 232    0:       NULL
         :       }
 234   64:      OCTET STRING
         :       C0 C3 42 D9 3F 8F FE 25 11 11 88 77 BF 89 C3 DB
         :       83 42 04 D6 20 F9 68 2A 99 F6 FE 30 3B E4 F4 C8
         :       F8 D5 B4 DA FB E1 C6 91 67 34 1F BC A6 7A 0D 12
         :       7B FD 10 25 C6 51 DB 8D B2 F4 8C 71 7E ED 72 A9
         :      }
         :     }
         :    }
         :   }
         :  }

|>GostR3410-2001-signed.bin
|MIIBKAYJKoZIhvcNAQcCoIIBGTCCARUCAQExDDAKBgYqhQMCAgkFADAbBgkqhkiG
|9w0BBwGgDgQMc2FtcGxlIHRleHQKMYHkMIHhAgEBMIGBMG0xHzAdBgNVBAMMFkdv
|c3RSMzQxMC0yMDAxIGV4YW1wbGUxEjAQBgNVBAoMCUNyeXB0b1BybzELMAkGA1UE
|BhMCUlUxKTAnBgkqhkiG9w0BCQEWGkdvc3RSMzQxMC0yMDAxQGV4YW1wbGUuY29t
|AhAr9cYewhG9F8fc1GJmtC4hMAoGBiqFAwICCQUAMAoGBiqFAwICEwUABEDAw0LZ
|P4/+JRERiHe/icPbg0IE1iD5aCqZ9v4wO+T0yPjVtNr74caRZzQfvKZ6DRJ7/RAl
|xlHbjbL0jHF+7XKp
|<GostR3410-2001-signed.bin

9.2. Упакованное с согласованием ключей сообщение

Это сообщение зашифровано с использованием примера сертификата из параграфа 4.2 [CPPK] в качестве сертификата получателя. Для расшифровки сообщения можно использовать секретный ключ d из того же параграфа.

   0  420: SEQUENCE {
   4    9:  OBJECT IDENTIFIER envelopedData
  15  405:  [0] {
  19  401:   SEQUENCE {
  23    1:    INTEGER 2
  26  336:    SET {
  30  332:     [1] {
  34    1:      INTEGER 3
  37  101:      [0] {
  39   99:       [1] {
  41   28:        SEQUENCE {
  43    6:         OBJECT IDENTIFIER id-GostR3410-2001
  51   18:         SEQUENCE {
  53    7:          OBJECT IDENTIFIER
         :           id-GostR3410-2001-CryptoPro-XchA-ParamSet
  62    7:          OBJECT IDENTIFIER
         :           id-GostR3411-94-CryptoProParamSet
         :          }
         :         }
  71   67:        BIT STRING, encapsulates {
  74   64:         OCTET STRING
         :          B3 55 39 F4 67 81 97 2B A5 C4 D9 84 1F 27 FB 81
         :          ED 08 32 E6 9A D4 F2 00 78 B8 FF 83 64 EA D2 1D
         :          B0 78 3C 7D FE 03 C1 F4 06 E4 3B CC 16 B9 C5 F6
         :          F6 19 37 1C 17 B8 A0 AA C7 D1 A1 94 B3 A5 36 20
         :         }
         :        }
         :       }
 140   10:      [1] {
 142    8:       OCTET STRING 2F F0 F6 D1 86 4B 32 8A
         :       }
 152   30:      SEQUENCE {
 154    6:       OBJECT IDENTIFIER id-GostR3410-2001-CryptoPro-ESDH
 162   20:       SEQUENCE {
 164    7:        OBJECT IDENTIFIER id-Gost28147-89-None-KeyWrap
 173    9:        SEQUENCE {
 175    7:         OBJECT IDENTIFIER
         :          id-Gost28147-89-CryptoPro-A-ParamSet
         :         }
         :        }
         :       }
 184  179:      SEQUENCE {
 187  176:       SEQUENCE {
 190  129:        SEQUENCE {
 193  109:         SEQUENCE {
 195   31:          SET {
 197   29:           SEQUENCE {
 199    3:            OBJECT IDENTIFIER commonName
 204   22:            UTF8String 'GostR3410-2001 example'
         :            }
         :           }
 228   18:          SET {
 230   16:           SEQUENCE {
 232    3:            OBJECT IDENTIFIER organizationName
 237    9:            UTF8String 'CryptoPro'
         :            }
         :           }
 248   11:          SET {
 250    9:           SEQUENCE {
 252    3:            OBJECT IDENTIFIER countryName
 257    2:            PrintableString 'RU'
         :            }
         :           }
 261   41:          SET {
 263   39:           SEQUENCE {
 265    9:            OBJECT IDENTIFIER emailAddress
 276   26:            IA5String 'GostR3410-2001@example.com'
         :            }
         :           }
         :          }
 304   16:         INTEGER
         :          2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21
         :         }
 322   42:        OCTET STRING, encapsulates {
 324   40:         SEQUENCE {
 326   32:          OCTET STRING
         :           16 A3 1C E7 CE 4E E9 0D F1 EC 74 69 04 68 1E C7
         :           9F 3A ED B8 3B 1F 1D 4A 7E F9 A5 D9 CB 19 D5 E8
 360    4:          OCTET STRING
         :           93 FD 86 7E
         :          }
         :         }
         :        }
         :       }
         :      }
         :     }
 366   56:    SEQUENCE {
 368    9:     OBJECT IDENTIFIER data
 379   29:     SEQUENCE {
 381    6:      OBJECT IDENTIFIER id-Gost28147-89
 389   19:      SEQUENCE {
 391    8:       OCTET STRING B7 35 E1 7A 07 35 A2 1D
 401    7:       OBJECT IDENTIFIER id-Gost28147-89-CryptoPro-A-ParamSet
         :       }
         :      }
 410   12:     [0] 39 B1 8A F4 BF A9 E2 65 25 B6 55 C9
         :     }
         :    }
         :   }
         :  }

|>GostR3410-2001-keyagree.bin
|MIIBpAYJKoZIhvcNAQcDoIIBlTCCAZECAQIxggFQoYIBTAIBA6BloWMwHAYGKoUD
|AgITMBIGByqFAwICJAAGByqFAwICHgEDQwAEQLNVOfRngZcrpcTZhB8n+4HtCDLm
|mtTyAHi4/4Nk6tIdsHg8ff4DwfQG5DvMFrnF9vYZNxwXuKCqx9GhlLOlNiChCgQI
|L/D20YZLMoowHgYGKoUDAgJgMBQGByqFAwICDQAwCQYHKoUDAgIfATCBszCBsDCB
|gTBtMR8wHQYDVQQDDBZHb3N0UjM0MTAtMjAwMSBleGFtcGxlMRIwEAYDVQQKDAlD
|cnlwdG9Qcm8xCzAJBgNVBAYTAlJVMSkwJwYJKoZIhvcNAQkBFhpHb3N0UjM0MTAt
|MjAwMUBleGFtcGxlLmNvbQIQK/XGHsIRvRfH3NRiZrQuIQQqMCgEIBajHOfOTukN
|8ex0aQRoHsefOu24Ox8dSn75pdnLGdXoBAST/YZ+MDgGCSqGSIb3DQEHATAdBgYq
|hQMCAhUwEwQItzXhegc1oh0GByqFAwICHwGADDmxivS/qeJlJbZVyQ==
|<GostR3410-2001-keyagree.bin

9.3. Упакованное с доставкой ключей сообщение

Это сообщение зашифровано с использованием примера сертификата из параграфа 4.2 [CPPK] в качестве сертификата получателя. Для расшифровки сообщения можно использовать секретный ключ d из того же параграфа.

   0  423: SEQUENCE {
   4    9:  OBJECT IDENTIFIER envelopedData
  15  408:  [0] {
  19  404:   SEQUENCE {
  23    1:    INTEGER 0
  26  339:    SET {
  30  335:     SEQUENCE {
  34    1:      INTEGER 0
  37  129:      SEQUENCE {
  40  109:       SEQUENCE {
  42   31:        SET {
  44   29:         SEQUENCE {
  46    3:          OBJECT IDENTIFIER commonName
  51   22:          UTF8String 'GostR3410-2001 example'
         :          }
         :         }
  75   18:        SET {
  77   16:         SEQUENCE {
  79    3:          OBJECT IDENTIFIER organizationName
  84    9:          UTF8String 'CryptoPro'
         :          }
         :         }
  95   11:        SET {
  97    9:         SEQUENCE {
  99    3:          OBJECT IDENTIFIER countryName
 104    2:          PrintableString 'RU'
         :          }
         :         }
 108   41:        SET {
 110   39:         SEQUENCE {
 112    9:          OBJECT IDENTIFIER emailAddress
 123   26:          IA5String 'GostR3410-2001@example.com'
         :          }
         :         }
         :        }
 151   16:       INTEGER
         :        2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21
         :       }
 169   28:      SEQUENCE {
 171    6:       OBJECT IDENTIFIER id-GostR3410-2001
 179   18:       SEQUENCE {
 181    7:        OBJECT IDENTIFIER
         :         id-GostR3410-2001-CryptoPro-XchA-ParamSet
 190    7:        OBJECT IDENTIFIER
         :         id-GostR3411-94-CryptoProParamSet
         :        }
         :       }
 199  167:      OCTET STRING, encapsulates {
 202  164:       SEQUENCE {
 205   40:        SEQUENCE {
 207   32:         OCTET STRING
         :          6A 2F A8 21 06 95 68 9F 9F E4 47 AA 9E CB 61 15
         :          2B 7E 41 60 BC 5D 8D FB F5 3D 28 1B 18 9A F9 75
 241    4:         OCTET STRING
         :          36 6D 98 B7
         :         }
 247  120:        [0] {
 249    7:         OBJECT IDENTIFIER
         :          id-Gost28147-89-CryptoPro-A-ParamSet
 258   99:         [0] {
 260   28:          SEQUENCE {
 262    6:           OBJECT IDENTIFIER id-GostR3410-2001
 270   18:           SEQUENCE {
 272    7:            OBJECT IDENTIFIER
         :             id-GostR3410-2001-CryptoPro-XchA-ParamSet
 281    7:            OBJECT IDENTIFIER
         :             id-GostR3411-94-CryptoProParamSet
         :            }
         :           }
 290   67:          BIT STRING encapsulates {
 293   64:           OCTET STRING
         :            4D 2B 2F 33 90 E6 DC A3 DD 55 2A CD DF E0 EF FB
         :            31 F7 73 7E 4E FF BF 78 89 8A 2B C3 CD 31 94 04
         :            4B 0E 60 48 96 1F DB C7 5D 12 6F DA B2 40 8A 77
         :            B5 BD EA F2 EC 34 CB 23 9F 9B 8B DD 9E 12 C0 F6
         :           }
         :          }
 359    8:         OCTET STRING
         :          97 95 E3 2C 2B AD 2B 0C
         :         }
         :        }
         :       }
         :      }
         :     }
 369   56:    SEQUENCE {
 371    9:     OBJECT IDENTIFIER data
 382   29:     SEQUENCE {
 384    6:      OBJECT IDENTIFIER id-Gost28147-89
 392   19:      SEQUENCE {
 394    8:       OCTET STRING BC 10 8B 1F 0B FF 34 29
 404    7:       OBJECT IDENTIFIER id-Gost28147-89-CryptoPro-A-ParamSet
         :       }
         :      }
 413   12:     [0] AA 8E 72 1D EE 4F B3 2E E3 0F A1 37
         :     }
         :    }
         :   }
         :  }

|>GostR3410-2001-keytrans.bin
|MIIBpwYJKoZIhvcNAQcDoIIBmDCCAZQCAQAxggFTMIIBTwIBADCBgTBtMR8wHQYD
|VQQDDBZHb3N0UjM0MTAtMjAwMSBleGFtcGxlMRIwEAYDVQQKDAlDcnlwdG9Qcm8x
|CzAJBgNVBAYTAlJVMSkwJwYJKoZIhvcNAQkBFhpHb3N0UjM0MTAtMjAwMUBleGFt
|cGxlLmNvbQIQK/XGHsIRvRfH3NRiZrQuITAcBgYqhQMCAhMwEgYHKoUDAgIkAAYH
|KoUDAgIeAQSBpzCBpDAoBCBqL6ghBpVon5/kR6qey2EVK35BYLxdjfv1PSgbGJr5
|dQQENm2Yt6B4BgcqhQMCAh8BoGMwHAYGKoUDAgITMBIGByqFAwICJAAGByqFAwIC
|HgEDQwAEQE0rLzOQ5tyj3VUqzd/g7/sx93N+Tv+/eImKK8PNMZQESw5gSJYf28dd
|Em/askCKd7W96vLsNMsjn5uL3Z4SwPYECJeV4ywrrSsMMDgGCSqGSIb3DQEHATAd
|BgYqhQMCAhUwEwQIvBCLHwv/NCkGByqFAwICHwGADKqOch3uT7Mu4w+hNw==
|<GostR3410-2001-keytrans.bin

10. Модули ASN.1

Дополнительные модули ASN.1, упомянутые здесь, можно найти в [CPALGS].

10.1. GostR3410-EncryptionSyntax

GostR3410-EncryptionSyntax
    { iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
      other(1) modules(1) gostR3410-EncryptionSyntax(5) 2 }
DEFINITIONS ::=
BEGIN
-- EXPORTS All --
-- The types and values defined in this module are exported for
-- use in the other ASN.1 modules contained within the Russian
-- Cryptography "GOST" & "GOST R" Specifications, and for the use
-- of other applications which will use them to access Russian
-- Cryptography services.  Other applications may use them for
-- their own purposes, but this will not constrain extensions and
-- modifications needed to maintain or improve the Russian
-- Cryptography service.
    IMPORTS
        id-CryptoPro-algorithms,
        gost28147-89-EncryptionSyntax,
        gostR3410-94-PKISyntax,
        gostR3410-2001-PKISyntax,
        ALGORITHM-IDENTIFIER,
        cryptographic-Gost-Useful-Definitions
        FROM Cryptographic-Gost-Useful-Definitions -- in [CPALGS]
            { iso(1) member-body(2) ru(643) rans(2)
              cryptopro(2) other(1) modules(1)
              cryptographic-Gost-Useful-Definitions(0) 1 }
        id-GostR3410-94
        FROM GostR3410-94-PKISyntax -- in [CPALGS]
            gostR3410-94-PKISyntax
        id-GostR3410-2001
        FROM GostR3410-2001-PKISyntax -- in [CPALGS]
            gostR3410-2001-PKISyntax
        Gost28147-89-ParamSet,
        Gost28147-89-EncryptedKey
        FROM Gost28147-89-EncryptionSyntax -- in [CPALGS]
             gost28147-89-EncryptionSyntax
        SubjectPublicKeyInfo
        FROM PKIX1Explicit88 {iso(1) identified-organization(3)
        dod(6) internet(1) security(5) mechanisms(5) pkix(7)
        id-mod(0) id-pkix1-explicit-88(1)}
    ;
  -- CMS/PKCS#7 key agreement algorithms & parameters
    Gost28147-89-KeyWrapParameters ::=
      SEQUENCE {
        encryptionParamSet Gost28147-89-ParamSet,
        ukm                OCTET STRING (SIZE (8)) OPTIONAL
      }
    id-Gost28147-89-CryptoPro-KeyWrap OBJECT IDENTIFIER ::=
      { id-CryptoPro-algorithms keyWrap(13) cryptoPro(1) }
    id-Gost28147-89-None-KeyWrap OBJECT IDENTIFIER ::=
      { id-CryptoPro-algorithms keyWrap(13) none(0) }
    Gost28147-89-KeyWrapAlgorithms  ALGORITHM-IDENTIFIER ::= {
      { Gost28147-89-KeyWrapParameters IDENTIFIED BY
        id-Gost28147-89-CryptoPro-KeyWrap } |
      { Gost28147-89-KeyWrapParameters IDENTIFIED BY
        id-Gost28147-89-None-KeyWrap }
    }
    id-GostR3410-2001-CryptoPro-ESDH OBJECT IDENTIFIER ::=
      { id-CryptoPro-algorithms
        gostR3410-2001-CryptoPro-ESDH(96) }
    id-GostR3410-94-CryptoPro-ESDH OBJECT IDENTIFIER ::=
      { id-CryptoPro-algorithms
        gostR3410-94-CryptoPro-ESDH(97) }
  -- CMS/PKCS#7 key transport algorithms & parameters
    -- OID for CMS/PKCS#7 Key transport is id-GostR3410-94 from
    --      GostR3410-94-PKISyntax or id-GostR3410-2001 from
    --      GostR3410-2001-PKISyntax
    -- Algorithms for CMS/PKCS#7 Key transport are
    --      GostR3410-94-PublicKeyAlgorithms from
    --      GostR3410-94-PKISyntax or
    --      GostR3410-2001-PublicKeyAlgorithms from
    --      GostR3410-2001-PKISyntax
    -- SMIMECapability for CMS/PKCS#7 Key transport are
    --      id-GostR3410-94 from GostR3410-94-PKISyntax or
    --      id-GostR3410-2001 from GostR3410-2001-PKISyntax
    id-GostR3410-94-KeyTransportSMIMECapability
        OBJECT IDENTIFIER ::= id-GostR3410-94
    id-GostR3410-2001-KeyTransportSMIMECapability
        OBJECT IDENTIFIER ::= id-GostR3410-2001
    GostR3410-KeyTransport ::=
        SEQUENCE {
            sessionEncryptedKey Gost28147-89-EncryptedKey,
            transportParameters [0]
                IMPLICIT GostR3410-TransportParameters OPTIONAL
        }
    GostR3410-TransportParameters ::=
        SEQUENCE {
            encryptionParamSet Gost28147-89-ParamSet,
            ephemeralPublicKey [0]
                IMPLICIT SubjectPublicKeyInfo OPTIONAL,
            ukm                OCTET STRING ( SIZE(8) )
        }
END -- GostR3410-EncryptionSyntax

10.2. GostR3410-94-SignatureSyntax

GostR3410-94-SignatureSyntax
    { iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
      other(1) modules(1) gostR3410-94-SignatureSyntax(3) 1 }
DEFINITIONS ::=
BEGIN
-- EXPORTS All --
-- The types and values defined in this module are exported for
-- use in the other ASN.1 modules contained within the Russian
-- Cryptography "GOST" & "GOST R" Specifications, and for the use
-- of other applications which will use them to access Russian
-- Cryptography services.  Other applications may use them for
-- their own purposes, but this will not constrain extensions and
-- modifications needed to maintain or improve the Russian
-- Cryptography service.
    IMPORTS
        gostR3410-94-PKISyntax, ALGORITHM-IDENTIFIER,
        cryptographic-Gost-Useful-Definitions
        FROM Cryptographic-Gost-Useful-Definitions -- in [CPALGS]
            { iso(1) member-body(2) ru(643) rans(2)
              cryptopro(2) other(1) modules(1)
              cryptographic-Gost-Useful-Definitions(0) 1 }
        id-GostR3410-94,
        GostR3410-94-PublicKeyParameters
        FROM GostR3410-94-PKISyntax -- in [CPALGS]
            gostR3410-94-PKISyntax
    ;
  -- GOST R 34.10-94 signature data type
    GostR3410-94-Signature ::=
        OCTET STRING (SIZE (64))
  -- GOST R 34.10-94 signature algorithm & parameters
    GostR3410-94-CMSSignatureAlgorithms  ALGORITHM-IDENTIFIER ::= {
        { GostR3410-94-PublicKeyParameters IDENTIFIED BY
                        id-GostR3410-94 }
    }
END -- GostR3410-94-SignatureSyntax

10.3. GostR3410-2001-SignatureSyntax

GostR3410-2001-SignatureSyntax
    { iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
      other(1) modules(1) gostR3410-2001-SignatureSyntax(10) 1 }
DEFINITIONS ::=
BEGIN
-- EXPORTS All --
-- The types and values defined in this module are exported for
-- use in the other ASN.1 modules contained within the Russian
-- Cryptography "GOST" & "GOST R" Specifications, and for the use
-- of other applications which will use them to access Russian
-- Cryptography services. Other applications may use them for
-- their own purposes, but this will not constrain extensions and
-- modifications needed to maintain or improve the Russian
-- Cryptography service.
    IMPORTS
        gostR3410-2001-PKISyntax, ALGORITHM-IDENTIFIER,
        cryptographic-Gost-Useful-Definitions
        FROM Cryptographic-Gost-Useful-Definitions -- in [CPALGS]
            { iso(1) member-body(2) ru(643) rans(2)
              cryptopro(2) other(1) modules(1)
              cryptographic-Gost-Useful-Definitions(0) 1 }
        id-GostR3410-2001,
        GostR3410-2001-PublicKeyParameters -- in [CPALGS]
        FROM GostR3410-2001-PKISyntax
            gostR3410-2001-PKISyntax
    ;
  -- GOST R 34.10-2001 signature data type
    GostR3410-2001-Signature ::=
        OCTET STRING (SIZE (64))
  -- GOST R 34.10-2001 signature algorithms and parameters
    GostR3410-2001-CMSSignatureAlgorithms

        ALGORITHM-IDENTIFIER ::= {
                { GostR3410-2001-PublicKeyParameters IDENTIFIED BY
                        id-GostR3410-2001 }
        }
END -- GostR3410-2001-SignatureSyntax

11. Благодарности

Этот документ был подготовлен в соответствии с «Соглашением о совместимости СКЗИ», подписанным ФГУП НТЦ «Атлас», ООО «КРИПТО-ПРО», ООО «Фактор-ТС», ЗАО «МО ПНИЭИ», ООО «Инфотекс», ЗАО «СПбРЦЗИ», ООО «Криптоком», ООО «Р-Альфа». Целью этого соглашения является обеспечение взаимной совместимости продукции и решений.

Авторы выражают свою признательность

представительству компании Microsoft в России за предоставление информации о продукции и решениях компании, а также технические консультации в части PKI;

представительству RSA Security в России и компании «Демос» за активное сотрудничество и неоценимую помощь в создании этого документа;

Russ Housley (Vigil Security, LLC, housley@vigilsec.com) и Василию Сахарову (DEMOS Co Ltd, svp@dol.ru) за поощрение авторов к созданию этого документа;

Дмитрию Приходько (VSTU, PrikhodkoDV@volgablob.ru) за неоценимую помощь в корректуре этого документа т проверку формы и содержания структур ASN.1 упомянутых и использованных в этом документе.

12. Литература

12.1. Нормативные документы

[CMS] Housley, R., «Cryptographic Message Syntax (CMS)», RFC 3852, July 2004.

[CPALGS] Popov, V., Kurepkin, I., and S. Leontiev, «Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms», RFC 4357, January 2006.

[CPPK] Leontiev, S., Ed. and D. Shefanovskij, Ed., «Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile», RFC 4491, May 2006.

[GOST28147] «Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования. ГОСТ 28147-89″, Государственный стандарт СССР, Государственный комитет СССР по стандартизации, 1989. (на русском языке)

[GOST3431195] «Информационная технология. Криптографическая защита информации. Функция хэширования.», ГОСТ 34.311-95, Межгосударственный совет по стандартизации, метрологии и сертификации (МГС), Минск, 1995. (на русском языке)

[GOST3431095] «Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма.», ГОСТ 34.310-95, Межгосударственный совет по стандартизации, метрологии и сертификации (МГС), Минск, 1995. (на русском языке)

[GOST3431004] «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи.»2, ГОСТ 34.310-2004, Межгосударственный совет по стандартизации, метрологии и сертификации (МГС), Минск, 2004. (на русском языке)

[GOSTR341094] «Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма.», ГОСТ Р 34.10-94, Государственный стандарт Российской Федерации, Госстандарт России, 1994. (на русском языке)

[GOSTR341001] «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи.», ГОСТ Р 34.10-2001, Государственный стандарт Российской Федерации, Госстандарт России, 2001. (на русском языке)

[GOSTR341194] «Информационная технология. Криптографическая защита информации. Функция хэширования.», ГОСТ Р 34.11-943, Государственный стандарт Российской Федерации, Госстандарт России, 1994. (на русском языке)

[PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 3280, April 2002.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC3851] Ramsdell, B., «Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification», RFC 3851, July 2004.

[X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.

[X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.

12.2. Дополнительная литература

[CRYPTOLIC] «Положение о лицензировании деятельности по распространению шифровальных (криптографических) средств», Постановление Правительства РФ от 23.09.2002, N 6914.

[RFC4134] Hoffman, P., «Examples of S/MIME Messages», RFC 4134, July 2005.

[RFEDSL] Федеральный закон «Об электронной цифровой подписи» от 10.01.2002 N 1-ФЗ5

[RFLLIC] Федеральный закон «О лицензировании отдельных видов деятельности» от 08.08.2001 г. N 128-ФЗ

[Schneier95] B. Schneier, Applied Cryptography, Second Edition, John Wiley & Sons, Inc., 1995.


Адреса авторов

Сергей Леонтьев, редактор

CRYPTO-PRO

38, Obraztsova,

Moscow, 127018, Russian Federation

EMail: lse@cryptopro.ru

Григорий Чудов, редактор

CRYPTO-PRO

38, Obraztsova,

Moscow, 127018, Russian Federation

EMail: chudov@cryptopro.ru

Владимир Попов

CRYPTO-PRO

38, Obraztsova,

Moscow, 127018, Russian Federation

EMail: vpopov@cryptopro.ru

Александр Афанасьев

Factor-TS

office 711, 14, Presnenskij val,

Moscow, 123557, Russian Federation

EMail: afa1@factor-ts.ru

Николай Никишин

Infotecs GmbH

p/b 35, 80-5, Leningradskij prospekt,

Moscow, 125315, Russian Federation

EMail: nikishin@infotecs.ru

Болеслав Изотов

FGUE STC «Atlas»

38, Obraztsova,

Moscow, 127018, Russian Federation

EMail: izotov@nii.voskhod.ru

Елена Минаева

MD PREI

build 3, 6A, Vtoroj Troitskij per.,

Moscow, Russian Federation

EMail: evminaeva@mail.ru

Игорь Овчаренок

MD PREI

Office 600, 14, B.Novodmitrovskaya,

Moscow, Russian Federation

EMail: igori@mo.msk.ru

Сергей Муругов

R-Alpha

4/1, Raspletina,

Moscow, 123060, Russian Federation

EMail: msm@top-cross.ru

Игорь Устинов

Cryptocom

office 239, 51, Leninskij prospekt,

Moscow, 119991, Russian Federation

EMail: igus@cryptocom.ru

Анатолий Еркин

SPRCIS (SPbRCZI)

1, Obrucheva,

St.Petersburg, 195220, Russian Federation

EMail: erkin@nevsky.net


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).


1Message authentication code.

2Название стандарта на английском языке в оригинале указано неверно (см. https://www.rfc-editor.org/errata/eid5099). Прим. перев.

3В оригинале ошибочно указано GOST R 31.10-94 (см. https://www.rfc-editor.org/errata/eid5089). Прим. перев.

4В соответствии с Постановлением Правительства РФ от 29 декабря 2007 г. N 957 данный документ утратил силу. Прим. перев.

5В соответствии с Федеральным законом от 6 апреля 2011 г. N 63-ФЗ утратил силу с 01.07.2013 г. Прим. перев.