Closed bcryptobot closed 2 months ago
И еще одно ограничение п. 8.6 вызывает вопросы:
Список данных о подписантах (компонент
signerInfos
) должен содержать единственный контейнер типаSignerInfo
.
Другими словами, данные должны быть подписаны одной стороной, должен быть единственный подписант.
Данное ограничение блокирует некоторые сценарии использования подписанных данных.
Данное ограничение блокирует некоторые сценарии использования подписанных данных.
Ограничения в п. 8.6 касаются управления подписанными данными исключительно в контексте Bpki. Речь идет о 9 сценариях использования подписанных данных, заданных идентификаторами id-ct-TSTInfo
, ..., bpki-ct-resp
. Другие сценарии за рамками Bpki могут быть реализованы как угодно.
Данные запреты являются весьма ограничительными.
Общая логика профилирования в Bpki -- акцент на совместимость и поэтому ничего лишнего и необязательного. Отсюда запреты на атрибутные сертификаты и вариативность правил идентификации подписанта.
Предлагается снять запреты, разрешив использовать контейнеры SignedData версий 3 и 4.
С другой стороны, при профилировании была допущена ошибка: при использовании идентификаторов подписанных данных, отличных от id-data
, версия SignedData
должна быть не ниже 3.
Поэтому предлагается вместо
- Версия синтаксиса (компонент
version
) должна равняться 1.
писать
- Версия синтаксиса (компонент
version
) должна равняться 3.
Формат подписанных данных определяется типом
SignedData
, установленным в СТБ 34.101.23.В п. 8.6 требуется, чтобы в контейнере
SignedData
была выбрана версия 1 и, таким образом, запрещается:SignerInfo.subjectKeyIdentifier
;id-data
.Данные запреты являются весьма ограничительными. Более того, последний запрет заведомо не может быть выполнен, поскольку в п. 8.6 вводится список разрешенных идентификаторов подписанных данных, и этот список не включает
id-data
.Предлагается снять запреты, разрешив использовать контейнеры
SignedData
версий 3 и 4.