Гост эцп ключ

Что делать, если появляется сообщение о запрещении формирования электронной подписи в КриптоПро?

КриптоПро CSP 4.0

VipNet CSP 4.2

https://www.youtube.com/watch?v=ytdevru

С 1 января 2019 года формирование и использование подписи по ГОСТ Р 34.10-2001 запрещено.

Поэтому, начиная с января 2019 года, предстоит переустановка крипто провайдеров у 90% пользователей.

Тем, кто используют Крипто-про версией ниже 4.0 предстоит покупка новых лицензий,А тем у кого стоит VipNet CSP на Windows XP, придется обновлять винду, так как устанавливается и работает на ней с вероятностью 50/50Уже сейчас советуют, всем кто пользуется ЭЦП, проверить версии Ваших криптопровайдеров и обновлять при необходимости, чтобы избежать проблем при выпуске и использовании новых электронно цифровых подписей.

Для криптопро версии 4.0 и Выше подходит следующий usb ключ

Рутокен ЭЦП 2.0 — это многофункциональное аппаратное средство СКЗИ с поддержкой новых стандартов ГОСТ 2012. Средство осуществляет действия кодирования и подписи прямо в закрытом ключе, и данные не выходят за защитные пределы. Средство реализуется в виде USB-ключа и в micro-исполнении, подходящие для использования в планшетках, нетбуках и ноутбуков.

Поддерживается во всех сертифицированных ГОСТ-криптопровайдерах с реализацией подписи на неизвлекаемых ключах. Применяется в информационных системах с высокими требованиями к информационной безопасности: в дистанционном банковском обслуживании и электронном документообороте в государственном секторе, в том числе в системе ЕГАИС.

Ключевые достоинства:- Поддержка новых и старых алгоритмов ГОСТ.- Полная совместимость с Рутокен ЭЦП.- Вычисление подписи за 0,3 секунды.- Срок действия закрытого ключа до 3-х лет.

Характеристики:- Генерация и хранение закрытых ключей без возможности их экспорта.- Поддержка RSA до 2048 бит.- Операционные системы: Microsoft Windows, Apple macOS, GNU/Linux.- Процессорные архитектуры: x86/x64/ARM/Эльбрус/Байкал(MIPS)Аппаратная реализация ГОСТ Р 34.11-2012, ГОСТ Р 34.10-2012, ГОСТ Р 34.10-2001, ГОСТ Р 34.11-94, ГОСТ 28147-89.

В первую очередь следует обратиться в удостоверяющий центр, где был выпущен сертификат электронной подписи, чтобы выпустить сертификат в соответствии с новым ГОСТ Р 34.10-2012.

Согласно письму Федеральной службы безопасности Российской Федерации от 07.09.2018 № 149/7/6-363 возможность использования схемы ЭП, соответствующей ГОСТ Р 34.10-2001 «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи» (далее – ГОСТ-2001), для формирования ЭП продлевается до 31.12.2019. С 1 января 2020 года формирование электронной подписи должно производится по алгоритму ГОСТ Р 34.10-2012.

Выпуск Головным удостоверяющим центром (Минкомсвязью) подчиненных корневых сертификатов для аккредитованных удостоверяющих центров с использованием ГОСТ Р 34.10-2012 начался с июля 2018 года.

Каждый аккредитованный удостоверяющий центр будет решать на свое усмотрение когда переводить пользователей на работу с квалифицированными сертификатами ключей проверки электронной подписи по ГОСТ Р 34.10-2012. Решение принимается исходя из возможностей удостоверяющего центра. Скорее всего, сразу после издания Минкомсвязью корневого сертификата подчиненного удостоверяющего центра по ГОСТ Р 34.10-2012 каждым УЦ будет производиться последовательный перевыпуск пользовательских сертификатов до 31 декабря 2019 года.

Чтобы выпустить сертификат электронной подписи для физического или юридического лица в соответствии с ГОСТ Р 34.10-2012, необходимо обратиться в свой удостоверяющий центр.

Новый стандарт электронной подписи

Подписи, выпущенные по старому ГОСТу, будут работать до 31.12.2019, этой датой ограничен срок действия электронной подписи ГОСТ Р 34.10-2001.

Владельцы подписей, срок которых истекает до 31 декабря 2018 года, могут в рабочем режиме продлевать их по-старому ГОСТ-2001.

Владельцам подписей, срок которых истекает после 1 января 2019 года, необходимо уже продлевать по-новому ГОСТ-2012.

https://www.youtube.com/watch?v=upload

Таким образом, в течение всего 2019 года будут одновременно действовать подписи по старому ГОСТ-2001 и новому ГОСТ-2012.

Услуги по оформлению ЭЦП с новым ГОСТом  

Перейти на сайт

Для чего нужно выбирать сертификат электронной подписи в соответствии с ГОСТ Р 34.10-2012?

Отталкиваясь от выписки из приказа ФСБ России от 31 января 2014 г. № 149/7/1/3-58 «О порядке перехода к использованию новых стандартов электронной подписи и функции хэширования», применение в работе сертификата подписи ГОСТ Р 34.10-2001 для создания подписи позднее 31 декабря 2018 года не разрешается, даже для необходимости создания перечня отзыва сертификатов. С 1 января 2019 года создание электронной подписи обязано выполнятся по новому стандарту ЭЦП ГОСТ 2012.

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

Переход к новшеству от предыдущих стандартов необходимо осуществить до 31 декабря 2018 года включительно, на основе замены ГОСТ Р 34.10-2001:• ГОСТ Р 34.10-2012 с описанием алгоритма электронной подписи;• ГОСТ Р 34.11-2012 с регламентом алгоритма хэширования.

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

ЭЦП ГОСТ 2012

Недопустимо применение схемы подписи на основе ГОСТ Р 34.10-2001, чтобы сформировать электронную подпись после наступления 31 декабря 2018 года. Об этом свидетельствует наличие сведений в выписке из документов ФСБ России, отражающих порядок перехода к новым стандартам ЭЦП и функциям хеширования от 31 января 2014 года № 149/1/3-58.

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

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

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

Всплывающее окно с требованием использовать криптопро гост 2012 CSP 4.0

О потребности смены старой версии на СКЗИ КриптоПро CSP версия 4.0 соответствующий системе перехода к работе с национальным стандартом ГОСТ Р 34.10-2012 в устройствах электронной подписи для данных, не содержащие гос. тайну, в случаях, доступных урегулированию со стороны ФСБ России , отталкиваясь от ныне существующей нормативной правовой базой (выписка из документа ФСБ России от 31.01.

2014 № 149/7/1/3-58), работа с методами подписи ГОСТ Р 34.10-2001 для создания подписи позднее 31 декабря 2018 года не разрешается. Исходя из этого, с 01.01.2019 для создания усиленной квалифицированной электронной подписи, допустима работа только сертифицированных криптосредств, использующих ГОСТ Р 34.10-2012 «Информационная технология.

С 01.10.2017 при использовании сертификатов в «КриптоПро» 3.9 и 4.0 может появляться предупреждение о необходимости перейти на ГОСТ Р 34.10-2012.

Для соответствия законодательству РФ, уже к 01.01.2019 необходимо перейти на ЭП с новым стандартом ГОСТ 2012. Для работы, пока что подходит «КриптоПро» 4.0. Рутокен 2, Рутокен S

Приложение Д (справочное). Распределение сертификатов ключей проверки электронной подписи и САС

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

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

https://www.youtube.com/watch?v=ytcreatorsru

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

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

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

В.2 Принятие данных запроса на сертификат ключа проверки электронной подписи от физического лица

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

В.2.2 Для бизнес-приложений со средней степенью рискаПример – Недорогие/небольшого объема бизнес-приложения по электронному обмену данными или персональные системы по управлению активами.Принятие данных запроса на сертификат должно быть основано на одном или нескольких механизмах идентификации физического лица, подающего заявку на сертификат ключа проверки электронной подписи.

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

В.2.3 Для бизнес-приложений с высокой степенью рискаПример – Частная банковская система.Принятие данных запроса на сертификат должно быть основано на личном присутствии физического лица (или уполномоченного лица), подающего заявку на сертификат ключа проверки электронной подписи, и использовании традиционных деловых практик для идентификации физического лица (или, если это требуется, уполномоченного указанного физического лица).

В.3 Принятие данных запроса на сертификат ключа проверки электронной подписи от юридического лица

В.3.1 Для одноуровневого финансового учрежденияПример – Клиринговые расчетные палаты (например, CHIPS, CHAPS) и системы автоматизированных расчетов центральных банков._______________CHIPS (The Clearing House Interbank Payments System) – частная электронная система денежных переводов в США. CHAPS (The Clearing House Automated Payment System) – система клиринговых расчётов в Великобритании.

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

В.3.2 Для бизнес-клиентов финансового учрежденияПринятие данных запроса на сертификат должно быть основано на личной доставке данных запроса на сертификат двумя или несколькими представителями юридического лица, и на:- заявке на сертификат ключа проверки электронной подписи на фирменном бланке, заверенной подписью и печатью (при необходимости);

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

Д.1 Общая информацияВ этом приложении обсуждаются механизмы распределения сертификатов ключей проверки электронной подписи юридическим или физическим лицам, которые не являются владельцем сертификата, и механизмы распределения САС. Распределение САС может осуществляться с помощью электронных средств или носителей информации, например, CD-ROM или печатных листов.

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

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

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

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

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

– передача единичной записи САС (подписанной УЦ). Этот механизм будет использоваться для обеспечения уведомления о прекращении действия “в реальном времени”, тогда как весь САС будет отправлен на плановой основе в соответствии со временем следующего обновления. Возможна отправка нового (внепланового) САС полностью, когда действие сертификата ключа проверки электронной подписи прекращено.

Введение

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

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

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

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

Настоящий стандарт определяет систему управления сертификатами ключей проверки электронной подписи для использования в сфере финансовой деятельности юридическими и физическими лицами, включающую:- содержание (данные) запроса на сертификат ключа проверки электронной подписи;- типы систем удостоверяющих центров;

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

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

– требования к практикам создания сертификатов ключей проверки электронной подписи и политикам применения сертификатов ключей проверки электронной подписи;- сертификаты атрибутов.В настоящем стандарте не затрагивается создание или транспортировка ключей, используемых для шифрования.Примечание – Использование полужирного шрифта без засечек, такого как CertReqData или CRLEntry, обозначает использование абстрактной синтаксической нотации (ASN.

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

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:ГОСТ Р ИСО/МЭК 8824-1-2001 Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 1. Спецификация основной нотацииГОСТ Р ИСО/МЭК 8824-2-2001 Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 2.

Спецификация информационного объектаГОСТ Р ИСО/МЭК 8824-3-2002 Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 3. Спецификация ограниченияГОСТ Р ИСО/МЭК 8824-4-2003 Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 4. Параметризация спецификации АСН.

1ГОСТ Р ИСО/МЭК 8825-1-2003 Информационная технология. Правила кодирования АСН.1. Часть 1. Спецификация базовых (BER), канонических (CER) и отличительных (DER) правил кодированияГОСТ Р ИСО/МЭК 8825-2-2003 Информационная технология. Правила кодирования АСН.1. Часть 2. Спецификация правил уплотненного кодирования (PER)ГОСТ Р ИСО/МЭК 9594-8-98 Информационная технология.

Взаимосвязь открытых систем. Справочник. Часть 8. Основы аутентификацииПримечание – При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования – на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю “Национальные стандарты”, который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя “Национальные стандарты” за текущий год.

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

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

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

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

3.1 владелецсертификата ключа проверки электронной подписи;владелец сертификата (public key certificate subject): Юридическое или физическое лицо, которому выдан сертификат ключа проверки электронной подписи.

3.2 восстановление действия сертификата (ключа проверки электронной подписи) (public key certificate release): Восстановление удостоверяющим центром действия сертификата ключа проверки электронной подписи, действие которого было приостановлено этим удостоверяющим центром.

3.3 данные запроса на сертификат (ключа проверки электронной подписи) (request data on public key certificate): Подписанная информация в запросе на сертификат ключа проверки электронной подписи, включающая ключ проверки электронной подписи физического или юридического лица, идентификационные данные этого лица и другую информацию, включаемую в сертификат.

3.4 двойной контроль (dual control): Процесс совместного участия двух или более юридических или физических лиц, действующих в общих целях обеспечения защиты важных функций или информации.Примечание – Эти лица несут равную ответственность за обеспечение защиты информации, задействованной в уязвимых операциях. Ни одно из этих лиц в отдельности не может получить доступ к информации (например, криптографическому ключу) или использовать ее.

3.5 доверенный ключ проверки электронной подписи (trusted certification authority public key): Ключ проверки электронной подписи, полученный доверенным образом и используемый для проверки первого сертификата ключа проверки электронной подписи в цепочке сертификатов ключей проверки электронной подписи при проверке цепочки сертификатов.

3.6 журнал аудита (audit journal): Хронологическая запись системной активности, достаточная, чтобы позволить реконструкцию, анализ и изучение последовательности условий и действий, окружающих или приводящих к каждому событию в ходе транзакции от ее начала и до вывода окончательных результатов.

3.7 замена сертификата (ключа проверки электронной подписи) (public key certificate re-key): Процесс, при котором владелец сертификата ключа проверки электронной подписи получает новый сертификат ключа проверки электронной подписи на новый ключ проверки электронной подписи после создания новой пары ключей.

3.8 ключ проверки электронной подписи (public key): Уникальная последовательность символов, однозначно связанная с ключом электронной подписи и предназначенная для проверки подлинности электронной подписи.Примечание – В настоящем стандарте в целях сохранения терминологической преемственности по отношению к действующим национальным правовым и нормативным документам, регулирующих отношения по использованию электронной подписи (например [1, 2]), и опубликованным научно-техническим изданиям установлено, что термины “ключ проверки электронной подписи” и “открытый ключ” являются синонимами.

3.9 ключ электронной подписи (private key): Уникальная последовательность символов, предназначенная для создания электронной подписи.

3.10 ключевая информация (keying material): Данные, необходимые для выполнения криптографических операций, например изготовления ключей.

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

3.12 криптографический ключ (cryptographic key): Параметр, который определяет работу криптографической функции.Примечание – Криптографическая функция позволяет осуществить:- преобразование обычного текста в шифрованный текст и наоборот;- создание ключевой информации;- создание или проверку электронной подписи.

https://www.youtube.com/watch?v=ytpressru

3.13 кросс-сертификация (cross-certification): Процесс, при котором два удостоверяющих центра взаимно подтверждают ключи проверки электронных подписей друг друга.

3.14 модуль ASN.1 (ASN.1 module): Совокупность идентифицируемых видов и значений абстрактной синтаксической нотации (ASN.1).

3.15 отличительное имя (distinguished name): Уникальный идентификатор владельца сертификата ключа проверки электронной подписи.Примечание – Методы определения глобальной уникальности имени выходят за рамки настоящего стандарта.

3.16 пара ключей (key pair): Совокупность ключа проверки электронной подписи и соответствующего ему ключа электронной подписи.

3.17 политика применения сертификатов (ключей проверки электронных подписей) (public key certificate policy): Поименованный набор правил, определяющий порядок применения сертификата ключа проверки электронной подписи, для определенной совокупности и (или) отдельного класса бизнес-приложений с едиными требованиями безопасности.Примечания

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

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

3.18 пользователь сертификата (relying party): Юридическое или физическое лицо, использующее сертификат ключа проверки электронной подписи для проверки электронной подписи.

3.19 приостановка действия сертификата (ключа проверки электронной подписи) (public key certificate suspension): Временное прекращение удостоверяющим центром действия сертификата ключа проверки электронной подписи.

3.20 продление сертификата (ключа проверки электронной подписи) (public key certificate renewal): Процесс, при котором юридическому или физическому лицу выдается новый сертификат существующего ключа проверки электронной подписи с новым сроком действия.

3.21 разделенное знание (split knowledge): Метод хранения криптографического ключа, при котором два (или более) физических или юридических лица по отдельности, имеют части ключа, которые, по отдельности, не дают никаких сведений о результирующем криптографическом ключе.

https://www.youtube.com/watch?v=ytpolicyandsafetyru

3.22 регламент выдачи сертификатов ключей проверки электронных подписей; РВС (public key certification practice statement): Совокупность правил, регулирующих порядок выдачи и управления сертификатами ключей проверки электронных подписей удостоверяющим центром на протяжении их жизненного цикла.

3.23 реестр сертификатов (ключей проверки электронных подписей) (public key certificate register): Совокупность данных, включающая список выданных удостоверяющим центром сертификатов ключей проверки электронных подписей и информацию, содержащуюся в этих сертификатах, а также информацию о датах прекращения действия или аннулирования сертификатов ключей проверки электронных подписей и об основаниях таких прекращений или аннулирований.

3.24 сертификат ключа проверки электронной подписи (public key certificate): Электронный документ или документ на бумажном носителе, выданные удостоверяющим центром либо доверенным лицом удостоверяющего центра и подтверждающие принадлежность ключа проверки электронной подписи владельцу данного сертификата ключа проверки электронной подписи.

3.25 сертификат ключа проверки электронной подписи удостоверяющего центра; сертификатУЦ (certification authority public key certificate): Сертификат ключа проверки электронной подписи, владельцем которого является удостоверяющий центр, чей ключ электронной подписи используется для подписания сертификатов ключей проверки электронной подписи.

3.26 система удостоверяющих центров;система УЦ (certification authority system): Совокупность удостоверяющих центров, которые управляют сертификатами ключей проверки электронных подписей (включая соответствующие им ключи проверки электронных подписей и ключи электронных подписей) на протяжении жизненного цикла сертификата ключа проверки электронной подписи.

3.27 список недействительных сертификатов ключей проверки электронных подписей; САС (public key certificate revocation/non-action list): Список сертификатов ключей проверки электронных подписей, объявленных недействительными.Примечание – Недействительными сертификатами являются сертификаты срок действия которых истек, приостановленные сертификаты и сертификаты, аннулированные по решению суда.

3.28 уведомление по дополнительному каналу (out-of-band notification): Уведомление с использованием средств связи, независимых от основных средств связи.

3.29 удостоверяющий центр; УЦ (certification authority): Юридическое лицо или индивидуальный предприниматель, осуществляющие функции по созданию и выдаче сертификатов ключей проверки электронных подписей, а также иные функции, предусмотренные национальным законодательством.

3.30 управление ключами (key management): Обращение с ключевой информацией и ключами на протяжении их жизненного цикла в соответствии с политикой безопасности.

3.31 часть ключа (key fragment): Фрагмент ключа, переданный на хранение юридическому или физическому лицу для реализации метода разделения знаний.

Приложение В (справочное). Рекомендации по принятию данных запроса на сертификат ключа проверки электронной подписи

4.1 Обзор

Инфраструктура открытых ключей (PKI) – это термин, используемый для описания технической, юридической и коммерческой инфраструктуры, которая делает возможным широкое применение технологии открытого ключа.Технология открытого ключа используется для создания электронной подписи и управления симметричными ключами.

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

Аутентификация ключей проверки электронной подписи является необходимым условием, и поэтому такие ключи находятся в сертификатах ключей проверки электронной подписи. Сертификат ключа проверки электронной подписи содержит ключ проверки электронной подписи и идентификационные данные, а также электронную подпись УЦ. Настоящий стандарт основан на ГОСТ Р ИСО/МЭК 9594-8 в части аутентификации в открытых системах.

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

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

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

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

– переоформление сертификатов с помощью пары вторичных ключей ;- переоформление сертификатов ключей проверки электронной подписи с помощью пары новых первичных ключей ;- уведомление с помощью множества подписанных сертификатов ключей проверки электронной подписи.Указанные методы рассматриваются в Г.2-Г.

Ключ проверки электронной подписи проверяется на действительность вторичным ключом проверки электронной подписи ;- : Первичный сертификат ключа проверки электронной подписи подписывается с использованием первичного ключа электронной подписи ;- : Вторичный сертификат ключа проверки электронной подписи подписывается с использованием вторичного ключа электронной подписи .

Г.2 Уведомление с помощью пары вторичных ключей Когда новый конечный владелец сертификатов () представляет свой ключ проверки электронной подписи () , формирует первичный сертификат ключа проверки электронной подписи , подписанный с помощью первичного ключа электронной подписи , и вторичный сертификат ключа проверки электронной подписи , подписанный с помощью вторичного ключа электронной подписи .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Г.5 Переоформление с помощью очередной пары ключей Когда новый конечный владелец сертификата () представляет свой ключ проверки электронной подписи (), формирует сертификат ключа проверки электронной подписи конечного владельца сертификата , подписанный с помощью первичного ключа электронной подписи .

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

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

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

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

4.3 Удостоверяющий центр

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

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

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

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

В этой системе УЦ головной УЦ является общей точкой доверия для всех пользователей сертификатов.Головной УЦ для связи за пределами своей области ответственности должен кросс-сертифицироваться с УЦ желаемой удаленной области. Проверка цепочки сертификатов предполагает создание последовательности сертификатов ключей проверки электронной подписи от удаленного физического или юридического лица до головного УЦ с помощью кросс-сертифицированного удаленного УЦ.

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

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

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

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

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

5 Системы УЦ

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

5.2.1 Ответственность и характеристики УЦ

а) обеспечение безопасности ключа электронной подписи, связанного с ключом проверки электронной подписи, содержащимся в сертификате ключа проверки электронной подписи УЦ;

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

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

г) создание сертификатов ключа проверки электронной подписи с применением алгоритма электронной подписи к информации, указанной в сертификате ключа проверки электронной подписи;

д) поддержание механизма прекращения действия сертификатов и проверки, приемлемого для владельцев и пользователей сертификатов;

е) создание и распределение САС (см. приложение Д);

ж) создание пар ключей в соответствии с подробным сценарием процедуры создания ключей удостоверяющим центром и требованиями РВС;

з) разработку РВС и обеспечение его доступности для всех юридических и физических лиц;

и) обеспечение уверенности в том, что он владеет и управляет своими ключами электронной подписи;

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

а) имел достаточно ресурсов для поддержания своей деятельности в соответствии со своими обязанностями;

б) был способен в достаточной мере принять свой риск ответственности перед конечными владельцами сертификатов и пользователями сертификатов, как это диктуется политикой применения сертификатов;

в) применял кадровую политику, которая обеспечивает доверие к деятельности УЦ;

г) использовал для реализации функций УЦ средства, удовлетворяющие нормативным требованиям уполномоченных органов. Средства УЦ должны быть соответствующим образом защищены.Примечание – Классы средств электронной подписи и средств УЦ определены в [2]. Необходимый класс разрабатываемых (модернизируемых) средств УЦ определяется заказчиком (разработчиком) средств УЦ на основе [2].

д) обеспечивал доступность своих сертификатов ключей проверки электронной подписи, ключа проверки электронной подписи и САС для пользователей сертификатов;

е) определял и документально оформлял внутренние политики функционирования для области действия УЦ и обеспечивал их доступность заинтересованным лицам;

ж) обеспечивал уверенность в соответствии всем надлежащим нормативным требованиям.Система УЦ должна обеспечить уверенность в том, что обязанности УЦ и ЦР (при его наличии) были определены.

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

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

в) извещать о создании сертификата ключа проверки электронной подписи сторону, указанную в сертификате ключа проверки электронной подписи (при необходимости);

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

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

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

ж) предоставлять своим конечным владельцам сертификатов руководство по безопасному управлению ключом электронной подписи конечного владельца сертификата;

з) информировать конечного владельца сертификата о том, что его работа определяется как скомпрометированная, если его ключ электронной подписи используется каким-либо другим юридическим или физическим лицом;

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

к) в случае компрометации ключа электронной подписи УЦ незамедлительно информировать об этом владельцев и пользователей сертификатов в области действия УЦ;

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

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

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

в) предпринимать действия по обеспечению конфиденциальности ключа электронной подписи для предотвращения несанкционированного использования и компрометации ключа в течение его жизненного цикла;

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

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

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

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

з) обеспечить уровень безопасности, требуемый РВС и определенный соответствующим договорным соглашением;

и) предоставлять точные и полные данные для запроса на сертификат;

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

5.3.1 Создание

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

б) процесс создания ключа проверки электронной подписи/ключа электронной подписи должен обеспечивать уверенность в том, что ключевая информация соответствует требованиям к ключу проверки электронной подписи;

в) только УЦ должен иметь доступ к своему ключу электронной подписи;

https://www.youtube.com/watch?v=ytcopyrightru

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

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