ИЗМЕНЕН
    ПСИБ23 от 02.05.18, МО183-194/08.06.18 ст.859; в силу с 08.06.18


    На основании п. d) ч.(1) ст.36 Закона № 91 от 29.05.2014 года об электронной подписи и электронном документе (Официальный монитор Республики Молдова, 2014 г., № 174-177, ст.397) ПРИКАЗЫВАЮ:
    1. Утвердить Технические нормы в сфере усиленной квалифицированной электронной подписи (прилагаются).
    2. Признать утратившими силу:
    1) Приказ директора Службы информации и безопасности Республики Молдова № 64 от 7.12.2006 „Об утверждении Технических норм в сфере цифровой подписи” (Официальный монитор Республики Молдова, 2007, № 112-116, ст.481);
    2) Приказ Директора Службы информации и безопасности Республики Молдова № 32 от 23.06.2010 „О внесении изменений и дополнений в Приказ Директора Службы информации и безопасности № 64 от 7.12.2006 г.” (Официальный монитор Республики Молдова, 2010 № 110-113, ст. 390).
    3. Контроль за исполнением настоящего приказа возложить на заместителя директора Службы информации и безопасности Республики Молдова господина Александру БАЛТАГУ.
    4. Настоящий приказ вступает в силу со дня опубликования в Официальном мониторе Республики Молдова.

    ЗАМ. ДИРЕКТОРА СЛУЖБЫ
    ИНФОРМАЦИИ И БЕЗОПАСНОСТИ                          Александру БАЛАН

    № 69. Кишинэу, 15 июля 2016 г.

    1. Настоящие Технические нормы разработаны в соответствии с Законом № 91 от 29.05.2014 об электронной подписи и электронном документе и устанавливают нормы и требования соответствия стандартам и рекомендациям в области усиленной квалифицированной электронной подписи, принципы формирования инфраструктуры открытых ключей, создания и управления закрытыми, открытыми ключами и сертификатами открытых ключей, создания и проверки усиленной квалифицированной электронной подписи и фиксирования времени.
    2. Настоящие Технические нормы являются регламентирующим документом в области усиленной квалифицированной электронной подписи и обязательны для аккредитованных поставщиков сертификационных услуг в области применения усиленной квалифицированной электронной подписи, а также для пользователей усиленной квалифицированной электронной подписи.
    3. В настоящем документе используются следующие понятия и сокращения:
    статус сертификата – состояние сертификата открытого ключа в определенный момент времени. Статус сертификата определяется списком отозванных сертификатов;
    функция хеширования – криптографическая функция, которая отвечает следующим условиям: функция является однонаправленной и имеет высокую алгоритмическую сложность для нахождения коллизий;
    фиксирование времени – процедура, осуществляемая путем добавления к электронному документу метки времени таким образом, чтобы исключить возможность изменения документа с сохранением добавленной ранее метки времени;
    CWA (CEN Workshop agreement) – Соглашение рабочей группы Европейского комитета по стандартизации. Справочные тексты опубликованы на сайте www.cenorm.be;
    EAL (Evaluation Assurance Level) – Уровень оценки и обеспечения, числовой уровень, назначенный после окончания оценки, в соответствии с общими критериями проверки безопасности (Common Criteria security evaluation). Справочные тексты опубликованы на сайте www.commoncriteriaportal.org;
    ETSI (Evaluation Telecomunications Standards Institute) – Европейский Институт стандартизации телекоммуникаций. Справочные тексты опубликованы на сайте www.etsi.org;
    FIPS (Federal Information Processing Standard) – Федеральный стандарт по обработке информации. Справочные тексты опубликованы на сайте www.nist.gov;
    IETF (Internet Engineering Task Force) – Рабочая группа инженерии Интернета. Справочные тексты опубликованы на сайте www.ietf.org;
    ISO/IEC (International Organization for Standardization / International Electrotechnical Commission) – Международная организация по стандартизации / Международная комиссия по электротехнике. Официальный сайт www.iso.org;
    ITU-T (International Telecommunication Union Telecommunication Standardization Sector) – стандарт Международного союза электросвязи в области телекоммуникаций. Справочные тексты опубликованы на сайте www.itu.int;
    PKCS (Public Key Cryptography Standards) – криптографические стандарты с открытым ключом. Справочные тексты опубликованы на сайте www.rsalaboratory.com;
    RFC (Request for comments) – рекомендации, утверждающие документы, прошедшие публичный анализ в рамках процесса, согласованного с рабочей группой инженерии Интернета. Справочные тексты опубликованы на сайте www.ietf.org/rfc;
    RSA (Rivest, Shamir, Adleman) – асимметричный криптографический алгоритм цифровой подписи, разработанный исследователями Rivest, Shamir и Adleman. Справочные тексты опубликованы на сайте www.rsalaboratory.com;
    SM – национальный стандарт Республики Молдова;
    TSP(Time-Stamp Protocol) – Протокол метки времени;
    SIM (Subscriber Identitz Module) – модуль идентификации абонента;
    подтверждение достоверности данных и протокол сервера сертификации – процедура подтверждения достоверности и корректности электронных документов, подписанных усиленной квалифицированной электронной подписью, действительности сертификата открытого ключа и обладания или наличия данных.
    4. Открытые и закрытые ключи аккредитованных поставщиков сертификационных услуг в области применения усиленной квалифицированной электронной подписи (далее - поставщик), используемые при создании усиленной квалифицированной электронной подписи, создаются поставщиком, посредством защищенного устройства создания электронной подписи, настроенном в FIPS mode, в соответствии с требованиями стандарта FIPS 140-2 Security Requirements For Cryptographic Modules уровня 3 или 4, или SMV CWA 14169:2008 Устройства для защищенного создания подписи “EAL 4+”, или SM ISO/IEC 19790:2014 Информационные технологии. Методы обеспечения безопасности. Требования безопасности для криптографических модулей.
    5. Открытые и закрытые ключи пользователя усиленной квалифицированной электронной подписи, используемые для создания усиленной квалифицированной электронной подписи, создаются поставщиком посредством защищенного устройства создания электронной подписи, настроенном в соответствии с требованиями стандарта FIPS 140-2 Security Requirements For Cryptographic Modules уровня 3 или 4, или SMV CWA 14169:2008 Устройства для защищенного создания подписи “EAL 4+”, или SM ISO/IEC 19790:2014 Информационных технологий. Методы обеспечения безопасности. Требования безопасности для криптографических модулей. В случае использования защищенного устройства создания электронной подписи на базе SIM, поставщик обеспечивает пользователю усиленной квалифицированной электронной подписи инициацию процедуры создания открытого и закрытого ключа.
    6. Минимальная длина открытого и закрытого ключа составляет:
    1) 2048 бит для алгоритма RSA для пользователей усиленной квалифицированной электронной подписи;
    2) 4096 бит для алгоритма RSA для поставщиков.
    7. Управление открытыми и закрытыми ключами осуществляется в соответствии с рекомендациями IETF RFC 6712 Internet X.509 Public Key Infrastructure - HTTP Transfer for the Certificate Management Protocol (CMP), IETF RFC 4211 Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF).
    8. Срок действия закрытого ключа поставщика составляет:
    1) 10 лет – для поставщиков высшего уровня;
    2) 5 лет – для поставщиков второго уровня.
    9. Начало периода действия закрытого ключа исчисляется с даты и времени начала срока действия сертификата соответствующего ему открытого ключа.
    10. Срок действия сертификата открытого ключа, соответствующего закрытому ключу поставщика, составляет:
    1) 20 лет – для поставщиков высшего уровня;
    2) 10 лет – для поставщиков второго уровня.
    11. Срок действия закрытого ключа сервиса метки времени (TSP), сервиса on-line проверки статуса сертификата (OCSP), сервиса проверки достоверности данных и протокол сервера сертификации (DVCS) и сертификата открытого ключа, соответствующего закрытому ключу сервиса, составляет 5 лет.
    12. Срок действия закрытого ключа пользователя усиленной квалифицированной электронной подписи и сертификата открытого ключа, соответствующего закрытому ключу пользователя электронной подписи, составляет:
    1) до 2 лет включительно – для открытого и закрытого ключа длиной не менее 2048 бит, для алгоритма RSA;
    2) до 3 лет включительно – для открытого и закрытого ключа длиной не менее 3072 бит, для алгоритма RSA;
    3) до 5 лет включительно – для открытого и закрытого ключа длиной не менее 4096 бит, для алгоритма RSA.
    [Пкт.12 в редакции ПСИБ23 от 02.05.18, МО183-194/08.06.18 ст.859; в силу с 08.06.18]
    13. Закрытые ключи поставщиков и пользователей усиленной квалифицированной электронной подписи хранятся на материальных носителях, реализующих криптографические функции – защищенное устройство создания электронной подписи. Криптографические операции подписания с использованием закрытого ключа должны осуществляться на микрочипе материального носителя.
    14. Материальный носитель, содержащий закрытый ключ поставщика и пользователя усиленной квалифицированной электронной подписи, должен соответствовать требованиям стандарта FIPS 140-2 Security Requirements For Cryptographic Modules уровня 3 или 4, или SMV CWA 14169:2008 Устройства для защищенного создания подписи “EAL 4+”, или SM ISO/IEC 19790:2014 Информационные технологии. Методы обеспечения безопасности. Требования безопасности для криптографических модулей.
    15. Материальный носитель, содержащий закрытый ключ пользователя усиленной квалифицированной электронной подписи, дополнительно к стандартам перечисленным в пункте 14 из данных Технических норм, должен соответствовать и требованиям стандарта PKCS#15 Cryptographic Token Information Format Standard.
    16. Плановая смена открытых и закрытых ключей поставщика осуществляется не ранее 14 дней до истечения срока действия закрытого ключа и не позднее истечения срока действия закрытого ключа.
    17. Внеплановая смена открытых и закрытых ключей поставщика осуществляется в случае компрометации или угрозы компрометации закрытого ключа.
    18. В рамках процедуры смены закрытого и открытого ключей поставщика высшего уровня поставщик:
    1) создает новую пару ключей (закрытый и открытый);
    2) создает сертификат открытого ключа в форме электронного документа, содержащий новый открытый ключ, и подписывает его усиленной квалифицированной электронной подписью с использованием нового закрытого ключа.
    19. В рамках процедуры смены открытых и закрытых ключей поставщика второго уровня поставщик:
    1) создает новую пару ключей (закрытый и открытый);
    2) сертифицирует новый открытый ключ у поставщика высшего уровня.
    20. Старый закрытый ключ поставщика перестает действовать с даты создания сертификата нового открытого ключа. Сертификат старого открытого ключа поставщика продолжает действовать до истечения срока его действия.
    21. По истечении срока действия закрытого ключа он используется до истечения срока действия сертификата открытого ключа, соответствующего этому закрытому ключу только для подписания списка отозванных сертификатов.
    22. По истечении срока действия сертификата открытого ключа, соответствующего закрытому ключу, отмеченному в пункте 21 из данных Технических норм, закрытый ключ уничтожается.
    23. Процедура смены открытых и закрытых ключей пользователей усиленной квалифицированной электронной подписи определяется поставщиком усиленной квалифицированной электронной подписи в соответствии с рекомендациями IETF RFC 6712 Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP), IETF RFC 4211 Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) или IETF. RFC 5967 The application/pkcs10 Media Type.
    24. Процедуры сертификации открытых ключей (идентификация, аутентификация и регистрация пользователей усиленной квалифицированной электронной подписи, прием заявлений на сертификацию открытых ключей, создание сертификатов открытых ключей, приостановление, возобновление действия и отзыв сертификатов) осуществляются в соответствии с рекомендацией IETF RFC 3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework.
    25. Управление сертификатами открытых ключей осуществляется в соответствии с рекомендациями IETF RFC 6712 Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP), IETF RFC 4211 Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF).
    26. Заявления на сертификацию открытых ключей в форме электронного документа создаются в соответствии со стандартом IETF RFC 5967 The application/pkcs10 Media Type или IETF RFC 4211 Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF).
    27. Сертификаты открытых ключей в форме электронного документа должны соответствовать требованиям стандарта ITU-T X.509, версии 3, стандарта SMV ISO CEI 9594-8:2014 Информационные технологии. Взаимодействие открытых систем. Направляющие линии. Структура сертификата открытых ключей и атрибута или рекомендации IETF RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profil, ETF RFC 6818 Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profil и IETF RFC 3739 Qualified Certificates Profile. Структура сертификата открытых ключей поставщика и пользователя усиленной квалифицированной электронной подписи представлены в приложениях 1 и 2 к настоящим Техническим нормам.
    28. Списки отозванных сертификатов должны соответствовать требованиям стандарта ITU-T X.509, версия 2, стандарта SM ISO CEI 9594-8:2014 Информационные технологии. Взаимодействие открытых систем. Направляющие линии. Структура сертификата открытых ключей и атрибута или рекомендации IETF RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profil, ETF RFC 6818 Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profil и IETF RFC 3739 Qualified Certificates Profile. Структура сертификата открытых ключей поставщика и пользователя усиленной квалифицированной электронной подписи представлены в приложении № 3 к настоящим Техническим нормам.
    29. Временем приостановления или возобновления действия сертификата открытого ключа считается время опубликования (выпуска) обновленного списка отозванных сертификатов (время, указанное в поле this Update).
    30. Статус сертификата открытого ключа определяется в соответствии с одной из следующих рекомендаций:
    1) IETF RFC 6960 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP;
    2) IETF RFC 2585 Internet X.509 Public Key Infrastructure Operational Protocols: FTP, HTTP;
    3) IETF RFC 3494 Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status;
    4) IETF RFC 4523 Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates.
    31. Структура сертификата сервиса on-line проверки статуса сертификата (OCSP) представлена в приложении №4 к настоящим Техническим нормам.
    32. Усиленная квалифицированная электронная подпись поставщика создается посредством защищенного устройства создания электронной подписи, настроенного в FIPS mode, в соответствии с требованиями стандарта SMV CWA 14170:2007 Требования безопасности для приложений для создания электронной подписи.
    33. Усиленная квалифицированная электронная подпись пользователя создается посредством защищенного устройства создания электронной подписи и продукта для электронной подписи в соответствии с требованиями стандарта SMV CWA 14170:2007 Требования безопасности для приложений для создания электронной подписи.
    34. Безопасная проверка усиленной квалифицированной электронной подписи осуществляется посредством устройства проверки электронной подписи и/или продукта для электронной подписи в соответствии с требованиями стандарта SMV CWA 14171:2007 Общее руководство для проверки электронной подписи.
    35. Формат усиленной квалифицированной электронной подписи должен соответствовать требованиям стандарта PKCS#7 Cryptographic Message Syntax Standard и/или:
    1) SM ETSI TS 101 903 V1.4.2:2014 Электронная подпись и инфраструктуры (ESI). Усиленная электронная подпись XML (XAdES);
    2) SM ETSI TS 102 778-1 V1.1.1:2014 Электронная подпись и инфраструктуры (ESI). Профили усиленной электронной подписи PDF. Часть 1: Обзор PAdES – рамки для PAdES, ETSI TS 102 778-2 V1.2.1 :2009 Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles; Part 2: PAdES Basic - Profile based on ISO 32000-1, ETSI TS 102 778-3 V1.2.1:2010 Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles; Part 3: PAdES Enhanced - PAdES-BES and PAdES-EPES Profiles, ETSI TS 102 778-4 V1.1.2:2009 Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles; Part 4: PAdES Long Term - PAdES LTV Profile, ETSI TS 102 778-5 V1.1.2:2009, Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles; Part 5: PAdES for XML Content - Profiles for XAdES signatures, ETSI TS 102 778-6 V1.1.1:2010 Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles; Part 6: Visual Representations of Electronic Signatures.
    36. Алгоритмы создания и проверки усиленной квалифицированной электронной подписи должны соответствовать требованиям одного из следующих стандартов и рекомендаций:
    1) SM ISO/CEI 9796-2:2013 Информационные технологии. Методы обеспечения безопасности. Схемы цифровой подписи, позволяющие восстанавливать сообщения. Часть 2: Механизмы, основанные на факторизации целого числа; SM ISO/CEI 9796-3:2013 Информационные технологии. Методы защиты. Схемы цифровой сигнатуры, позволяющие восстанавливать сообщения. Часть 3: Механизмы, основанные на дискретном логарифме;
    2) SM ISO/CEI 14888-1:2011 Информационные технологии. Методы защиты. Цифровые подписи с приложением. Часть 1: Общие положения; SM ISO/CEI 14888-2:2011 Информационные технологии. Методы защиты. Цифровые подписи с приложением. Часть 2: Механизмы на основе идентификаторов; SM ISO/CEI 14888-3:2013 Информационные технологии. Методы защиты. Цифровые подписи с приложением. Часть 3: Механизмы на основе сертификатов;
    3) IETF RFC 3447 Public-Key Cryptography Standards PKCS#1: RSA Cryptography Specifications, версия 2.1;
    4) FIPS Publication 186-3 Digital Signature Standard (DSS) или SM SR ISO/CEI 14888-2-2011 Информационные технологи. Методы обеспечения безопасности. Цифровые подписи с приложениями. Часть 2: Механизмы, основанные на разложении на множители целых чисел.
    37. Поставщики должны использовать функцию хеширования SHA-256.
    38. Алгоритмы функции хеширования должны соответствовать требованиям одного из следующих стандартов:
    1) SM ISO/CEI 10118-1:2006 Информационные технологии. Методы обеспечения защиты. Хеш-функции. Часть 1: Общие положения; SM ISO/CEI 10118-2:2013 Информационные технологии. Методы обеспечения защиты. Хеш-функции. Часть 2: Хеш-функции с использованием алгоритма шифрования n-битными блоками; SM ISO/CEI 10118-3:2006 Информационные технологии. Методы обеспечения защиты. Хэш-функции. Часть 3: Выделенные хэш-функции; SM ISO/CEI 10118-4:2006 Информационные технологии. Методы защиты. Хэш-функции. Часть     4: Хэш-функции, применяющие модульную арифметику;
    2) FIPS Publication 180-3 Secure Hash Standard (SHS) или SM ISO/CEI 10118-3:2006 Information technology – Security techniques – Hash-functions – Part 3: Dedicated hash-functions.
    39. Добавление метки времени осуществляется в соответствии с требованиями рекомендации IETF RFC 3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) , RFC 5816 ESSCertIDv2 Update for RFC 3161.
    40. Синхронизация времени служб сертификации, в том числе программных и технических средств согласно предназначению, осуществляется в соответствии с рекомендацией IETF RFC 5905: Network Time Protokol Version 4: Protocol and Algoritms Specification.
    41. Структура сертификата открытого ключа службы метки времени (TSP) представлена в приложении №4 к настоящим Техническим нормам.
    42. Подтверждение достоверности данных и протокол сервера сертификации осуществляется в соответствии с требованиями рекомендации IETF RFC 3029 Data Validation and Certification Server Protocols (DVCS).
    43. Структура сертификата службы подтверждения достоверности данных и протокол сервера сертификации (DVCS) представлены в приложении №4 к настоящим Техническим нормам.

    приложение №1

    приложение №2

    приложение №3

    приложение №4