ГОСТ Р ИСО 9735-9-2016 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 9. Сообщение системы управления ключами защиты и сертификатами (тип сообщения - KEYMAN)

ГОСТ Р ИСО 9735-9-2016

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ЭЛЕКТРОННЫЙ ОБМЕН ДАННЫМИ В УПРАВЛЕНИИ, ТОРГОВЛЕ И НА ТРАНСПОРТЕ (EDIFACT)

Синтаксические правила для прикладного уровня (версия 4, редакция 1)

Часть 9

Сообщение системы управления ключами защиты и сертификатами (тип сообщения - KEYMAN)

Electronic data interchange for administration, commerce and transport (EDIFACT). Application level syntax rules (Syntax version number 4, Syntax release number 1). Part 9. Security key and certificate management message (message type - KEYMAN)

ОКС 35.240.60

Дата введения 2017-09-01

Предисловие

1 ПОДГОТОВЛЕН Автономной некоммерческой организацией "Институт безопасности труда" (АНО "ИБТ") на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 55 "Терминология, элементы данных и документация в бизнес-процессах и электронной торговле"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 30 ноября 2016 г. N 1901-ст

4 Настоящий стандарт идентичен стандарту ИСО 9735-9:2002* "Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 9. Сообщение системы управления ключами защиты и сертификатами (тип сообщения - KEYMAN)" [ISO 9735-9:2002 "Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4, Syntax release number: 1) - Part 9: Security key and certificate management message (message type - KEYMAN)", IDT]

________________

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

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

5 ВВЕДЕН ВПЕРВЫЕ

6 ПЕРЕИЗДАНИЕ. Ноябрь 2018 г.

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

Настоящий стандарт включает в себя правила прикладного уровня для структурирования данных в рамках обмена электронными сообщениями в открытой среде с учетом требований пакетной обработки. Эти правила утверждены Европейской экономической комиссией ООН (UN/ECE) в качестве синтаксических правил организации электронного обмена данными (Electronic Data Interchange, EDI) в управлении, торговле и на транспорте (EDIFACT) и являются частью Каталога ООН по информационному обмену в сфере торговли (UNTDID), который содержит также рекомендации по разработке сообщений пакетного и интерактивного обмена.

Спецификации и протоколы обмена сообщениями в рамках настоящего стандарта не рассматриваются.

Настоящий стандарт - это новая часть, добавленная в ИСО 9735. Она создает дополнительную возможность управления секретными ключами и сертификатами.

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

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

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

Приведенные ниже нормативные документы* содержат положения, на которые даются ссылки в настоящем тексте и которые, следовательно, становятся положениями настоящего стандарта. Для датированных ссылок применимо только указываемое издание: никакие его последующие изменения или редакции не применимы. Однако участникам договоров, в которых использован настоящий стандарт, рекомендуется изучить возможность применения самых последних изданий ссылочных документов, указанных ниже. Применительно к недатированным ссылочным документам (с плавающими ссылками) действующим остается самое последнее издание нормативного документа. Членами ИСО и МЭК ведутся реестры действующих международных стандартов.

_______________

* Таблицу соответствия национальных стандартов международным см. по ссылке. - .

ISO 9735-1:2002, Electronic data interchange for administration, commerce and transport (EDIFACT). Application level syntax rules (Syntax version number 4, Syntax release number 1). Part 1. Syntax rules common to all parts [Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 1. Синтаксические правила, общие для всех частей]

ISO 9735-2:2002, Electronic data interchange for administration, commerce and transport (EDIFACT). Application level syntax rules (Syntax version number 4, Syntax release number 1). Part 2. Syntax rules specific to batch EDI [Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 2. Специфика синтаксических правил для пакетного EDI]

ISO 9735-5:2002, Electronic data interchange for administration, commerce and transport (EDIFACT). Application level syntax rules (Syntax version number 4, Syntax release number 1). Part 5. Security rules for batch EDI (authenticity, integrity and non-repudiation of origin) [Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 5. Правила безопасности для пакетного EDI (подлинность, целостность и невозможность отказа отправителя от авторства сообщения]

ISO 9735-10:2002, Electronic data interchange for administration, commerce and transport (EDIFACT). Application level syntax rules (Syntax version number 4, Syntax release number 2). Part 10: Syntax service directories [Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 10. Каталоги синтаксической службы]

________________

Заменен на ISO 9735-10:2014.

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

В настоящем стандарте применены термины и определения, приведенные в ИСО 9735-1.

4 Соответствие настоящему стандарту

Для соответствия обмена требованиям настоящего стандарта в его обязательном элементе 0002 (номер версии синтаксических правил) следует использовать номер версии "4", а в условно-обязательном элементе данных 0076 (номер редакции синтаксических правил) - номер редакции "01", причем каждый из этих номеров появляется в сегменте UNB (заголовок обмена); однако в обменах, где продолжает использоваться синтаксис, определенный в более ранних версиях, для различения соответствующих синтаксических правил друг от друга и от правил, определенных в настоящем стандарте, должны использовать следующие номера версий:

- ИСО 9735:1988 - номер версии синтаксических правил: 1;

- ИСО 9735:1988 (перепечатанный с изменениями в 1990 г.) - номер версии синтаксических правил: 2;

- ИСО 9735:1988 и его Изменение 1:1992 - номер версии синтаксических правил: 3;

- ИСО 9735:1998 - номер версии синтаксических правил: 4.

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

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

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

Соответствие требованиям настоящего стандарта предполагает обязательное соответствие частям 1, 2, 5 и 10 ИСО 9735.

Положения смежных стандартов, на которые делается ссылка в настоящем стандарте, являются составными элементами критериев соответствия.

5 Правила использования ключа защиты и сообщения для управления сертификатами

5.1 Функциональное назначение

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

5.2 Сфера применения

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

5.3 Принципы использования управляющего сообщения

Управляющее сообщение может быть использовано для запроса или предоставления ключей защиты, сертификатов или маршрутов сертификации (в том числе для запрашивания различных операций управления ключами и сертификатами - например, операций обновления, замены или аннулирования сертификатов, а также предоставления дополнительной информации - к примеру, о статусе сертификата); это сообщение может быть использовано и для представления перечней сертификатов (например, с целью указания тех из них, которые признаны недействительными). Сообщение типа KEYMAN может быть защищено посредством использования групп сегментов заголовка и концевика защиты. Структурные схемы таких групп сегментов определены в ИСО 9735-5.

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

a) запрашивания операций, связанных с обработкой ключей и сертификатов;

b) предоставления ключей, сертификатов и относящейся к ним информации.

5.4 Определение сообщения

5.4.1 Детализация сегмента данных

5.4.2 Указатель сегментов данных

Таблица 1 - Перечень сегментов

Приложение А
(справочное)

Функции сообщения KEYMAN

А.1 Введение

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

- мандат;

- открытый ключ;

- отметки времени;

- цифровая подпись.

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

А.2 Регистрационные функции управления ключами

А.2.1 Предъявление к регистрации

Цель этой функции состоит в представлении для регистрации полного или частичного контента сертификата.

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

А.2.2 Запрос пары асимметричных ключей

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

А.3 Сертификационные функции управления ключами

А.3.1 Запрос сертификата

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

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

Тем не менее, если сообщение использовано источником для пересылки своего открытого ключа, у него должна существовать возможность подписи сообщения соответствующим секретным ключом даже в том случае, когда еще нет метки для открытого ключа. Такая ситуация называется самосертификация; она требует использования групп сегментов заголовка и концевика системы защиты. Для указания на самосертифицированный ключ определенная в ИСО 9735-5 группа сегментов заголовка защиты должна содержать сертификат, созданный пользователем для своего закрытого ключа. Хотя самосертифицированный открытый ключ не является для принимающей стороны доказательством подлинности его пользователя, для сертификационного органа он свидетельствует о том, что владелец открытого ключа располагает надлежащим закрытым ключом.

А.3.2 Запрос на обновление сертификата

Цель запроса - продление (или обновление) имеющегося сертификата.

Это делается для увеличения периода использования текущего действующего ключа, срок сертификата которого в скором времени истекает. Запрос на обновление должен быть подписан закрытым ключом с сертификатом, подлежащим обновлению, с использованием групп сегментов заголовка и концевика защиты в рамках обмена EDIFACT, описанного в ИСО 9735-5.

А.3.3 Запрос на замену сертификата

Цель запроса состоит в замене имеющегося сертификата на новый, с другим открытым ключом и при необходимости - с дополнительными информационными возможностями. Запрос должен быть подписан в соответствии с действующей политикой управления ключами и с использованием определенных в ИСО 9735-5 групп сегментов заголовка и концевика защиты в рамках обмена EDIFACT.

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

А.3.4 Запрос сертификата или маршрута сертификации

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

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

А.3.5 Предоставление сертификата

Цель этой процедуры состоит в отправке существующего или продленного сертификата по предварительному запросу или без такового.

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

А.3.6 Запрос статуса сертификата

Цель - получение сведений о текущем статусе конкретного сертификата.

А.3.7 Уведомление о статусе сертификата

Цель - предоставление информации о статусе конкретного сертификата запрашивающей стороне.

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

А.3.8 Запрос на проверку подлинности сертификата

Этот запрос должен пересылаться в сертификационный орган для осуществления контроля подлинности существующего сертификата.

Запрос касается сертификатов, относящихся к другим сферам безопасности (то есть выпускаемых иными СА), которые могут быть недоступны для контроля пользователем.

А.3.9 Уведомление о проверке подлинности сертификата

Это ответ на запрос проверки подлинности сертификата. Рекомендуется защищать данное уведомление посредством обеспечения невозможности отказа источника от авторства сообщения.

А.4 Ликвидационные функции управления ключами

А.4.1 Запрос на аннулирование

Цель состоит в запросе аннулирования (изменения статуса "действительный" на "недействительный") сертификата запрашивающей стороны: например, из-за компрометации закрытого ключа; смены СА пользователя; замены исходного сертификата; прекращения использования сертификата (например, вследствие увольнения пользователя из компании) или по иной причине. При этом, по возможности, следует использовать процедуру аутентификации. Рассматриваемая функция может требовать отдельного канала связи и охватывать случаи потери пользователем своего закрытого ключа.

А.4.2 Подтверждение аннулирования

Цель этого сообщения - подтверждение факта аннулирования запрошенного сертификата.

Рекомендуется защищать данное уведомление посредством обеспечения невозможности отказа источника от авторства сообщения.

А.4.3 Запрос списка аннулирования

Цель - получение полного или частичного списка аннулированных сертификатов.

А.4.4 Предоставление списка аннулирования

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

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

А.5 Запрос предупреждения

Цель этого запроса состоит в активизации тревожного сигнала относительно сертификата одной из сторон взаимодействия.

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

А.6 Предоставление маршрута сертификации

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

А.7 Генерирование и транспортирование симметричных ключей

А.7.1 Запрос симметричного ключа

Цель запроса состоит в получении симметричных ключей для шифрования данных или ключей шифрования ключей. Поскольку предоставление таких ключей требует предварительного установления связи между двумя взаимодействующими сторонами, в том случае, когда методы открытых ключей не применяются, необходима аутентификация инициатора запроса с помощью ключа шифрования ключей (KЕK - key encrypting key); данный ключ используют для обеспечения конфиденциальности другого ключа.

А.7.2 Доставка симметричных ключей

Цель данного сообщения - предоставление симметричных ключей по предварительному запросу или без такового.

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

А.8 Прекращение действия ключа

А.8.1 Запрос на прекращение действия симметричного или асимметричного ключа

Цель состоит в прекращении действия существующего симметричного или асимметричного ключа (если сертификаты не используют), например вследствие его компрометации, замены исходного ключа, смены сертификационного органа пользователя; прекращения использования ключа (например, из-за увольнения пользователя из компании) или по иной причине. Рекомендуется обезопасить рассматриваемый запрос, используя для аутентификации существующие ключи.

А.8.2 Подтверждение прекращения действия ключа

Цель состоит в уведомлении пользователей о том, что некоторые конкретные ключи признаны недействительными.

Примечание - Ниже перечислены функции, которые не поддерживаются сообщением типа KEYMAN:

- автономные функции генерирования временных меток (для них требуется отдельное сообщение, например типа AUTACK);

- функции квитирования сообщений и уведомления об ошибках, относящиеся к принятым сообщениям типа KEYMAN; в данном случае требуется использование других типов сообщений (например, AUTACK или CONTRL).

Приложение В
(справочное)

Методы защиты, применимые к сообщениям типа KEYMAN

Настоящее приложение содержит рекомендации по минимальной и максимальной степеням защиты сообщений с помощью сегментов заголовка/концевика (Н/Т) службы защиты, как описано в ИСО 9735-5, для использования применительно к каждой функции управления ключами (KEYMAN).

Таблица В.1 - Уровни обеспечения безопасности с помощью сегментов служб защиты

Приложение С
(справочное)

Использование групп сегментов в сообщениях типа KEYMAN

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

Таблица С.1 - Группы сегментов для формирования запросов

Таблица С.2 - Группы сегментов для функций доставки или уведомления

Приложение D
(справочное)

Модель для управления ключами

D.1 Введение

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

Рисунок D.1 - Модель управления ключами

Основные условия данной модели - обеспечение безопасности посредством использования методов защиты с открытыми ключами и соответствие архитектуры базовому стандарту ITU/TS Х.509.

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

Сертификационный орган соединен по защищенным каналам связи с целым рядом регистрационных органов (RA), доступных любому регистрирующемуся пользователю. Факт регистрации подтвержден сертификатом, выпущенным СА по запросу того или иного RA. После такого подтверждения информация о пользователях (их сертификаты) становится доступной в каталоге (DIR). Кроме того, возможна регистрация многочисленных доверенных третьих сторон (ТТР) и пользователей, предлагающих специальные услуги.

D.2 Конечный пользователь U

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

D.3 Регистрационный орган RA

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

D.4 Сертификационный орган СА

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

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

D.5 Каталог DIR

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

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

D.6 Услуги доверительных третьих сторон DIR

Доверительная третья сторона ТТР может предоставлять целый ряд дополнительных услуг, например формирование отметок времени. Применительно к электронному обмену данными это могут быть следующие службы:

- независимое штемпелевание;

- сертификация характеристик;

- нотариальные действия;

- репозиторий документов;

- обеспечение невозможности отказа отправителя от авторства сообщения;

- перевод сертификатов с заверением.

Приложение Е
(справочное)

Примеры управления ключами и сертификатами

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

Е.1 Запрос на аннулирование

Е.1.1 Описание ситуации

Сертификат, выпущенный ранее сертификационным органом СА2 для сотрудника Е1 учреждения О1, аннулирован этим учреждением по причине увольнения сотрудника 31 декабря 1996 г., в полдень по Гринвичу. Это сообщение организации, адресуемой сертификационному органу, должно быть снабжено электронной подписью, обеспечивающей невозможность отказа источника от авторства сообщения, обычным способом, с использованием групп сегментов заголовка и концевика защиты, как описано в стандарте ИСО 9735-5. В ответ на это сообщение учреждением О1 может быть получено подтверждение аннулирования сертификата от сертификационного органа СА2.

Е.1.2 Детализация системы обеспечения безопасности

Е.2 Запрос на прекращение действия симметричного ключа

Е.2.1 Описание ситуации

Организация О1 просит организацию О2 остановить использование общего симметричного ключа K1, поскольку он был заменен. Сообщение, соответствующее этому запросу, должно быть обеспечено проверкой подлинности источника обычным способом - с использованием групп сегментов заголовка и концевика защиты, как описано в ИСО 9735-5, с помощью другого предварительно согласованного симметричного ключа. В ответ на это сообщение может последовать подтверждение прекращения действия указанного в запросе ключа от организации О2 организации О1.

Е.2.2 Детализация защиты

Е.3 Предоставление сертификата или маршрута сертификации

Е.3.1 Описание ситуации

Данное сообщение от сертификационного органа СА2 организации О1 направлено в ответ на предварительный запрос маршрута сертификации от этой организации, касающийся сертификата организации О2. В рассматриваемом примере и СА2, и сертификационный орган СА3 организации О2 удостоверяются в двухуровневой иерархии сертификационным органом СА1. Запросное сообщение может присутствовать в явной форме в сегменте USX, размещенном между сегментами USE и USF.

Все метки времени сертификатов указывают полночь по Гринвичу, причем сертификат верхнего уровня сгенерирован 1 декабря 1996 г. на 10-летний срок, начинающийся с 1 января 1997 г., а пользовательский сертификат сгенерирован 1 февраля 1997 г. на двухлетний срок, начинающийся с 1 марта 1997 г. Открытые ключи СА1, СА3 и О2 имеют длину 2048, 1024 и 512 соответственно. Все открытые ключи представляют собой открытую экспоненту 10001.

Е.3.2 Детализация защиты

Е.4 Предоставление симметричного ключа

Е.4.1 Описание ситуации

Организация О2 предоставляет организации О1 симметричный ключ, зашифрованный по предварительному согласию ключом KEK1, в ответ на предшествующий запрос симметричного ключа организацией О1. Запросное сообщение может быть сформировано в явном виде путем вставки сегмента USX между сегментами USE и USF.

Е.4.2 Детализация защиты

Приложение ДА
(справочное)

Сведения о соответствии ссылочных международных стандартов национальным стандартам

Таблица ДА.1

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

Электронный текст документа

и сверен по:

, 2018