8(495)663-30-34 | 8(495)663-30-73 | 8(495)663-30-93

Замечания и предложения компании «Сигнал-КОМ» к проекту приказа Министерства связи и массовых коммуникаций «Об утверждении формата электронной подписи, обязательного для реализации всеми средствами электронной подписи»

Замечания и предложения компании «Сигнал-КОМ» к проекту приказа Министерства связи и массовых коммуникаций «Об утверждении формата электронной подписи, обязательного для реализации всеми средствами электронной подписи»

В настоящее время на Федеральном портале проектов нормативных правовых актов зарегистрирован проект приказа 01/02/10-17/00074234 «Об утверждении формата электронной подписи, обязательного для реализации всеми средствами электронной подписи», который устанавливает требования к структуре электронной подписи и информации в ней содержащейся. Общественное обсуждение проекта проходит с 19 октября по 02 ноября 2017 года.

Проанализировав предлагаемый текст проекта приказа, специалистами компании «Сигнал-КОМ» были сформулированы ряд замечаний и предложений, а именно:

1. из п.1 необходимо исключить определение неиспользуемых в документе терминов (например, «ключ ЭП», «аккредитация УЦ» и др.);

2. из п.7 необходимо исключить определение неиспользуемых в документе ASN.1-типов (например, BIT STRING, SET и др.);

3. структура ЭП (SignedData), приведённая в п.8, не имеет полного формального описания: необходимо либо привести определение недостающих типов (CMSVersion, DigestAlgorithmIdentifiers, EncapsulatedContentInfo, CertificateSet, RevocationInfoChoices, SignerInfos), либо сослаться на RFC 5652;

4. в п.8 необходимо добавить определение структуры ContentInfo, включающей в себя SignedData (либо дать ссылку на RFC 5652).

5. согласно п.9 «EncapsulatedContentInfo содержит подписываемые данные», т. е. подпись формируется с присоединёнными данными. Такой тип подписи является не самым удобным — в качестве обязательного для реализации варианта предпочтительнее отсоединённая подпись (т. е. не содержащая данных). Либо необходимо сделать обязательными для реализации оба типа подписи;

6. в п.9 для описания поля CertificateSet предлагается следующая формулировка: «В поле CertificateSet должна быть включена информация о сертификате владельца ключа проверки ЭП. В данное поле может быть также включена информация о сертификатах удостоверяющих центров, позволяющая построить цепочку сертификатов». Приведённая в проекте документа формулировка:

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

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

7. в п.9 заполнение поля RevocationInfoChoices предлагается сделать необязательным, поскольку время проверки ЭП подписывающей стороне заранее неизвестно, а информация о статусе сертификата ключа проверки ЭП довольно быстро теряет актуальность — целесообразно возлагать задачу поиска информации о статусе сертификата на проверяющую сторону.

8. в п.9 упоминается subjectKeyIdentifier, таким образом предусматривается вариант подписи без использования сертификата ключа проверки ЭП — предлагается этот вариант исключить, как редко используемый на практике.

Данные замечания и предложения были направлены разработчикам проекта приказа.

23.10.17