Новости 
База знаний 
Документация 
Форум 
ЛК УВ 
Назад
При формировании ЭП всех видов должны использоваться алгоритмы, представленные в таблице 3.
Таблица 3 – Алгоритмы
|
Наименование |
URI |
|
|
Расчёт хеш-суммы, 256 бит |
ГОСТ Р 34.11-2012 |
urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256 |
|
Формирование подписи по алгоритму ГОСТ 34.10-2012, 256 бит |
ГОСТ Р 34.10-2012 |
urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256 |
|
Канонизация (для XMLDSig) |
Exclusive XML Canonicalization от 18 июля 2002 |
|
| Дополнительная трансформация[1] (для XMLDSig) |
Нормализация СМЭВ |
[1] Описание алгоритма трансформации приведено в приложении Приложение А к настоящему документу. Образцовая реализация алгоритма трансформации приведена в приложении Приложение Г к настоящему документу
Далее по тексту этого раздела, если имя элемента указано без пространства имён, подразумевается пространство имён urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.X.
6.3.1. Подписи в формате PKCS#7
Формат PKCS#7 используется для подписания файлов, вложенных в сообщения.
Используется версия 1.5 спецификации PKCS#7 (RFC-2315).
На формат подписи накладываются следующие ограничения:
- Для корневого элемента ContentInfo единственный допустимый contentType - SignedData.
- Подпись должна быть detached (т.е. для элемента SignedData/contentInfo/contentType единственное допустимое значение - 1.2.840.113549.1.7.1, а элемент SignedData/contentInfo/content должен отсутствовать).
- Для вычисления message digest разрешён алгоритм ГОСТ Р 34.11-2012 (длина выхода 256 бит).
- Для генерации ЭП разрешён алгоритм ГОСТ Р 34.10-2012.
- Разрешено применять только X-509 сертификаты. Сертификаты PKCS#6 запрещены.
- Запрещено размещать более одной ЭП в PKCS#7-криптосообщении.
- В элементе SignerInfo должны присутствовать следующие authenticated attributes:
- contentType (1.2.840.113549.1.9.3), всегда имеет значение 1.2.840.113549.1.7.1.
- messageDigest (1.2.840.113549.1.9.4), содержит ГОСТ-digest подписываемого файла.
- В формируемой подписи authenticated attributes должны быть упорядочены согласно формату RFC 5652. Пример структуры порядка:
- 1.2.840.113549.1.9.3
- 1.2.840.113549.1.9.5
- 1.2.840.113549.1.9.4
На стороне УВ рекомендуется использовать библиотеку Bouncy Castle, которая позволяет исключить ошибки проверки подписи в части неверного порядка атрибутов при условии, что перед отправкой в СМЭВ отправитель сообщения сформировал верный порядок и корректно был рассчитан хэш.
Более формально большая часть данных ограничений описана в профиле формата PKCS#7, приложение В. В профиле также отражён тот факт, что в данном контексте формат PKCS#7 используется только для передачи ЭП и не используется для передачи зашифрованных данных и CRL. Профиль использует типы, определённые в стандарте PKCS#9 (RFC-2985).
