В настоящее время на Федеральном портале проектов нормативных правовых актов зарегистрирован проект приказа 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, таким образом предусматривается вариант подписи без использования сертификата ключа проверки ЭП — предлагается этот вариант исключить, как редко используемый на практике.
Данные замечания и предложения были направлены разработчикам проекта приказа.