Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
2576 lines (1936 sloc) 173 KB

СТБ 34.101.23-2012

Информационные технологии и безопасность

СИНТАКСИС КРИПТОГРАФИЧЕСКИХ СООБЩЕНИЙ

Інфармацыйныя тэхналогіі і бяспека

СІНТАКСІС КРЫПТАГРАФІЧНЫХ ПАВЕДАМЛЕННЯЎ

Information technology and security

Cryptographic message syntax


Содержание

1 Область применения

2 Нормативные ссылки

3 Термины и определения

4 Обозначения и сокращения

5 Общие положения

6 Типы данных

7 Неструктурированные данные

8 Подписанные данные

8.1 Общее описание

8.2 Тип SignedData

8.3 Тип EncapsulatedContentInfo

8.4 Тип SignerInfo

8.5 Хэширование

8.6 Выработка ЭЦП

8.7 Проверка ЭЦП

9 Конвертованные данные

9.1 Общее описание

9.2 Тип EnvelopedData

9.3 Тип RecipientInfo

9.4 Тип KeyTransRecipientInfo

9.5 Процесс шифрования данных

9.6 Процесс шифрования ключей

10 Хэшированные данные

10.1 Общее описание

10.2 Тип DigestedData

11 Шифрованные данные

11.1 Общее описание

11.2 Тип EncryptedData

12 Аутентифицируемые данные

12.1 Общее описание

12.2 Тип AuthenticatedData

12.3 Вычисление имитовставки

12.4 Проверка имитовставки

13 Аутентифицируемые конвертованные данные

13.1 Общее описание

13.2 Тип AuthEnvelopedData

13.3 Шифрование и имитозащита

13.4 Шифрование ключей

14 Вспомогательные типы

14.1 Тип AlgorithmIdentifier и связанные типы

14.2 Тип RevocationInfoChoices

14.3 Тип CertificateChoices

14.4 Тип CertificateSet

14.5 Тип IssuerAndSerialNumber

14.6 Тип CMSVersion

14.7 Тип UserKeyingMaterial

14.8 Тип OtherKeyAttribute

15 Атрибуты

15.1 Общее описание

15.2 Тип содержимого

15.3 Хэш-значение

15.4 Время подписания

15.5 Контрподпись

Приложение А (обязательное) Модули АСН.1

Приложение Б (рекомендуемое) Использование криптографических алгоритмов в CMS

Библиография

1 Область применения

Настоящий стандарт устанавливает синтаксис криптографических сообщений, которые используются для обеспечения конфиденциальности, контроля целостности и подлинности данных при их передаче и хранении. Стандарт определяет форматы криптографических сообщений, правила создания и обработки сообщений. При описании форматов используется абстрактно-синтаксическая нотация версии 1 (далее – АСН.1).

Настоящий стандарт применяется при разработке, испытаниях и эксплуатации средств криптографической защиты информации.

2 Нормативные ссылки

В настоящем стандарте использованы ссылки на следующие технические нормативные правовые акты в области технического нормирования и стандартизации (далее – ТНПА):

СТБ 1176.1-99 Информационная технология. Защита информации. Функция хэширования

СТБ 1176.2-99 Информационная технология. Защита информации. Процедуры выработки и проверки электронной цифровой подписи

СТБ 34.101.19-2012 Информационная технологии и безопасность. Форматы сертификатов и списков отозванных сертификатов инфраструктуры открытых ключей

СТБ 34.101.26-2012 Информационная технологии и безопасность. Онлайновый протокол проверки статуса сертификата (OCSP)

СТБ 34.101.31-2011 Информационные технологии. Защита информации. Криптографические алгоритмы шифрования и контроля целостности

СТБ П 34.101.45-2011 Информационные технологии и безопасность. Алгоритмы электронной цифровой подписи на основе эллиптических кривых

СТБ П 34.101.50-2012 Информационные технологии и безопасность. Правила регистрации объектов информационных технологий

ГОСТ ИСО 8601-2001 Система стандартов по информации, библиотечному и издательскому делу. Представление дат и времени. Общие требования

ГОСТ 28147-89 Система обработки информации. Защита криптографическая. Алгоритм криптографического преобразования

ГОСТ 34.973-91 (ИСО 8824-87) Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактно-синтаксической нотации версии 1 (АСН.1)

ГОСТ 34.974-91 (ИСО 8825-87) Информационная технология. Взаимосвязь открытых систем. Описание базовых правил кодирования для абстрактно-синтаксической нотации версии 1 (АСН.1)

Примечание – При пользовании настоящим стандартом целесообразно проверить действие ТНПА по каталогу, составленному по состоянию на 1 января текущего года, и по соответствующим информационным указателям, опубликованным в текущем году.

Если ссылочные ТНПА заменены (изменены), то при пользовании настоящим стандартом следует руководствоваться замененными (измененными) ТНПА. Если ссылочные ТНПА отменены без замены, то положение, в котором дана ссылка на них, применяется в части, не затрагивающей эту ссылку.

3 Термины и определения

В настоящем стандарте применяют термины, установленные в СТБ 34.101.19, СТБ 34.101.31, ГОСТ 34.973, ГОСТ 34.974, а также следующие термины с соответствующими определениями:

3.1 атрибутный сертификат: Подписанная доверенной стороной структура данных, которая связывает определенные атрибуты с идентификационной информацией об их владельце. Формат структуры определен в [1] (версия 1) и [2] (версия 2).

3.2 аутентифицируемые данные (authenticated data): Структура данных синтаксиса криптографических сообщений, предназначенная для контроля целостности и подлинности вложенных данных с помощью алгоритмов имитозащиты и алгоритмов защиты ключей имитозащиты.

3.3 аутентифицируемые конвертованные данные (authenticated enveloped data): Структура данных синтаксиса криптографических сообщений, предназначенная для обеспечения конфиденциальности, контроля целостности и подлинности вложенных данных с помощью алгоритмов шифрования и имитозащиты и алгоритмов защиты ключей шифрования и имитозащиты.

3.4 базовые правила кодирования (basic encoded rules): Правила кодирования значений типов АСН.1, заданные в ГОСТ 34.974.

3.5 конвертованные данные (enveloped data): Структура данных синтаксиса криптографических сообщений, предназначенная для обеспечения конфиденциальности вложенных данных с помощью алгоритмов шифрования и алгоритмов защиты ключей шифрования.

3.6 контрподпись (countersignature): Электронная цифровая подпись, удостоверяющая другую подпись.

3.7 отличительные правила кодирования (distinguished encoded rules): Базовые правила кодирования с уточнениями, описанными в СТБ 34.101.19 (приложение Б).

3.8 синтаксис криптографических сообщений; CMS (cryptographic message syntax): Набор соглашений о форматах сообщений (структур данных), которые получаются в результате применения криптографических алгоритмов обеспечения конфиденциальности, контроля целостности и подлинности.

3.9 подписанные данные (signed data): Структура данных синтаксиса криптографических сообщений, предназначенная для контроля целостности и подлинности вложенных данных с помощью алгоритмов электронной цифровой подписи.

3.10 удостоверяющий центр; УЦ (certification authority; CA): Поставщик услуг издания, распространения, хранения сертификатов открытых ключей и списков отозванных сертификатов открытых ключей

3.11 шифрованные данные (encrypted data): Структура данных синтаксиса криптографических сообщений, предназначенная для обеспечения конфиденциальности вложенных данных с помощью алгоритмов шифрования.

3.12 хэшированные данные (digested data): Структура данных синтаксиса криптографических сообщений, предназначенная для контроля целостности вложенных данных с помощью алгоритмов хэширования.

4 Обозначения и сокращения

В настоящем стандарте применяют следующие сокращения:

ЭЦП – электронная цифровая подпись.

Для определения типов АСН.1, применяют обозначения, заданные в ГОСТ 34.973.

Ключевое слово «ДОЛЖЕН» означает, что действия, к которым применены данные ключевые слова, необходимо в точности выполнять. Ключевое слово «НЕ ДОЛЖЕН» выражает абсолютный запрет на выполнение соответствующих действий. Ключевые слова «СЛЕДУЕТ» и «РЕКОМЕНДУЕТСЯ» необходимо понимать так, что в некоторых случаях существует реальная причина их игнорировать, но последствия таких действий должны быть очевидными и хорошо взвешенными. Ключевое слово «НЕ СЛЕДУЕТ» применяется в тех случаях, когда действие, к которому применено данное ключевое слово, будет в некоторых случаях правильным и даже полезным, однако при этом его последствия должны быть очевидными и хорошо взвешенными. Ключевое слово «МОЖЕТ» применяется к действиям (предметам), выполнение или не выполнение (наличие или отсутствие) которых не влияет на ситуацию в целом. Это означает, что программы, работающие с чем-то, помеченным данными ключевыми словами, должны учитывать обе ситуации и корректно их обрабатывать.

5 Общие положения

Настоящий стандарт определяет синтаксис криптографических сообщений, которые получаются в результате применения алгоритмов ЭЦП, хэширования, имитозащиты и шифрования к произвольным данным. Стандарт основан на [2] и его расширениях [3], [4].

Определяемый синтаксис базируется на инкапсуляции – вложении одной структуры данных в другую. CMS допускает многократную вложенность: один контейнер, содержащий вложенные данные, может быть частью другого контейнера. Например, стороны могут подписывать ранее инкапсулированные данные, которые уже содержат ЭЦП. CMS позволяет подписывать произвольные атрибуты, например текущее время, вместе с обрабатываемым сообщением и добавлять другие атрибуты, например контрподписи, к выработанной ЭЦП.

CMS поддерживает различные инфраструктуры открытых ключей, в том числе инфраструктуру, заданную в СТБ 34.101.19 и основанную на сертификатах открытых ключей.

Значения типов CMS определяются с помощью базовых правил кодирования АСН.1. Результатом кодирования является строка октетов. Большинство коммуникационных систем имеют средства надежной передачи строк октетов. Тем не менее, известны системы, в которых такие средства отсутствуют. Настоящий стандарт не определяет правила дополнительного кодирования строк октетов для их надежной передачи в произвольных средах.

6 Типы данных

CMS позволяет описывать данные многих типов. Тип данных задается специальным идентификатором. CMS связывает идентификатор с самими данными. Для этого ДОЛЖЕН использоваться криптографический контейнер, формат которого определяется типом ContentInfo АСН.1:

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

ContentType ::= OBJECT IDENTIFIER

Компоненты ContentInfo имеют следующее значение:

  • contentType определяет тип данных контейнера. Это идентификатор объекта АСН.1 – уникальная последовательность целых чисел. Идентификатор задает сторона, которая ввела тип.

  • content определяет данные контейнера. Тип данных однозначно определяется компонентом contentType. Данные также могут являться контейнером и инкапсулировать другие данные.

Настоящий стандарт определяет семь типов данных: неструктурированные данные, подписанные данные, конвертованные данные, хэшированные данные, шифрованные данные, аутентифицируемые данные и аутентифицируемые конвертованные данные.

Дополнительные типы данных могут быть определены в других ТНПА, основанных на настоящем стандарте. При этом дополнительные типы ДОЛЖНЫ быть отличны от CHOICE.

Реализации, которые претендуют на соответствие настоящему стандарту, ДОЛЖНЫ поддерживать контейнер ContentInfo и неструктурированные, подписанные и конвертованные данные. МОГУТ поддерживаться и остальные типы.

CMS спроектирован так, что данные каждого из его типов могут быть обработаны за один проход при применении базовых правил кодирования данных и представлении длины данных в неявной форме – через признак конца содержимого (подробнее см. ГОСТ 34.974, пункт 6.3.4). Обработка за один проход особенно важна при работе с данными большого объема, которые хранятся на магнитных лентах или принимаются от других процессов операционной системы. Однопроходная обработка обладает недостатком, который заключается в трудности организации кодирования с помощью отличительных правил, так как при таком кодировании требуется заранее знать длину различных компонентов обрабатываемых данных. Применение отличительных правил необходимо при передаче атрибутов подписанных и аутентифицируемых данных, так как получатель соответствующих контейнеров должен быть уверен в получении всех (заранее, возможно, не оговоренных) атрибутов. Атрибуты подписанных и аутентифицируемых данных – это единственные структуры данных CMS, для кодирования которых требуется применять отличительные правила.

7 Неструктурированные данные

Неструктурированные данные – это произвольные строки октетов, например текстовые сообщения, интерпретация которых зависит от конкретного применения. Такие строки не обязательно имеют внутреннюю структуру, хотя структура может быть, и она может описываться, например, с помощью АСН.1.

Тип неструктурированных данных задается следующим идентификатором:

id-data OBJECT IDENTIFIER ::=
  {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1}

8 Подписанные данные

8.1 Общее описание

Подписанные данные – это произвольные данные, дополненные несколькими ЭЦП, выработанными одной или несколькими сторонами. Отсутствие ЭЦП не считается ошибкой.

Тип подписанных данных задается следующим идентификатором:

id-signedData OBJECT IDENTIFIER ::=
  {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2}

Как правило, данные типа id-signedData включают одну ЭЦП неструктурированных данных. Типичными примерами использования этого типа являются сертификаты и списки отозванных сертификатов согласно СТБ 34.101.19.

Процесс формирования подписанных данных включает следующие шаги:

  1. Каждая из подписывающих сторон вычисляет хэш-значение подписываемых данных с помощью алгоритма хэширования, выбираемого самой стороной. Если стороне требуется подписать дополнительные данные, то полученное хэш-значение дополняется этими данными и повторно хэшируется с помощью выбранного алгоритма (см. 8.5. Результат хэширования объявляется окончательным хэш-значением и используется впоследствии.

  2. Каждая из подписывающих сторон вырабатывает ЭЦП от полученного хэш-значения. Для выработки ЭЦП используется личный ключ стороны.

  3. Каждая из подписывающих сторон формирует структуру данных типа SignerInfo, которая содержит полученную ЭЦП и другие связанные с выработкой ЭЦП данные (см. 8.4). На этом же шаге собираются сертификаты и списки отозванных сертификатов, относящиеся к подписывающей стороне или общие.

  4. Формируется структура данных SignedData, которая включает данные типа SignerInfo и описание использованных алгоритмов хэширования каждой из подписывающих сторон (см. 8.2).

Получатель независимо вычисляет хэш-значения для всех перечисленных алгоритмов хэширования. Хэш-значение и открытый ключ подписавшейся стороны используются для проверки ЭЦП. Открытый ключ может определяться двумя способами. Во-первых, определение открытого ключа может осуществляться по ссылке на сертификат, в котором он содержится. Ссылка состоит из уникального имени эмитента сертификата и номера сертификата, заданного эмитентом. Во-вторых, открытый ключ может быть определен по своему идентификатору. Такой идентификатор может указывать на открытые ключи, которые распространяются как в виде сертификатов, так и в другой форме.

Сертификат подписывающей стороны может быть задан в компоненте certificates типа SignedData, хотя это не является необходимым условием.

Если имеется несколько ЭЦП одной стороны, то, как правило, корректность некоторой из них означает, что сторона действительно подписала данные. Однако могут существовать приложения CMS, в которых действуют другие правила интерпретации корректности одной из нескольких ЭЦП. Данные правила должны быть документированы в этих приложениях. Кроме того, если проверки идентификатора подписавшейся стороны недостаточно для принятия решения о том, что несколько подписей выработано одной стороной, то должно быть документировано, как определить принадлежность ЭЦП той или иной стороне. Несколько ЭЦП одной стороны используются, как правило, для поддержки различных групп получателей. Например, данные типа id-signedData могут включать как подпись СТБ 1176.2, так и подпись СТБ П 34.101.45. Это позволяет получателям проверять подписанные данные с помощью того или иного алгоритма.

В следующих трех подразделах описываются типы SignedData, EncapsulatedContentInfo и SignerInfo АСН.1, которые определяют формат подписанных данных. В 8.5, 8.6, 8.7 описываются процессы хэширования, выработки и проверки ЭЦП.

8.2 Тип SignedData

Формат подписанных данных определяется следующими типами АСН.1:

SignedData ::= SEQUENCE {
  version CMSVersion,
  digestAlgorithms DigestAlgorithmIdentifiers,
  encapContentInfo EncapsulatedContentInfo,
  certificates [0] IMPLICIT CertificateSet OPTIONAL,
  crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
  signerInfos SignerInfos}

DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

SignerInfos ::= SET OF SignerInfo

Компоненты SignedData имеют следующее значение:

  • version определяет номер версии применяемого синтаксиса. Номер версии ДОЛЖЕН определяться путем последовательной проверки следующих условий, вплоть до первого выполненного:
Условие Версия
Включен компонент ceritificates, и он содержит сертификаты различных типов (например, в ceritificates содержатся как сертификаты открытых ключей, так и атрибутные сертификаты) 5
Включен компонент clsr, и он содержит списки отозванных сертификатов различных типов 5
Включен компонент ceritificates, и он содержит атрибутный сертификат версии 2 4
Включен компонент ceritificates, и он содержит атрибутный сертификат версии 1 3
Компонент signerInfos содержит структуру типа SignerInfo версии 3 3
Значение компонента eContentType, вложенного в encapContentInfo, отличается от id-data 3
В остальных случаях 1
  • digestAlgorithms определяет список использованных алгоритмов хэширования. Список МОЖЕТ содержать любое количество элементов или быть пустым. Каждый элемент списка определяет идентификатор алгоритма хэширования и, при необходимости, параметры алгоритма. Каждый алгоритм может использоваться одной или несколькими подписывающими сторонами. В списке задаются все алгоритмы, использованные этими сторонами, что позволяет обработать данные за один проход при проверке ЭЦП. Реализации МОГУТ не поддерживать проверку ЭЦП, если при такой проверке требуется использовать алгоритм хэширования, не включенный в список. Процесс хэширования описан в 8.5.

  • encapContentInfo определяет подписываемые данные. Данные описываются типом EncapsulatedContentInfo и представляют собой контейнер, который содержит идентификатор типа данных и собственно содержимое. Тип EncapsulatedContentInfo подробно описан в 8.3.

  • certificates определяет список сертификатов. Список предназначен для построения маршрутов сертификации от точек доверия (корневых удостоверяющих центров) ко всем подписывающим сторонам, перечисленным в компоненте signerInfos. В списке может быть больше сертификатов, чем действительно необходимо. Например, список может определять маршруты сертификации для двух и более точек доверия. В списке также может быть меньше сертификатов, чем необходимо. При этом предполагается, что получатель имеет дополнительные возможности получения недостающих сертификатов, например, из предыдущих списков сертификатов. В список МОЖЕТ быть включен сертификат подписывающей стороны. Использование атрибутных сертификатов версии 1 нежелательно.

  • crls является набором данных о статусе отзыва. Предполагается, что набор содержит достаточно информации для вывода о том, что сертификаты компонента certificates действительны, хотя данное предположение не является необходимым. Списки отозванных сертификатов являются основным источником информации о статусе отзыва. МОЖЕТ быть задано больше списков, чем действительно необходимо, хотя информации из списков МОЖЕТ быть и недостаточно.

  • signerInfos представляет собой список данных, связанных с подписывающими сторонами. Список МОЖЕТ содержать любое количество элементов или быть пустым. Если список содержит несколько ЭЦП, то корректность одной из подписей определенной стороны следует трактовать как то, что сторона действительно подписала данные. Однако могут существовать приложения CMS, в которых действуют другие правила (см. 8.1).

Описание типа SignerInfo приведено в 8.4.

Подписывающие стороны могут применять различные технологии ЭЦП, синтаксис может со временем изменяться. Поэтому реализации CMS ДОЛЖНЫ корректно обрабатывать неподдерживаемые прямо версии SignerInfo. Не обязательно реализовывать все допустимые алгоритмы ЭЦП. Тем не менее, нереализованные алгоритмы, которые встречаются при обработке данных, ДОЛЖНЫ корректно обрабатываться.

8.3 Тип EncapsulatedContentInfo

Формат инкапсулированных данных определяется следующими типами АСН.1:

EncapsulatedContentInfo ::= SEQUENCE {
  eContentType ContentType,
  eContent [0] EXPLICIT OCTET STRING OPTIONAL}

ContentType ::= OBJECT IDENTIFIER

Компоненты EncapsulatedContentInfo имеют следующее значение:

  • eContentType определяет тип данных.

  • eContent определяет собственно данные, закодированные строкой октетов. Использование при кодировании отличительных правил не является обязательным.

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

В вырожденном случае, когда ЭЦП отсутствуют, «подписываемое» значение EncapsulatedContentInfo является несущественным. В этом случае «подписываемые» данные должны иметь тип id-data (см. раздел 7), а компонент eContent ДОЛЖЕН быть опущен.

8.4 Тип SignerInfo

Информация о подписывающей стороне описывается следующими типами АСН.1:

SignerInfo ::= SEQUENCE {
  version CMSVersion,
  sid SignerIdentifier,
  digestAlgorithm DigestAlgorithmIdentifier,
  signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
  signatureAlgorithm SignatureAlgorithmIdentifier,
  signature SignatureValue,
  unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL}

SignerIdentifier ::= CHOICE {
  issuerAndSerialNumber IssuerAndSerialNumber,
  subjectKeyIdentifier [0] SubjectKeyIdentifier}

SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

Attribute ::= SEQUENCE {
  attrType OBJECT IDENTIFIER,
  attrValues SET OF AttributeValue}

AttributeValue ::= ANY

SignatureValue ::= OCTET STRING

Компоненты типа SignerInfo имеют следующее значение:

  • version определяет номер версии применяемого синтаксиса. Если в SignerIdentifier выбран компонент issuerAndSerialNumber, то значение version ДОЛЖНО равняться 1. Если в SignerIdentifier выбран компонент subjectKeyIdentifier, то значение version ДОЛЖНО равняться 3.

  • sid определяет ссылку на сертификат подписывающей стороны, в том числе ссылку на открытый ключ стороны. Открытый ключ нужен получателям для проверки ЭЦП. Тип SignerIdentifier позволяет задать ссылку двумя способами. При выборе компонента issuerAndSerialNumber задается уникальное имя эмитента сертификата и номер сертификата. При выборе компонента subjectKeyIdentifier задается идентификатор открытого ключа. При этом если ключ размещается в сертификате СТБ 34.101.19, то его идентификатор должен совпадать со значением расширения SubjectKeyIdentifier (см. СТБ 34.101.19, подпункт 6.2.1.2). При ссылках на сертификаты других форматов документация по форматам и использованию сертификатов в CMS должна определять соответствие между идентификатором открытого ключа и определенным компонентом сертификата. Реализации ДОЛЖНЫ поддерживать обработку обоих компонентов issuerAndSerialNumber и subjectKeyIdentifier типа SignerIdentifier. При формировании значений SignerIdentifier реализации МОГУТ использовать только один из компонентов, или реализации МОГУТ использовать то один, то второй компонент. Однако при ссылках на сертификаты, не соответствующие СТБ 34.101.19, ДОЛЖЕН использоваться компонент subjectKeyIdentifier.

  • digestAlgorithm определяет идентификатор и параметры алгоритма хэширования, используемого при выработке и проверке ЭЦП. Алгоритм хэширования применяется к подписываемым данным, возможно, дополненным подписываемыми атрибутами. Хэширование подробно описано в 8.5. Используемый алгоритм хэширования СЛЕДУЕТ включить в список, определяемый компонентом digestAlgorithms типа SignedData. Реализации МОГУТ не поддерживать проверку ЭЦП в тех случаях, когда используемый алгоритм хэширования не включен в этот список.

  • signedAttrs определяет подписываемые атрибуты. Хотя компонент является не обязательным, он ДОЛЖЕН присутствовать, если тип содержимого подписываемого контейнера EncapsulatedContentInfo отличается от id-data. Значения компонента signedAttrs ДОЛЖНЫ кодироваться с помощью отличительных правил, даже если эти правила не применяются к другим компонентам типа SignerInfo. В разделе 15 описаны некоторые распространенные атрибуты, например «время подписания». При использовании компонента signedAttrs он ДОЛЖЕН содержать атрибуты «тип содержимого» и «хэш-значение», которые задают тип содержимого подписываемого контейнера EncapsulatedContentInfo и хэш-значение подписываемых данных соответственно (см. 15.2 и 15.3). Однако атрибут «тип содержимого» НЕ ДОЛЖЕН применяться для неподписываемого атрибута «контрподпись» (см. 15.5).

  • signatureAlgorithm определяет алгоритм, используемый для выработки ЭЦП, и параметры алгоритма.

  • signature определяет ЭЦП хэш-значения, выработанную на личном ключе подписывающей стороны. Значение компонента определяется с помощью выбранного алгоритма выработки ЭЦП.

  • unsignedAttrs определяет неподписываемые (не учитываемые в ЭЦП) атрибуты. Компонент является необязательным. В разделе 15 описаны некоторые распространенные атрибуты, например «контрподпись».

Типы SignedAttributes и UnsignedAttributes компонентов signedAttrs и unsignedAttrs описывают наборы значений типа Attribute. Тип Attribute описан в 15.1.

8.5 Хэширование

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

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

Окончательное хэш-значение определяется в зависимости от включения компонента signedAttrs типа SignerInfo. Если компонент опущен, то окончательное хэш-значение определяется, как описано выше. Если же компонент включен, то хэшируется полное кодовое представление signedAttrs, полученное с помощью отличительных правил, и вычисленное хэш-значение объявляется окончательным. При включении компонента signedAttrs он должен содержать атрибуты «тип содержимого» и «хэш-значение» (см. 15.2 и 15.3). Поэтому значения данных атрибутов, т.е. тип и хэш-значение подписываемых данных, неявно учитываются в окончательном хэш-значении. Атрибут «тип содержимого» НЕ ДОЛЖЕН использоваться в неподписываемом атрибуте «контрподпись», как объяснено в подразделе 15.5.

Компонент signedAttrs должен кодироваться для хэширования как отдельное от SignerInfo значение типа SET OF Atrribute. Это значит, что при кодировании тег IMPLICIT [0] ДОЛЖЕН быть заменен на тег SET OF. Таким образом, хэшированию подвергается октет тега SET OF, дополненный октетами длины и содержимого кодового представления signedAttrs.

Если компонент signedAttrs опущен, то только октеты содержимого кодового представления компонента eContent (например, содержимое файла) являются входными данными алгоритма хэширования. Следует отметить, что при этом объем подписываемых данных может быть заранее неизвестен.

8.6 Выработка ЭЦП

При выработке ЭЦП используются хэш-значение подписываемых данных и личный ключ подписывающей стороны. Детали выработки подписи определяются особенностями используемых алгоритмов ЭЦП. Идентификатор алгоритма выработки ЭЦП, а также параметры алгоритма, используемые подписывающей стороной, задаются в компоненте signatureAlgorithm типа SignerInfo. Выработанная ЭЦП ДОЛЖНА представляться строкой октетов и сохраняться в компоненте signature типа SignerInfo.

8.7 Проверка ЭЦП

При проверке ЭЦП используются результат хэширования и открытый ключ подписавшейся стороны. Получатель МОЖЕТ получить корректный открытый ключ любым доступным методом, но предпочтительным является получение ключа из сертификата, заданного в компоненте certificates типа SignedData. Получение и проверка открытого ключа МОГУТ быть основаны на проверке маршрута сертификации (см. СТБ 34.101.19) либо на других методах, не определяемых в настоящем стандарте. Детали проверки подписи определяются особенностями используемых алгоритмов ЭЦП.

Получатель НЕ ДОЛЖЕН основывать выводы о корректности ЭЦП на хэш-значениях, представленных подписавшейся стороной. Если компонент signerInfo типа SignedData включает signedAttributes, то подписываемые данные ДОЛЖНЫ хэшироваться по правилам, определенным в 8.5. Для признания ЭЦП корректной вычисленное хэш-значение ДОЛЖНО совпасть со значением атрибута «хэш-значение», содержащегося в signedAttributes.

Если компонент signerInfo типа SignedData включает signedAttributes, то атрибут «тип содержимого» ДОЛЖЕН совпадать со значением компонента eContentType, вложенного в компонент encapContentInfo типа SignedData.

9 Конвертованные данные

9.1 Общее описание

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

Тип конвертованных данных задается следующим идентификатором:

id-envelopedData OBJECT IDENTIFIER ::=
  {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3}

Процесс формирования конвертованных данных включает следующие шаги:

  1. Случайным образом формируется ключ шифрования данных выбранного алгоритма шифрования.

  2. Ключ шифрования данных зашифровывается для каждого получателя. Способ шифрования ключа определяется выбранным методом управления ключами. Как правило, применяется четыре основных метода:

    • транспорт ключа: ключ шифрования данных зашифровывается на открытом ключе получателя;

    • согласование ключа: открытый ключ получателя и личный ключ отправителя используются для формирования общего секретного ключа, на котором зашифровывается ключ шифрования данных;

    • предварительное распределение секретных ключей: для шифрования ключей шифрования данных используются предварительно распределенные секретные ключи;

    • пароли: для шифрования ключей шифрования данных используются ключи, построенные по паролю или по другим секретным данным, известным только получателю и отправителю.

  3. Для каждого получателя формируется структура данных типа RecipientInfo, которая содержит зашифрованный ключ шифрования данных и другую связанную с получателем информацию.

  4. Передаваемые данные зашифровываются на ключе шифрования данных.

  5. Структуры данных типа RecipientInfo и зашифрованные данные заносятся в структуру типа EnvelopedData.

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

В следующих двух разделах описываются типы EnvelopedData, и RecipientInfo, которые определяют формат конвертованных данных. В 9.4, 9.5 описываются процессы шифрования данных и ключей.

9.2 Тип EnvelopedData

Формат конвертованных данных определяется следующими типами АСН.1:

EnvelopedData ::= SEQUENCE {
  version CMSVersion,
  originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
  recipientInfos RecipientInfos,
  encryptedContentInfo EncryptedContentInfo,
  unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL}

OriginatorInfo ::= SEQUENCE {
  certs [0] IMPLICIT CertificateSet OPTIONAL,
  crls [1] IMPLICIT RevocationInfoChoices OPTIONAL}

RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

EncryptedContentInfo ::= SEQUENCE {
  contentType ContentType,
  contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
  encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL}

EncryptedContent ::= OCTET STRING

UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute

Компоненты EnvelopedData имеют следующее значение:

  • version определяет номер версии применяемого синтаксиса. Номер версии ДОЛЖЕН определяться путем последовательной проверки следующих условий, вплоть до первого выполненного:
Условие Версия
Включен компонент originatorInfo, который содержит сертификаты или списки отозванных сертификатов различных типов 4
Включен компонент originatorInfo, который содержит атрибутный сертификат версии 2, или включен компонент RecipientInfo с выбором pwri или ori (см. 9.3) 3
Отсутствует компонент originatorInfo, или отсутствует компонент unprotectedAttrs, или все компоненты RecipientInfo имеют версию 0 0
В остальных случаях 2
  • originatorInfo содержит информацию об отправителе. Компонент присутствует, только если его требуется использовать в алгоритме управления ключами. Компонент может содержать сертификаты и списки отозванных сертификатов.

  • recipientInfos определяет информацию, связанную с получателями. В данном компоненте ДОЛЖНА быть представлена информация по крайней мере для одного получателя.

  • encryptedContentInfo определяет зашифрованные данные.

  • unprotectedAttrs определяет дополнительные атрибуты данных, которые не зашифровываются. Некоторые распространенные атрибуты описаны в разделе 15.

Компоненты originatorInfo имеют следующее значение:

  • certs определяет список сертификатов. Список МОЖЕТ содержать сертификаты отправителя, связанные с различными методами управления ключами. Список МОЖЕТ содержать атрибутные сертификаты отправителя. Список предназначен для построения маршрутов сертификации от точек доверия (корневых удостоверяющих центров) ко всем сертификатам в списке. В списке может быть больше сертификатов, чем действительно необходимо. Например, список может определять маршруты сертификации для двух и более точек доверия. В списке также может быть меньше сертификатов, чем необходимо. При этом предполагается, что получатель имеет дополнительные возможности получения недостающих сертификатов, например, из предыдущих списков сертификатов.

  • crls определяет набор списков отозванных сертификатов. Предполагается, что набор содержит достаточно информации для вывода о том, что сертификаты компонента certs действительны, хотя данное предположение не является необходимым. МОЖЕТ быть задано больше списков, чем действительно необходимо, хотя информации из списков МОЖЕТ быть и недостаточно.

Компоненты encryptedContentInfo имеют следующее значение:

  • contentType определяет идентификатор типа данных.

  • contentEncryptionAlgorithm определяет идентификатор и параметры используемого алгоритма шифрования. Процесс шифрования данных описан в 9.4. Одни и те же алгоритм и ключ шифрования данных используются для всех получателей.

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

Примечание – Компонент recipientInfos включен в EnvelopedData перед компонентом encryptedContentInfo, что позволяет организовать однопроходную обработку данных.

9.3 Тип RecipientInfo

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

Реализации могут не поддерживать все возможные методы управления ключами. Тем не менее, реализации ДОЛЖНЫ корректно обрабатывать нереализованные алгоритмы, которые встречаются при обработке данных. Например, реализация, которая поддерживает предварительное распределение ключей СТБ 34.101.31 должна возвращать штатное сообщение об ошибке при обработке предварительного распределения ключей ГОСТ 28147.

Реализации ДОЛЖНЫ поддерживать транспорт ключа, согласование ключа и предварительное распределение секретных ключей. Для этого в типе RecipientInfo предусмотрены компоненты ktri, kari и kekri соответственно. Реализации МОГУТ поддерживать парольную защиту ключей. Для этого предусмотрен компонент pwri. Реализации МОГУТ поддерживать другие методы управления ключами, для чего предусмотрен компонент ori.

Так как каждый получатель конвертованных данных может применять любой из методов управления ключами и в будущем могут быть разработаны новые методы, реализации ДОЛЖНЫ корректно обрабатывать неподдерживаемые компоненты RecipientInfo, неподдерживаемые версии поддерживаемых компонентов RecipientInfo и неизвестные методы, заданные в компоненте ori.

RecipientInfo ::= CHOICE {
  ktri KeyTransRecipientInfo,
  kari [1] KeyAgreeRecipientInfo,
  kekri [2] KEKRecipientInfo,
  pwri [3] PasswordRecipientinfo,
  ori [4] OtherRecipientInfo}

EncryptedKey ::= OCTET STRING

9.4 Тип KeyTransRecipientInfo

Тип KeyTransRecipientInfo используется при транспорте ключа и описывает информацию, касающуюся получателей. Через экземпляр KeyTransRecipientInfo зашифрованный ключ шифрования данных передается одному из получателей.

KeyTransRecipientInfo ::= SEQUENCE {
  version CMSVersion,
  rid RecipientIdentifier,
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  encryptedKey EncryptedKey}

RecipientIdentifier ::= CHOICE {
  issuerAndSerialNumber IssuerAndSerialNumber,
  subjectKeyIdentifier [0] SubjectKeyIdentifier}

Компоненты KeyTransRecipientInfo имеют следующее значение:

  • version определяет номер версии применяемого синтаксиса. Если в RecipientIdentifier выбран компонент issuerAndSerialNumber, то номер версии ДОЛЖЕН быть равен 0, если выбран компонент subjectKeyIdentifier, то номер версии ДОЛЖЕН быть равен 2.

  • rid определяет ссылку на сертификат, который содержит открытый ключ получателя, или непосредственно на открытый ключ. Открытый ключ получателя используется для защиты ключа шифрования данных при транспорте: ключ шифрования данных зашифровывается на открытом ключе получателя. Если открытый ключ размещается в сертификате, удовлетворяющем требованиям СТБ 34.101.19, то в расширении KeyUsage сертификата (см. СТБ 34.101.19, подпункт 6.2.1.3) ДОЛЖЕН быть установлен бит keyEncipherment. Тип RecipientIdentifier позволяет задать ссылку на открытый ключ двумя способами. При выборе компонента issuerAndSerialNumber задается уникальное имя эмитента сертификата и номер сертификата. При выборе компонента subjectKeyIdentifier задается идентификатор открытого ключа. При этом если ключ размещается в сертификате, удовлетворяющем требованиям СТБ 34.101.19, то его идентификатор должен совпадать со значением расширения SubjectKeyIdentifier (см. СТБ 34.101.19, подпункт 6.2.1.2). При ссылках на сертификаты других форматов документация по форматам и использованию сертификатов в CMS должна определять соответствие между идентификатором открытого ключа и определенным компонентом сертификата. Реализации получателя ДОЛЖНЫ поддерживать обработку обоих компонентов issuerAndSerialNumber и subjectKeyIdentifier типа RecipientIdentifier. Реализации отправителя ДОЛЖНЫ поддерживать обработку хотя бы одного компонента.

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

  • encryptedKey определяет зашифрованный ключ шифрования данных для получателя.

9.4.1 Тип KeyAgreeRecipientInfo

Тип KeyAgreeRecipientInfo используется при согласовании ключа и описывает информацию, касающуюся получателей. Через экземпляр KeyAgreeRecipientInfo зашифрованный ключ передается одному или нескольким получателям, которые используют одинаковые алгоритмы согласования ключа и одинаковые долговременные параметры этих алгоритмов.

KeyAgreeRecipientInfo ::= SEQUENCE {
  version CMSVersion,
  originator [0] EXPLICIT OriginatorIdentifierOrKey,
  ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  recipientEncryptedKeys RecipientEncryptedKeys}

OriginatorIdentifierOrKey ::= CHOICE {
  issuerAndSerialNumber IssuerAndSerialNumber,
  subjectKeyIdentifier [0] SubjectKeyIdentifier,
  originatorKey [1] OriginatorPublicKey}

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

RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey

RecipientEncryptedKey ::= SEQUENCE {
  rid KeyAgreeRecipientIdentifier,
  encryptedKey EncryptedKey}

KeyAgreeRecipientIdentifier ::= CHOICE {
  issuerAndSerialNumber IssuerAndSerialNumber,
  rKeyId [0] IMPLICIT RecipientKeyIdentifier}

RecipientKeyIdentifier ::= SEQUENCE {
  subjectKeyIdentifier SubjectKeyIdentifier,
  date GeneralizedTime OPTIONAL,
  other OtherKeyAttribute OPTIONAL}

SubjectKeyIdentifier ::= OCTET STRING

Компоненты KeyAgreeRecipientInfo имеют следующее значение:

  • version определяет номер версии применяемого синтаксиса. Номер версии всегда ДОЛЖЕН быть равен 3.

  • originator определяет открытый ключ отправителя. Отправитель использует свой личный ключ и открытый ключ получателя для формирования общего секретного ключа, который используется для зашифрования ключа шифрования данных. Тип OriginatorIdentifierOrKey определяет открытый ключ тремя способами. Во-первых, при выборе компонента issuerAndSerialNumber задается ссылка на сертификат отправителя, в том числе его открытый ключ, через уникальное имя эмитента сертификата и номер сертификата. Во‑вторых, при выборе компонента subjectKeyIdentifier задается ссылка на сертификат отправителя, в том числе его открытый ключ, через идентификатор открытого ключа. При этом если ключ размещается в сертификате, удовлетворяющем требованиям СТБ 34.101.19, то его идентификатор должен совпадать со значением расширения SubjectKeyIdentifier (см. СТБ 34.101.19, подпункт 6.2.1.2). При ссылках на сертификаты других форматов документация по форматам и использованию сертификатов в CMS должна определять соответствие между идентификатором открытого ключа и определенным компонентом сертификата. В-третьих, при выборе в OriginatorIdentifierOrKey компонента originatorKey задается идентификатор используемого алгоритма согласования ключа и непосредственно открытый ключ. Выбор компонента originatorKey позволяет добиться анонимности отправителя, так как при этом открытый ключ не содержит информации об отправителе. Реализации ДОЛЖНЫ поддерживать обработку всех трех способов определения открытого ключа.

  • ukm определяет дополнительные данные алгоритма согласования общего ключа. Компонент ukm является необязательным. В некоторых алгоритмах согласования отправитель использует дополнительные несекретные данные (user keying material) для того, чтобы при выполнении алгоритма согласования на одних и тех же открытом и личном ключах результаты были разными. Реализации ДОЛЖНЫ поддерживать включение в KeyAgreeRecipientInfo компонента ukm. Реализации, которые не поддерживают алгоритмы согласования с использованием ukm, тем не менее, ДОЛЖНЫ корректно обрабатывать этот компонент.

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

  • recipientEncryptedKeys определяет список идентификаторов получателей и предназначенных им зашифрованных ключей шифрования данных. Идентификатор является значением типа KeyAgreeRecipientIdentifier и определяет ссылку на открытый ключ получателя. Открытый ключ получателя используется для согласования общего ключа. Поэтому если открытый ключ размещается в сертификате, удовлетворяющем требованиям СТБ 34.101.19, то в расширении KeyUsage (см. СТБ 34.101.19, подпункт 6.2.1.3) должен быть установлен бит keyAgreement. Ссылка на открытый ключ в KeyAgreeRecipientIdentifier может быть задана двумя способами. Во-первых, при выборе компонента issuerAndSerialNumber задается ссылка на сертификат получателя, в том числе его открытый ключ, через уникальное имя эмитента сертификата и номер сертификата. Во‑вторых, при выборе компонента rKeyId задается идентификатор открытого ключа. Описание соответствующего типа RecipientKeyIdentifier приведено ниже. Реализации ДОЛЖНЫ поддерживать обработку обоих компонентов KeyAgreeRecipientIdentifier. Компонент encryptedKey определяет ключ шифрования данных, зашифрованный на согласованном общем ключе.

Компоненты RecipientKeyIdentifier имеют следующее значение:

  • subjectKeyIdentifier содержит идентификатор открытого ключа. Если ключ размещается в сертификате, удовлетворяющем требованиям СТБ 34.101.19, то его идентификатор должен совпадать со значением расширения SubjectKeyIdentifier (см. СТБ 34.101.19, подпункт 6.2.1.2). При ссылках на сертификаты других форматов документация по форматам и использованию сертификатов в CMS должна определять соответствие между идентификатором открытого ключа и определенным компонентом сертификата.

  • date является необязательным компонентом, который указывает на ранее переданное значение ukm, использованное отправителем.

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

9.4.2 Тип KEKRecipientInfo

Тип KEKRecipientInfo описывает информацию, передаваемую получателям конвертованных данных при использовании заранее распределенных ключей шифрования ключей. Через экземпляры KEKRecipientInfo зашифрованные ключи шифрования данных пересылаются одному или нескольким получателям конвертованных данных.

KEKRecipientInfo ::= SEQUENCE {
  version CMSVersion,
  kekid KEKIdentifier,
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  encryptedKey EncryptedKey}

KEKIdentifier ::= SEQUENCE {
  keyIdentifier OCTET STRING,
  date GeneralizedTime OPTIONAL,
  other OtherKeyAttribute OPTIONAL}

Компоненты KEKRecipientInfo имеют следующее значение:

  • version определяет номер версии применяемого синтаксиса. Номер версии всегда ДОЛЖЕН быть равен 4.

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

  • keyEncryptionAlgorithm определяет идентификатор и параметры алгоритма шифрования ключа шифрования данных. Процесс шифрования ключа шифрования данных описан в 9.5.

  • encryptedKey определяет ключ шифрования ключей, зашифрованный на ключе шифрования данных.

Компоненты KEKIdentifier имеют следующее значение:

  • keyIdentifier определяет ссылку на ключ шифрования ключей, который был предварительно распределен отправителю и одному или нескольким получателям.

  • date является необязательным компонентом, который указывает на один ключ из набора предварительно распределенных ключей шифрования ключей.

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

9.4.3 Тип PasswordRecipientInfo

Тип PasswordRecipientInfo описывает информацию, передаваемую получателям конвертованных данных при использовании паролей. Через экземпляры KEKRecipientInfo зашифрованные ключи шифрования данных пересылаются одному или несколькими получателям, которые знают пароль или другой общий секрет.

PasswordRecipientInfo ::= SEQUENCE {
  version CMSVersion,
  keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier OPTIONAL,
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  encryptedKey EncryptedKey}

Компоненты PasswordRecipientInfo имеют следующее значение:

  • version определяет номер версии применяемого синтаксиса. Номер версии всегда ДОЛЖЕН быть равен 0.

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

  • keyEncryptionAlgorithm определяет алгоритм шифрования ключей шифрования данных, а также параметры алгоритма. Процесс шифрования ключа шифрования данных описан в 9.5.

  • encryptedKey определяет ключ шифрования данных, зашифрованный на ключе шифрования ключей.

9.4.4 Тип OtherRecipientInfo

Тип OtherRecipientInfo описывает информацию, передаваемую получателям конвертованных данных при применении дополнительных методов управления ключами шифрования данных. С помощью OtherRecipientInfo можно применять методы, отличные от описанных выше.

OtherRecipientInfo ::= SEQUENCE {
  oriType OBJECT IDENTIFIER,
  oriValue ANY DEFINED BY oriType}

Компоненты OtherRecipientInfo имеют следующее значение:

  • oriType определяет метод управления ключами.

  • oriValue содержит данные, необходимые для применения выбранного метода управления.

9.5 Процесс шифрования данных

При шифровании данных ключ выбранного алгоритма шифрования вырабатывается случайным образом. Данные (строка октетов) дополняются до определенной длины, как описано ниже, а затем зашифровываются с помощью выработанного ключа. Шифрование состоит в преобразовании первоначальной строки октетов (открытые данные) в новую строку (зашифрованные данные) c использованием ключа. Зашифрованные данные помещаются в компонент encryptedContent, вложенный в компонент encryptedContentInfo типа EnvelopedData.

В некоторых алгоритмах шифрования предполагается, что длина входной строки октетов кратна k, 1 < k < 256. Если это так, то входную строку следует дополнить k − l октетами, каждый из которых представляет число k − l, где l – остаток от деления длины входной строки на k. Если, например, l = k − 1, то строка дополняется одним октетом, представляющим число 1, а если l = 0, то добавляется k октетов, представляющих число k. По строке, полученной в результате дополнения, можно однозначно восстановить первоначальную строку, так как дополнение применяется ко всем строкам, в том числе строкам длины, кратной k, и ни одна из полученных в результате дополнения строк не является суффиксом другой.

9.6 Процесс шифрования ключей

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

10 Хэшированные данные

10.1 Общее описание

Хэшированные данные – это данные вместе с вычисленным для них хэш-значением. Обычно данный тип применяется для контроля целостности данных и используется в качестве вложенного контейнера при формировании конвертованных данных.

Тип хэшированных данных задается следующим идентификатором:

id-digestedData OBJECT IDENTIFIER ::=
  {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5}

Процесс формирования хэшированных данных включает следующие шаги:

  1. С помощью алгоритма хэширования вычисляется хэш-значение данных.

  2. Информация об алгоритме хэширования и хэш-значение сохраняются в структуре типа DigestedData.

Получатель проверяет целостность хэшированных данных, сравнивая хэш-значение из DigestedData с независимо вычисленным хэш-значением.

10.2 Тип DigestedData

Формат хэшированных данных определяется следующими типами АСН.1:

DigestedData ::= SEQUENCE {
  version CMSVersion,
  digestAlgorithm DigestAlgorithmIdentifier,
  encapContentInfo EncapsulatedContentInfo,
  digest Digest}

Digest ::= OCTET STRING

Компоненты DigestedData имеют следующее значение:

  • version определяет номер версии применяемого синтаксиса. Если вложенные данные являются неструктурированными и имеют тип id-data, то номер версии ДОЛЖЕН быть равен 0; в остальных случаях номер версии ДОЛЖЕН быть равен 2.

  • digestAlgorithm определяет идентификатор и параметры алгоритма хэширования.

  • encapContentInfo определяет данные, для которых вычисляется хэш-значение. Тип данного компонента описан в 8.3.

  • digest содержит хэш-значение данных.

Хэширование производится в соответствии с 8.5 для случая, когда подписываемые атрибуты отсутствуют.

Примечание – Использованный в DigestedData порядок компонентов digestAlgorithm, encapContentInfo и digest позволяет организовать однопроходную обработку данных.

11 Шифрованные данные

11.1 Общее описание

Шифрованные данные – это данные любого типа, зашифрованные на некотором ключе. В отличие от конвертованных данных, в шифрованных данных не содержится информации ни о получателях, ни о ключах шифрования. Управление ключами шифрования ДОЛЖНО осуществляться другими, отличными от использованных в конвертованных данных, способами. Типичным применением данного типа является защита данных при хранении на локальных устройствах с помощью шифрования на ключе, построенном по паролю.

Тип зашифрованных данных задается следующим идентификатором:

id-encryptedData OBJECT IDENTIFIER ::=
  {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6}

11.2 Тип EncryptedData

Формат зашифрованных данных определяется следующими типами АСН.1:

EncryptedData ::= SEQUENCE {
  version CMSVersion,
  encryptedContentInfo EncryptedContentInfo,
  unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL}

Компоненты EncryptedData имеют следующее значение:

  • version определяет номер версии применяемого синтаксиса. Если включен компонент unprotectedAttrs, то номер версии ДОЛЖЕН быть равен 2; если компонент unprotectedAttrs отсутствует, то номер версии ДОЛЖЕН быть равен 0.

  • encryptedContentInfo определяет зашифрованные данные. Тип данного компонента описан в 9.2.

  • unprotectedAttrs содержит набор дополнительных атрибутов, которые не зашифровываются. Некоторые распространенные атрибуты описаны в разделе 15.

12 Аутентифицируемые данные

12.1 Общее описание

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

Тип аутентифицируемых данных задается следующим идентификатором:

id-ct-authData OBJECT IDENTIFIER ::= {iso(1) member-body(2)
  us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2}

Процесс формирования аутентифицируемых данных включает следующие шаги:

  1. Для заданного алгоритма выработки имитовставки случайным образом генерируется ключ имитозащиты.

  2. Ключ имитозащиты зашифровывается для каждого получателя. Особенности шифрования и распространения ключей зависят от применяемого метода управления ключами (см. 9.1).

  3. Для каждого получателя формируется структура данных типа RecipientInfo, которая содержит зашифрованный ключ имитозащиты и другие связанные с выработкой имитовставки данные (см. 9.3).

  4. Используя ключ имитозащиты, отправитель вычисляет имитовставку вложенных данных. Если кроме вложенных данных требуется организовать защиту дополнительной информации (см. 12.3), то вложенные данные хэшируются, полученное хэш-значение дополняется этой информацией и подается на вход алгоритма имитозащиты. Имитовставка является результатом выполнения алгоритма на ключе имитозащиты.

12.2 Тип AuthenticatedData

Формат аутентифицируемых данных определяется следующими типами АСН.1:

AuthenticatedData ::= SEQUENCE {
  version CMSVersion,
  originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
  recipientInfos RecipientInfos,
  macAlgorithm MessageAuthenticationCodeAlgorithm,
  digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
  encapContentInfo EncapsulatedContentInfo,
  authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
  mac MessageAuthenticationCode,
  unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL}

AuthAttributes ::= SET SIZE (1..MAX) OF Attribute

UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute

MessageAuthenticationCode ::= OCTET STRING

Компоненты типа DigestedData имеют следующее значение:

  • version определяет номер версии применяемого синтаксиса. Номер версии ДОЛЖЕН определяться путем последовательной проверки следующих условий, вплоть до первого выполненного:
Условие Версия
Включен компонент originatorInfo, и он содержит сертификаты или списки отозванных сертификатов различных типов 3
Включен компонент originatorInfo, и он содержит атрибутные сертификаты версии 2 1
В остальных случаях 0
  • originatorInfo является необязательным компонентом, который определяет информацию об отправителе. Компонент присутствует только тогда, когда данная информация требуется для применяемого метода управления ключами. Компонент МОЖЕТ содержать сертификаты, атрибутные сертификаты и списки отозванных сертификатов, как описано в 9.2.

  • recipientInfos определяет набор связанной с получателем информации. Тип данного компонента определен в 9.3. Набор ДОЛЖЕН содержать по крайней мере один элемент.

  • macAlgorithm определяет идентификатор и параметры используемого алгоритма выработки имитовставки. Порядок следования данного компонента позволяет получателю обрабатывать аутентифицируемые данные за один проход.

  • digestAlgorith является необязательным компонентом, который определяет идентификатор и параметры алгоритма хэширования, используемого для обработки вложенных данных при наличии аутентифицируемых атрибутов. Вычисление хэш-значения производится в соответствии с 8.5. Порядок следования данного компонента позволяет получателю обрабатывать аутентифицируемые данные за один проход. Если присутствует компонент digestAlgorithm, то также ДОЛЖЕН присутствовать компонент authAttrs.

  • encapContentInfo определяет вложенные данные, целостность и подлинность которых контролируется. Тип данного компонента определен в 8.3.

  • authAttrs является необязательным компонентом, который определяет набор аутентифицируемых атрибутов. Компонент ДОЛЖЕН присутствовать, если значение типа EncapsulatedContentInfo содержит данные, тип которых отличается от id-data. Если присутствует компонент authAttrs, то также ДОЛЖЕН присутствовать компонент digestAlgorithm. Значение типа AuthAttributes ДОЛЖНО быть закодировано с помощью отличительных правил, даже если все остальные значения закодированы с помощью базовых правил. Если присутствует компонент authAttrs, то он ДОЛЖЕН содержать по крайней мере атрибуты «тип содержимого» и «хэш-значение». Атрибут «тип содержимого» определяет тип данных, которые содержатся в EncapsulatedContentInfo. Атрибут «хэш-значение» определяет хэш-значение данных, которые содержатся в EncapsulatedContentInfo. Данные атрибуты описаны в 15.2 и 15.3.

  • mac определяет имитовставку.

  • unauthAttrs является необязательным компонентом, который определяет набор неаутентифицируемых атрибутов. Настоящий стандарт не определяет атрибуты, которые классифицируются как неаутентифицируемые. Некоторые общие распространенные атрибуты описаны в разделе 15.

12.3 Вычисление имитовставки

Имитовставка вычисляется либо непосредственно от данных, либо от хэш-значения данных, дополненного аутентифицируемыми атрибутами.

Если компонент authAttrs отсутствует, то на вход алгоритма выработки имитовставки подается значение компонента eContent, вложенного в компонент encapContentInfo. Имитовставка вычисляется от октетов содержимого кодового представления компонента eContent, октеты тега и длины не используется. Важно, что при этом объем данных, от которых вычисляется имитовставка, может быть заранее не известен.

Если присутствует компонент authAttrs, то он ДОЛЖЕН включать атрибуты «тип содержимого» и «хэш-значение», определенные в 15.2 и 15.3. При этом на вход алгоритма выработки имитовставки подается закодированное с помощью отличительных правил кодирования значение компонента authAttrs. Компонент authAttrs должен кодироваться для вычисления имитовставки как отдельное от AuthenticatedData значение типа SET OF Atrribute. Это значит, что при кодировании тег IMPLICIT [2] ДОЛЖЕН быть заменен на тег SET OF. Таким образом, обработке при вычислении имитовставки подвергается октет тега SET OF, дополненный октетами длины и содержимого кодового представления authAttrs.

Хэшируются непосредственно данные, целостность которых контролируется. Входными данными алгоритма хэширования является значение компонента eContent, вложенного в компонент encapContentInfo. Хэшируются октеты содержимого кодового представления eContent, октеты тега и длины не используется. Важно, что при этом объем данных, целостность которых контролируется, может быть заранее не известен.

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

При вычислении имитовставки используется ключ имитозащиты, предаваемый в компоненте recipientInfo. Детали вычисления имитовставки определяются особенностями используемого алгоритма. Идентификатор алгоритма выработки имитовставки, а также используемые параметры алгоритма, задаются в компоненте macAlgorithm. Выработанная имитовставка представляется строкой октетов и сохраняется в компоненте mac.

12.4 Проверка имитовставки

Входными данными при проверке имитовставки являются данные, которые строятся в зависимости от наличия или отсутствия компонента authAttrs по правилам согласно 12.3, и ключ имитозащиты, предаваемый в компоненте recipientInfo. Детали проверки имитовставки определяются особенностями используемого алгоритма.

Получатель НЕ ДОЛЖЕН делать выводы о целостности данных только на основании имитовставок или хэш-значений, представленных отправителем. Для подтверждения целостности данных имитовставка, вычисленная получателем, ДОЛЖНА совпадать со значением компонента mac. Данные, от которых вычисляется имитовставка, определяются в 12.3. Если отправитель включает аутентифицируемые атрибуты, то имитовставка вычисляется от значения компонента authAttrs согласно 12.3. Кроме того, при наличии компонента authAttrs хэш-значение, вычисленное получателем, ДОЛЖНО совпадать со значением атрибута «хэш-значение», содержащегося в компоненте authAttrs.

Если тип AuthenticatedData включает компонент authAttrs, то значение атрибута «тип содержимого» ДОЛЖНО совпадать со значением компонента eContentType, вложенного в компонент encapContentInfo.

13 Аутентифицируемые конвертованные данные

13.1 Общее описание

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

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

Тип аутентифицируемых конвертованных данных задается следующим идентификатором:

id-ct-authEnvelopedData OBJECT IDENTIFIER ::= {iso(1) member-body(2)
  us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 23}

Процесс формирования аутентифицируемых конвертованных данных включает следующие шаги:

  1. Для заданного алгоритма одновременного шифрования и имитозащиты случайным образом генерируется ключ защиты данных.

  2. Ключ защиты данных зашифровывается для каждого получателя. Детали шифрования ключа определяются применяемым методом управления ключами (см. 9.1).

  3. Для каждого получателя формируется структура данных типа RecipientInfo, которая содержит зашифрованный ключ защиты и другие связанные с шифрованием и выработкой имитовставки данные (см. 9.3).

  4. Формируются аутентифицируемые атрибуты, включающие любые атрибуты, для которых требуется контролировать целостность, но не требуется обеспечивать конфиденциальность.

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

  6. Формируются неаутентифицируемые атрибуты, включающие любые атрибуты, для которых не требуется контролировать целостность и обеспечивать конфиденциальность.

  7. Формируется структура данных AuthEnvelopedData, которая содержит экземпляры RecipientInfo для каждого из получателей, аутентифицируемые атрибуты, неаутентифицируемые атрибуты, а также зашифрованные данные и имитовставку.

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

Получатель ДОЛЖЕН проверить целостность вложенных данных до их использования. При нарушении целостности данные НЕ ДОЛЖНЫ использоваться, все расшифрованные данные ДОЛЖНЫ быть уничтожены.

13.2 Тип AuthEnvelopedData

Формат аутентифицируемых конвертованных данных определяется следующими типами АСН.1:

AuthEnvelopedData ::= SEQUENCE {
  version CMSVersion,
  originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
  recipientInfos RecipientInfos,
  authEncryptedContentInfo EncryptedContentInfo,
  authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
  mac MessageAuthenticationCode,
  unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL}

Компоненты типа AuthEnvelopedData имеют следующее значение:

  • version определяет номер версии применяемого синтаксиса. Номер версии ДОЛЖЕН быть установлен в 0.

  • originatorInfo является необязательным компонентом, который определяет информацию об отправителе. Компонент присутствует только тогда, когда данная информация требуется для применяемого метода управления ключами. Компонент МОЖЕТ содержать сертификаты, атрибутные сертификаты и списки отозванных сертификатов, как описано в 9.2.

  • recipientInfos определяет набор связанной с получателем информации. Тип данного компонента определен в 9.3. Набор ДОЛЖЕН содержать по крайней мере один элемент.

  • authEncryptedContentInfo определяет зашифрованные данные. Тип данного компонента определен в 9.2.

  • authAttrs является необязательным компонентом, который определяет аутентифицируемые атрибуты. Компонент ДОЛЖЕН присутствовать, если значение типа EncryptedContentInfo содержит данные, тип которых отличается от id-data. Значение типа AuthAttributes ДОЛЖНО быть закодировано с помощью отличительных правил, даже если все остальные значения структуры AuthEnvelopedData закодированы с помощью базовых правил. Тип данного компонента определен в 12.2. Данный компонент НЕ ДОЛЖЕН содержать атрибут «хэш-значение». В разделе 15 описаны некоторые распространенные атрибуты.

  • mac хранит имитовставку, вычисленную с помощью выбранного алгоритма одновременного шифрования и имитозащиты. Имитовставка вычисляется непосредственно от данных и аутентифицируемых атрибутов, при этом хэширование данных не используется. Тип данного компонента определен в 12.2.

  • unauthAttrs является необязательным компонентом, который определяет неаутентифицируемые атрибуты. Тип данного компонента определен в 12.2. В разделе 15 описаны некоторые распространенные атрибуты.

13.3 Шифрование и имитозащита

Если входные данные (строки октетов) используемого алгоритма одновременного шифрования и имитозащиты должны иметь определенную длину, то эти данные дополняются до требуемой длины по правилам, определенным в 9.5. Эти правила действуют только в том случае, когда идет речь о выравнивании данных на блок из k < 256 октетов.

Если присутствуют необязательные аутентифицируемые атрибуты, то они должны быть закодированы с помощью отличительных правил. Кодирование компонента authAttrs с помощью отличительных правил выполняется для построения открытых входных данных алгоритма одновременного шифрования и имитозащиты, т. е. данных, для которых вычисляется имитовставка и которые не зашифровываются. Компонент authAttrs должен кодироваться как отдельное от AuthEnvelopedData значение типа SET OF Atrribute. Это значит, что при кодировании тег IMPLICIT [1] ДОЛЖЕН быть заменен на тег SET OF. Таким образом, при вычислении имитовставки обработке подвергается октет тега SET OF, дополненный октетами длины и содержимого кодового представления authAttrs.

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

Алгоритм одновременного шифрования и имитозащиты выполняет зашифрование вложенных данных и вычисляет имитовставку объединения вложенных данных и открытых входных данных. Ключ алгоритма вырабатывается случайным образом. Зашифрованные данные сохраняются в компоненте encryptedContent, вложенном в компонент authEncryptedContentInfo типа AuthEnvelopedData. Имитовставка сохраняется в компоненте mac типа AuthEnvelopedData.

13.4 Шифрование ключей

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

14 Вспомогательные типы

14.1 Тип AlgorithmIdentifier и связанные типы

Идентификаторы криптографических алгоритмов описываются типом AlgorithmIdentifier, определенным в СТБ 34.101.19.

Тип DigestAlgorithmIdentifier описывает алгоритмы хэширования. Алгоритм хэширования ставит в соответствие строке октетов произвольной длины (хэшируемым данным) строку октетов фиксированной длины (хэш-значение).

DigestAlgorithmIdentifier ::= AlgorithmIdentifier

Тип SignatureAlgorithmIdentifier описывает алгоритмы выработки и проверки ЭЦП, в том числе вспомогательные алгоритмы хэширования. Подпись вырабатывается под хэш-значением подписываемых данных на личном ключе подписывающей стороны. Подпись проверяется по хэш-значению подписанных данных на открытом ключе подписавшей стороны.

SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

Тип KeyEncryptionAlgorithmIdentifier описывает алгоритмы шифрования ключей шифрования данных. При зашифровании строке октетов (ключу) ставится в соответствие другая строка (зашифрованный ключ). При расшифровании выполняется обратное преобразование. Зашифрование и расшифрование выполняются под управлением ключа шифрования ключей. Детали зашифрования и расшифрования определяются применяемым методом управления ключами. Поддерживаются транспорт ключа, согласование ключа, предварительное распределение секретных ключей и построение секретных ключей по паролям.

KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

Тип ContentEncryptionAlgorithmIdentifier определяет алгоритмы шифрования данных. При зашифровании входной строке октетов ставится в соответствие другая строка (зашифрованные данные). При расшифровании выполняется обратное преобразование. Зашифрование и расшифрование выполняются под управлением ключа шифрования данных. Если тип ContentEncryptionAlgorithmIdentifier используется для описания аутентифицированных конвертованных данных (см. раздел 13), то он определяет алгоритмы одновременного шифрования и имитозащиты. В этом случае вместе с шифрованием выполняется выработка или проверка имитовставок, причем имитовставки могут контролировать не только зашифровываемые, но и дополнительные открытые данные.

ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

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

MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier

Тип KeyDerivationAlgorithmIdentifier определяет алгоритмы выработки ключа по паролю или другому секрету.

KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier

14.2 Тип RevocationInfoChoices

Тип RevocationInfoChoices представляет собой набор данных о статусе отзыва сертификатов. Предполагается, что набор содержит достаточно информации для вывода о том, что сертификаты действительны. МОЖЕТ быть предоставлено больше информации о статусе отзыва, чем действительно необходимо, хотя информации МОЖЕТ быть и недостаточно.

Данные о статусе отзыва сертификатов МОГУТ быть представлены в виде списка отозванных сертификатов согласно СТБ 34.101.19 (данные находятся в компоненте crl типа CertificateList, который определен в СТБ 34.101.19), но МОГУТ быть использованы данные других форматов (данные находятся в компоненте other).

RevocationInfoChoices ::= SET OF RevocationInfoChoice

RevocationInfoChoice ::= CHOICE {
  crl CertificateList,
  other [1] IMPLICIT OtherRevocationInfoFormat}

OtherRevocationInfoFormat ::= SEQUENCE {
  otherRevInfoFormat OBJECT IDENTIFIER,
  otherRevInfo ANY DEFINED BY otherRevInfoFormat}

Компонент otherRevInfoFormat может принимать значение

id-ri-ocsp-response OBJECT IDENTIFIER ::= {iso(1) 
  identified-organization(3) dod(6) internet(1) security(5) 
  mechanisms(5) pkix(7) ri(16) 2}

В этом случае компонент otherRevInfo должен иметь тип OCSPResponse, определенный в СТБ 34.101.26. Значение типа OCSPResponse содержит данные о статусе отзыва сертификата, полученные по онлайновому протоколу проверки статуса сертификата согласно СТБ 34.101.26.

14.3 Тип CertificateChoices

Тип CertificateChoices предоставляет возможность использовать сертификаты различных типов: сертификаты согласно СТБ 34.101.19 (находятся в компоненте certificate типа Certificate, который определен в СТБ 34.101.19), атрибутные сертификаты согласно [1] (находятся в компонентах v1AttrCert и v2AttrCert) или сертификаты других форматов (находятся в компоненте other).

CertificateChoices ::= CHOICE {
  certificate Certificate,
  extendedCertificate [0] IMPLICIT ExtendedCertificate,
  v1AttrCert [1] IMPLICIT AttributeCertificateV1,
  v2AttrCert [2] IMPLICIT AttributeCertificateV2,
  other [3] IMPLICIT OtherCertificateFormat}

OtherCertificateFormat ::= SEQUENCE {
otherCertFormat OBJECT IDENTIFIER,
otherCert ANY DEFINED BY otherCertFormat}

14.4 Тип CertificateSet

Тип CertificateSet определяет набор сертификатов. Список предназначен для построения маршрутов сертификации от точек доверия (корневых удостоверяющих центров) ко всем сертификатам в списке. В списке может быть больше сертификатов, чем действительно необходимо. В списке также может быть меньше сертификатов, чем необходимо. Определение маршрута сертификации приведено в СТБ 34.101.19.

CertificateSet ::= SET OF CertificateChoices

14.5 Тип IssuerAndSerialNumber

Тип IssuerAndSerialNumber используется для ссылки на сертификат открытого ключа по заданному уникальному имени эмитента сертификата и номеру сертификата. Тип определен в СТБ 34.101.19 (пункт 6.1.2).

IssuerAndSerialNumber ::= SEQUENCE {
  issuer Name,
  serialNumber CertificateSerialNumber}

CertificateSerialNumber ::= INTEGER

14.6 Тип CMSVersion

Тип CMSVersion определяет номер версии применяемого синтаксиса.

CMSVersion ::= INTEGER {v0(0), v1(1), v2(2), v3(3), v4(4), v5(5)}

14.7 Тип UserKeyingMaterial

Тип UserKeyingMaterial определяет формат дополнительных несекретных данных (user keying material), которые используются в некоторых алгоритмах согласования ключей (см. 9.4.2).

UserKeyingMaterial ::= OCTET STRING

14.8 Тип OtherKeyAttribute

Тип OtherKeyAttribute определяет синтаксис для включения в структуры данных атрибутов, которые позволят получателю определить ключ, который был использован отправителем (см. 9.4.2, 9.4.3). Следует избегать использования данного типа для предотвращения несовместимости реализаций.

OtherKeyAttribute ::= SEQUENCE {
  keyAttrId OBJECT IDENTIFIER,
  keyAttr ANY DEFINED BY keyAttrId OPTIONAL}

15 Атрибуты

15.1 Общее описание

В настоящем разделе определены атрибуты, которые можно использовать с подписанными, конвертованными, шифрованными и аутентифицируемыми данными. Атрибуты могут быть подписываемыми (см. signedAttrs в 8.4), неподписываемыми (см. unsignedAttrs в 8.4), аутентифицируемыми (см. authAttrs в 12.2 и 13.2), неаутентифицируемыми (см. unauthAttrs в 12.2 и 13.2) и незашифрованными (см. unprotectedAttrs в 9.2 и 11.2).

Атрибуты описываются с помощью типа Attribute АСН.1 (см. 8.4). Синтаксис этого типа соответствует требованиям СТБ 34.101.19.

Компоненты Attribute имеют следующее значение:

  • attrType определяет тип атрибута и является идентификатором объекта АСН.1.

  • attrValues определяет список значений, которые в совокупности составляют атрибут. Тип каждого значения однозначно определяется attrType. Компонент attrType может накладывать ограничения на число элементов в списке.

15.2 Тип содержимого

Атрибут «тип содержимого» определяет тип данных контейнера ContentInfo, вложенного в подписанные или аутентифицируемые данные. Атрибут «тип содержимого» ДОЛЖЕН присутствовать в списке подписываемых атрибутов подписываемых данных и в списке аутентифицируемых атрибутов аутентифицируемых данных во всех случаях, когда список атрибутов непустой. Тип вложенного контейнера указывается в компоненте eContentType типа EncapsulatedContentInfo. Значение атрибута «тип содержимого» ДОЛЖНО соответствовать значению eContentType.

Атрибут «тип содержимого» ДОЛЖЕН быть подписываемым или аутентифицируемым и НЕ ДОЛЖЕН быть неподписываемым, неаутентифицируемым или незашифрованным.

Идентификатор атрибута «тип содержимого» определяется следующим образом:

id-contentType OBJECT IDENTIFIER ::=
  {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3}

Атрибут «тип содержимого» задает значения, которые описываются типом ContentType АСН.1:

ContentType ::= OBJECT IDENTIFIER

Несмотря на примененную при определении типа Attribute синтаксическую конструкцию SET OF AttributeValue, атрибут «тип содержимого» ДОЛЖЕН быть списком ровно из одного элемента (типа ContentType). Использование пустого списка или списка из двух и более элементов запрещено.

В определениях типов SignedAttributes и AuthAttributes используется конструкция SET OF Attributes. При этом значения SignedAttributes в SignerInfo и значения AuthAttributes в AuthenticatedData НЕ ДОЛЖНЫ содержать несколько экземпляров атрибута «тип содержимого».

15.3 Хэш-значение

Атрибут «хэш-значение» определяет хэш-значение кодового представления компонента eContent, вложенного в контейнер encapContentInfo, который подписывается (см. 8.5) или для которого вычисляется имитовставка (см. 12.3). Для подписываемых данных алгоритм хэширования выбирается подписывающей стороной. Для аутентифицируемых данных алгоритм хэширования выбирается отправителем.

Атрибут «хэш-значение» ДОЛЖЕН присутствовать в списке подписываемых атрибутов подписываемых данных и в списке аутентифицируемых атрибутов аутентифицируемых данных во всех случаях, когда список атрибутов непустой.

Атрибут «хэш-значение» ДОЛЖЕН быть подписываемым или аутентифицируемым и НЕ ДОЛЖЕН быть неподписываемым, неаутентифицируемым или незашифрованным.

Идентификатор атрибута «хэш-значение» определяется следующим образом:

id-messageDigest OBJECT IDENTIFIER ::=
  {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4}

Атрибут «хэш-значение» задает значения, которые описываются типом MessageDigest АСН.1:

MessageDigest ::= OCTET STRING

Несмотря на примененную при определении типа Attribute синтаксическую конструкцию SET OF AttributeValue, атрибут «хэш-значение» ДОЛЖЕН быть списком ровно из одного элемента. Использование пустого списка или списка из двух и более элементов запрещено.

В определениях типов SignedAttributes и AuthAttributes используется конструкция SET OF Attributes. При этом значения SignedAttributes в SignerInfo и значения AuthAttributes в AuthenticatedData НЕ ДОЛЖНЫ содержать несколько экземпляров атрибута «хэш-значение».

15.4 Время подписания

Атрибут «время подписания» определяет момент времени, в который подписывающая сторона (предположительно) выработала ЭЦП. Атрибут предназначен для использования в первую очередь с подписываемыми данными.

Атрибут «время подписания» ДОЛЖЕН быть подписываемым или аутентифицируемым и НЕ ДОЛЖЕН быть неподписываемым, неаутентифицируемым или незашифрованным.

Идентификатор атрибута «время подписания» определяется следующим образом:

id-signingTime OBJECT IDENTIFIER ::=
  {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5}

Атрибут «время подписания» задает значения, которые описываются следующими типами АСН.1:

SigningTime ::= Time

Time ::= CHOICE {
  utcTime UTCTime,
  generalizedTime GeneralizedTime}

Использованный тип Time соответствует требованиям СТБ 34.101.19.

Даты между 1 января 1950 года и 31 декабря 2049 года (включительно) ДОЛЖНЫ задаваться через компонент UTCTime. Остальные даты ДОЛЖНЫ задаваться через компонент GeneralizedTime.

Значения UTCTime ДОЛЖНЫ задаваться во всемирном времени в соответствии с ГОСТ ИСО 8601. Значения UTCTime ДОЛЖНЫ включать секунды (т. е. иметь вид YYMMDDhhmmssZ, подробнее см. ГОСТ 34.973, раздел 31), даже если число секунд равняется нулю. Полночь ДОЛЖНА представляться в виде "YYMMDD000000Z". Информация о столетии является неявной и ДОЛЖНА определяться следующим образом:

  • если YY ≥ 50, то год ДОЛЖЕН равняться 19YY;

  • если YY < 50, то год ДОЛЖЕН равняться 20YY.

Значения GeneralizedTime ДОЛЖНЫ задаваться во всемирном времени, ДОЛЖНЫ включать секунды (т. е. иметь вид YYYYMMDDhhmmssZ), даже если число секунд равняется нулю, и НЕ ДОЛЖНЫ включать доли секунды.

Несмотря на примененную при определении типа Attribute синтаксическую конструкцию SET OF AttributeValue, атрибут «время подписания» ДОЛЖЕН быть списком ровно из одного элемента (типа SigningTime). Использование пустого списка или списка из двух и более элементов запрещено.

В определениях типов SignedAttributes и AuthAttributes используется конструкция SET OF Attributes. При этом значения SignedAttributes в SignerInfo и значения AuthAttributes в AuthenticatedData НЕ ДОЛЖНЫ содержать несколько экземпляров атрибута «время подписания».

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

15.5 Контрподпись

Атрибут «контрподпись» определяет одну или несколько подписей значения компонента signature типа SignerInfo. Компонент signature задает ЭЦП и, таким образом, контрподпись является подписью другой подписи. Подписываются октеты содержимого кодового представления signature, октеты тега и длины не учитываются.

Атрибут «контрподпись» ДОЛЖЕН быть неподписываемым и НЕ ДОЛЖЕН быть подписываемым, аутентифицируемым, неаутентифицируемым или незашифрованным.

Идентификатор атрибута «контрподпись» определяется следующим образом:

id-countersignature OBJECT IDENTIFIER ::=
  {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6}

Атрибут «контрподпись» задает значения, которые описываются типом Countersignature АСН.1:

Countersignature ::= SignerInfo

Значения Countersignature определяются так же, как значения SignerInfo для обычных ЭЦП, со следующими изменениями:

  1. Компонент signedAttributes НЕ ДОЛЖЕН содержать атрибут «тип содержимого», такие атрибуты не используются в контрподписях.

  2. Компонент signedAttributes ДОЛЖЕН содержать атрибут «хэш-значение», если список атрибутов непустой.

  3. Входными данными при хэшировании являются октеты содержимого кодового представления значения компонента signature типа SignerInfo, с которым связан атрибут.

В соответствии с синтаксической конструкцией SET OF AttributeValue, примененной при определении типа Attribute, атрибут «контрподпись» может быть списком из нескольких элементов (типа Countersignature). Однако список НЕ ДОЛЖЕН быть пустым.

В определении типа UnsignedAttributes используется конструкция SET OF Attributes. При этом значения UnsignedAttributes в SignerInfo могут содержать несколько экземпляров атрибута «контрподпись».

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

Приложение А (обязательное)

Модули АСН.1

A.1 Модуль CMS

CryptographicMessageSyntax2004
      {iso(1) member-body(2) us(840) rsadsi(113549)
        pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24)}

DEFINITIONS IMPLICIT TAGS ::=
BEGIN
  IMPORTS
    AlgorithmIdentifier, Certificate, CertificateList,
    CertificateSerialNumber, Name
      FROM PKIX1Explicit88
        {iso(1) identified-organization(3) dod(6)
          internet(1) security(5) mechanisms(5) pkix(7)
          mod(0) pkix1-explicit(18)}

    AttributeCertificate
      FROM PKIXAttributeCertificate
        {iso(1) identified-organization(3) dod(6)
          internet(1) security(5) mechanisms(5) pkix(7)
          mod(0) attribute-cert(12)}

    AttributeCertificateV1
      FROM AttributeCertificateVersion1
        {iso(1) member-body(2) us(840) rsadsi(113549)
          pkcs(1) pkcs-9(9) smime(16) modules(0)
          v1AttrCert(15)};

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

  ContentType ::= OBJECT IDENTIFIER

  SignedData ::= SEQUENCE {
    version CMSVersion,
    digestAlgorithms DigestAlgorithmIdentifiers,
    encapContentInfo EncapsulatedContentInfo,
    certificates [0] IMPLICIT CertificateSet OPTIONAL,
    crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
    signerInfos SignerInfos}

  DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

  SignerInfos ::= SET OF SignerInfo

  EncapsulatedContentInfo ::= SEQUENCE {
    eContentType ContentType,
    eContent [0] EXPLICIT OCTET STRING OPTIONAL}

  SignerInfo ::= SEQUENCE {
    version CMSVersion,
    sid SignerIdentifier,
    digestAlgorithm DigestAlgorithmIdentifier,
    signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
    signatureAlgorithm SignatureAlgorithmIdentifier,
    signature SignatureValue,
    unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL}

  SignerIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier}

  SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

  UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

  Attribute ::= SEQUENCE {
    attrType OBJECT IDENTIFIER,
    attrValues SET OF AttributeValue}

  AttributeValue ::= ANY

  SignatureValue ::= OCTET STRING

  EnvelopedData ::= SEQUENCE {
    version CMSVersion,
    originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
    recipientInfos RecipientInfos,
    encryptedContentInfo EncryptedContentInfo,
    unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL}

  OriginatorInfo ::= SEQUENCE {
    certs [0] IMPLICIT CertificateSet OPTIONAL,
    crls [1] IMPLICIT RevocationInfoChoices OPTIONAL}

  RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

  EncryptedContentInfo ::= SEQUENCE {
    contentType ContentType,
    contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
    encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL}

  EncryptedContent ::= OCTET STRING

  UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute

  RecipientInfo ::= CHOICE {
    ktri KeyTransRecipientInfo,
    kari [1] KeyAgreeRecipientInfo,
    kekri [2] KEKRecipientInfo,
    pwri [3] PasswordRecipientInfo,
    ori [4] OtherRecipientInfo}

  EncryptedKey ::= OCTET STRING

  KeyTransRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 0 or 2
    rid RecipientIdentifier,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey}

  RecipientIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier}

  KeyAgreeRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 3
    originator [0] EXPLICIT OriginatorIdentifierOrKey,
    ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    recipientEncryptedKeys RecipientEncryptedKeys}

  OriginatorIdentifierOrKey ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier,
    originatorKey [1] OriginatorPublicKey}

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

  RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey

  RecipientEncryptedKey ::= SEQUENCE {
    rid KeyAgreeRecipientIdentifier,
    encryptedKey EncryptedKey}

  KeyAgreeRecipientIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    rKeyId [0] IMPLICIT RecipientKeyIdentifier}

  RecipientKeyIdentifier ::= SEQUENCE {
    subjectKeyIdentifier SubjectKeyIdentifier,
    date GeneralizedTime OPTIONAL,
    other OtherKeyAttribute OPTIONAL}

  SubjectKeyIdentifier ::= OCTET STRING

  KEKRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 4
    kekid KEKIdentifier,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey}

  KEKIdentifier ::= SEQUENCE {
    keyIdentifier OCTET STRING,
    date GeneralizedTime OPTIONAL,
    other OtherKeyAttribute OPTIONAL}

  PasswordRecipientInfo ::= SEQUENCE {
    version CMSVersion, -- always set to 0
    keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier OPTIONAL,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey}

  OtherRecipientInfo ::= SEQUENCE {
    oriType OBJECT IDENTIFIER,
    oriValue ANY DEFINED BY oriType}

  DigestedData ::= SEQUENCE {
    version CMSVersion,
    digestAlgorithm DigestAlgorithmIdentifier,
    encapContentInfo EncapsulatedContentInfo,
    digest Digest}

  Digest ::= OCTET STRING

  EncryptedData ::= SEQUENCE {
    version CMSVersion,
    encryptedContentInfo EncryptedContentInfo,
    unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL}

  AuthenticatedData ::= SEQUENCE {
    version CMSVersion,
    originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
    recipientInfos RecipientInfos,
    macAlgorithm MessageAuthenticationCodeAlgorithm,
    digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
    encapContentInfo EncapsulatedContentInfo,
    authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
    mac MessageAuthenticationCode,
    unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL}

  AuthAttributes ::= SET SIZE (1..MAX) OF Attribute

  UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute

  MessageAuthenticationCode ::= OCTET STRING

  DigestAlgorithmIdentifier ::= AlgorithmIdentifier

  SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

  KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

  ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

  KeyWrapAlgorithm ::= AlgorithmIdentifier

  MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier

  KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier

  RevocationInfoChoices ::= SET OF RevocationInfoChoice

  RevocationInfoChoice ::= CHOICE {
    crl CertificateList,
    other [1] IMPLICIT OtherRevocationInfoFormat}

  OtherRevocationInfoFormat ::= SEQUENCE {
    otherRevInfoFormat OBJECT IDENTIFIER,
    otherRevInfo ANY DEFINED BY otherRevInfoFormat}

  CertificateChoices ::= CHOICE {
    certificate Certificate,
    extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
    v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
    v2AttrCert [2] IMPLICIT AttributeCertificateV2,
    other [3] IMPLICIT OtherCertificateFormat}

  AttributeCertificateV2 ::= AttributeCertificate

  OtherCertificateFormat ::= SEQUENCE {
    otherCertFormat OBJECT IDENTIFIER,
    otherCert ANY DEFINED BY otherCertFormat}

  CertificateSet ::= SET OF CertificateChoices

  IssuerAndSerialNumber ::= SEQUENCE {
    issuer Name,
    serialNumber CertificateSerialNumber}

  CMSVersion ::= INTEGER {v0(0), v1(1), v2(2), v3(3), v4(4), v5(5)}

  UserKeyingMaterial ::= OCTET STRING

  OtherKeyAttribute ::= SEQUENCE {
    keyAttrId OBJECT IDENTIFIER,
    keyAttr ANY DEFINED BY keyAttrId OPTIONAL}

  -- Content Type Object Identifiers

  id-ct-contentInfo OBJECT IDENTIFIER ::= {iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6}

  id-data OBJECT IDENTIFIER ::= {iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1}

  id-signedData OBJECT IDENTIFIER ::= {iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2}

  id-envelopedData OBJECT IDENTIFIER ::= {iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3}

  id-digestedData OBJECT IDENTIFIER ::= {iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5}

  id-encryptedData OBJECT IDENTIFIER ::= {iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6}

  id-ct-authData OBJECT IDENTIFIER ::= {iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2}

  id-ri-ocsp-response OBJECT IDENTIFIER ::= {iso(1)
    identified-organization(3) dod(6) internet(1) security(5)
        mechanisms(5) pkix(7) ri(16) 2}

  MessageDigest ::= OCTET STRING

  SigningTime ::= Time

  Time ::= CHOICE {
    utcTime UTCTime,
    generalTime GeneralizedTime}

  Countersignature ::= SignerInfo

  id-contentType OBJECT IDENTIFIER ::= {iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3}

  id-messageDigest OBJECT IDENTIFIER ::= {iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4}

  id-signingTime OBJECT IDENTIFIER ::= {iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5}

  id-countersignature OBJECT IDENTIFIER ::= {iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6}

  -- Obsolete Extended Certificate syntax from PKCS #6

  ExtendedCertificateOrCertificate ::= CHOICE {
    certificate Certificate,
    extendedCertificate [0] IMPLICIT ExtendedCertificate}

  ExtendedCertificate ::= SEQUENCE {
    extendedCertificateInfo ExtendedCertificateInfo,
    signatureAlgorithm SignatureAlgorithmIdentifier,
    signature Signature}

  ExtendedCertificateInfo ::= SEQUENCE {
    version CMSVersion,
    certificate Certificate,
    attributes UnauthAttributes}

  Signature ::= BIT STRING
END

A.2 Аутентифицируемые конвертованные данные

CMS-AuthEnvelopedData-2007
  {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
    pkcs-9(9) smime(16) modules(0) cms-authEnvelopedData(31)}

DEFINITIONS IMPLICIT TAGS ::=
BEGIN
  IMPORTS
    AuthAttributes, CMSVersion, EncryptedContentInfo,
    MessageAuthenticationCode, OriginatorInfo, RecipientInfos,
    UnauthAttributes
      FROM CryptographicMessageSyntax2004
        {iso(1) member-body(2) us(840) rsadsi(113549)
        pkcs(1) pkcs-9(9) smime(16) modules(0)
        cms-2004(24)};

  id-ct-authEnvelopedData OBJECT IDENTIFIER ::= {iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
    smime(16) ct(1) 23}

  AuthEnvelopedData ::= SEQUENCE {
    version CMSVersion,
    originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
    recipientInfos RecipientInfos,
    authEncryptedContentInfo EncryptedContentInfo,
    authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
    mac MessageAuthenticationCode,
    unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL}
END

Приложение Б (рекомендуемое)

Использование криптографических алгоритмов в CMS

Б.1 Использование алгоритма, определенного в СТБ 1176.1

Алгоритм хэширования, определенный в СТБ 1176.1, НЕ ДОЛЖЕН применяться для обработки подписываемых, хэшируемых и аутентифицируемых данных. Это значит, что идентификатор и параметры алгоритма хэширования, определенного в СТБ 1176.1, НЕ ДОЛЖНЫ задаваться в компонентах digestAlgorithm, digestAlgorithms соответствующих структур данных. Алгоритм хэширования, определенный в СТБ 1176.1, МОЖЕТ применяться в CMS только неявно как композиционный элемент алгоритмов выработки и проверки ЭЦП, определенных в СТБ 1176.2.

Б.2 Использование алгоритмов, определенных в СТБ 1176.2

Определенные в СТБ 1176.2 алгоритмы выработки и проверки ЭЦП МОЖНО применять для создания и обработки подписанных данных. При этом ДОЛЖНЫ использоваться идентификаторы и параметры алгоритмов, заданные в СТБ П 34.101.50 (приложение B).

ЭЦП, определенная в СТБ 1176.2, является целым числом. При формировании значения компонента signature типа SignerInfo (см. 8.4) данное число представляется строкой октетов, которая ДОЛЖНА определяться следующим образом:

  1. Формируется двоичная последовательность, которая содержит представление ЭЦП как числа. Первый бит последовательности является старшим (ненулевым) битом числа, последний бит последовательности – младшим битом числа.

  2. В начало последовательности дописываются нулевые биты (не более 7) для получения последовательности, длина которой кратна 8.

  3. Полученная двоичная последовательность разбивается на октеты.

Б.3 Использование алгоритмов, определенных в СТБ 34.101.31

Определенные в СТБ 34.101.31 алгоритмы шифрования в режимах простой замены, сцепления блоков, гаммирования с обратной связью и счетчика МОЖНО применять для создания и обработки конвертованных и шифрованных данных. В режиме простой замены РЕКОМЕНДУЕТСЯ шифровать только высокоэнтропийные данные, например ключи. При шифровании в режимах гаммирования с обратной связью и счетчика ограничения на длину входных данных не накладываются. При шифровании в режимах простой замены и сцепления блоков длина входных строк октетов ДОЛЖНА быть кратна 16. Для выравнивания данных на границу блока ДОЛЖЕН применяться метод, описанный в 9.5.

Определенный в СТБ 34.101.31 алгоритм выработки имитовставки МОЖНО применять для создания и обработки аутентифицируемых данных.

Определенный в СТБ 34.101.31 алгоритм одновременного шифрования и имитозащиты данных МОЖНО применять для создания и обработки аутентифицируемых конвертованных данных. Для этого алгоритма ограничения на длину входных данных не накладываются.

Определенный в СТБ 34.101.31 алгоритм одновременного шифрования и имитозащиты ключей МОЖНО применять для шифрования ключей при создании и обработке конвертованных, аутентифицируемых и аутентифицируемых конвертованных данных. Алгоритм можно применять, если для шифрования ключей используются предварительно распределенные секретные ключи или пароли (см. 9.1).

Определенный в алгоритм хэширования МОЖНО применять для создания и обработки подписанных, хэшированных и аутентифицируемых данных. Возвращаемое алгоритмом хэш-значение является строкой битов, длина которой равняется 256. При необходимости данная строка естественным образом представляется строкой из 32 октетов.

При применении алгоритмов, определенных в СТБ 34.101.31, должны использоваться идентификаторы и параметры алгоритмов, заданные в приложении Б к указанному стандарту.

Б.4 Использование алгоритмов, определенных в СТБ П 34.101.45

Определенные в СТБ П 34.101.45 алгоритмы выработки и проверки ЭЦП МОЖНО применять для создания и обработки подписанных данных. В соответствии с правилами CMS (см. ) на вход алгоритмов подаются не непосредственно подписываемые данные X, а их хэш-значения h(X). Поэтому на шагах алгоритмов ЭЦП вычислять h(X) не требуется. При выработке и проверке ЭЦП обрабатывается идентификатор используемой функции хэширования h. Действие h ДОЛЖНО определяться по идентификатору однозначно, т. е. без указания дополнительных параметров.

ЭЦП, определенная в СТБ П 34.101.45 является строкой длиной 384, 576 или 768 бит. При формировании значения компонента signature типа SignerInfo (см. 8.4) данная строка естественным образом представляется строкой из 48, 72 или 96 октетов.

Определенные в СТБ П 34.101.45 алгоритмы транспорта ключа МОЖНО применять для шифрования ключей при создании и обработке конвертованных, аутентифицируемых и аутентифицируемых конвертованных данных. При этом в RecipientInfo ДОЛЖЕН быть выбран компонент ktri типа KeyTransRecipientInfo (см. 9.4.1).

Компоненты KeyTransRecipientInfo ДОЛЖНЫ определяться следующим образом:

  • в компоненте rid задается ссылка на сертификат открытого ключа получателя. Открытый ключ имеет тип bign-pubkey (см. СТБ П 34.101.45, приложение Г);

  • в компоненте keyEncryptionAlgorithm задается идентификатор bign-keytransport алгоритмов транспорта ключа (см. СТБ П 34.101.45, приложение Г). Параметры алгоритмов опускаются;

  • в компоненте encryptedKey задается токен транспортируемого ключа (см. СТБ П 34.101.45, подраздел 7.1). Для формирования токена используется открытый ключ получателя и долговременные параметры открытого ключа из сертификата получателя. Токен ключа является двоичным словом, длина которого кратна 8. При записи в encryptedKey данное слово естественным образом представляется строкой октетов.

Примечание – При создании токена ключа используется одноразовый ключ k. В СТБ П 34.101.45 (подраздел 5.6) объяснено, что при пересылке ключа шифрования данных сразу нескольким получателям, применяющим одинаковые долговременные параметры, отправитель может использовать один и тот же одноразовый ключ k и тем самым сократить время вычислений.

При применении алгоритмов СТБ П 34.101.45 должны использоваться идентификаторы и параметры алгоритмов, заданные в приложении Г к указанному предстандарту.

Б.5 Использование алгоритмов, определенных в ГОСТ 28147

Определенные в ГОСТ 28147 алгоритмы шифрования в режимах простой замены, гаммирования и гаммирования с обратной связью МОЖНО применять для создания и обработки конвертованных и шифрованных данных. В режиме простой замены РЕКОМЕНДУЕТСЯ шифровать только высокоэнтропийные данные, например ключи. При шифровании в режимах гаммирования и гаммирования с обратной связью ограничения на длину входных данных не накладываются. При шифровании в режиме простой замены длина входных строк октетов ДОЛЖНА быть кратна 8. Для выравнивания данных на границу блока ДОЛЖЕН применяться метод, описанный в 9.5.

Определенный в ГОСТ 28147 алгоритм выработки имитовставки МОЖНО применять для создания и обработки аутентифицируемых данных.

При применении алгоритмов ГОСТ 28147 должны использоваться идентификаторы и параметры алгоритмов, заданные в СТБ П 34.101.50 (приложение Г).

Б.6 Использование протоколов формирования общего ключа

Идентификаторы и параметры протоколов формирования общего ключа, заданных в [5], описаны в СТБ П 34.101.50 (приложение В).

Определенный в [5] протокол одностороннего формирования общего ключа МОЖНО применять для шифрования ключей при создании и обработке конвертованных, аутентифицируемых и аутентифицируемых конвертованных данных. При этом в RecipientInfo ДОЛЖЕН быть выбран компонент ktri типа KeyTransRecipientInfo (см. 9.4.1).

Компоненты KeyTransRecipientInfo ДОЛЖНЫ определяться следующим образом:

в компоненте rid задается ссылка на сертификат открытого ключа получателя. Открытый ключ имеет тип stb1176-bdh-pubkey или stb1176pre-bdh-pubkey (см. приложение В к СТБ П 34.101.50);

в компоненте keyEncryptionAlgorithm задается идентификатор bdh-keytransport протокола транспорта ключа и параметры этого протокола, описанные типом BDHKeytransParams (см. СТБ П 34.101.50, приложение В);

в компоненте encryptedKey задается зашифрованный ключ, описанный типом BDHKeytransEncryptedKey (см. СТБ П 34.101.50, приложение В). При зашифровании используется открытый ключ получателя и долговременные параметры открытого ключа из сертификата получателя.

Библиография

[1] ISO/IEC 9594-8:2008 Information technology – Open System Interconnection – The Directory: Public-key and attribute certificate frameworks (Информационные технологии. Взаимосвязь открытых систем. Директория. Структура сертификатов открытого ключа и атрибутов)

[2] Housley R. Cryptographic Message Syntax (CMS). Request for Comments: 5652, 2009 (Синтаксис криптографических сообщений)

[3] Housley R. Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type. Request for Comments: 5083, 2007 (Аутентифицируемые конвертованные данные синтаксиса криптографических сообщений)

[4] Turner S., Housley R. Cryptographic Message Syntax (CMS) Revocation Information Choices. Request for Comments: 5940, 2010 (Дополнительные способы задания информации об отзыве в синтаксисе криптографических сообщений)

[5] Проект руководящего документа Республики Беларусь "Банковские технологии. Протоколы формирования общего ключа" Мн.: Национальный банк Республики Беларусь, 1997

You can’t perform that action at this time.