А что странного, Госуслуги не могут использовать Microsoft?

Берём таймаут.

В стандарте другой пример, только с подписанными атрибутами.

Тем не менее, в ТК26 CMS была другая формулировка, с явным требованием использования алгоритма открытого ключа, в окончательном стандарте она изменена (с отсылкой на алгоритмы подписей в сертификатах).
Поэтому при противоречии основного текста и пример надо определиться, чему отдавать приоритет (может, пример тупо перекочевал из проектов в ТК26).
Я лично отдаю общему случаю (текст).
А пример, возможно, справедлив только для конкретного значения messageDigest, поскольку нигде не оговаривается обратное :)))

Что касается используется во всем мире: возможно, это дань совместимости с pkcs #7, где использовался термин digest encryption algorithm, а не signature algorithm.
В rfc на CMS, мне кажется, неспроста это поменяли. Как и в стандарте.
Пример из коробки: explorer.exe из windows 10 1909 имеет цифровую подпись с oid RSA в основной подписи и sha256RSA - в timestamp, т.е. встретить подпись
in the wild с таким сочетанием алгоритмов - ненулевая. И, повторюсь, rfc этого не запрещает.

Возможно, при проверке подписи стоило бы учитывать оба варианта. Как раз в целях совместимости. Поскольку есть ПО от КриптоПро, с использованием которого подобная проверка до сих пор проходит успешно.

И, кажется, в в подготовке текста стандарта принимали участие сотрудники КриптоПро. Вероятно, они могли бы внести ясность.

Отредактировано пользователем 25 марта 2020 г. 12:28:23(UTC)  | Причина: Не указана

К сожалению, текст документа уже утвержден, и, кажется, новый будет выкатить непросто и долго.


Ну, в разработанном мной ПО формирование CMS пакета - собственными силами, и там возможны варианты. В частности, какой алгоритм использовать.
Поскольку лично у меня до сих пор нет ясности, должен ли, в общем случае, digestAlgorithm, обязательно соответствовать signatureAlgorithm.
Это по формулировкам rfc, не росстандарта. А ПО работатает не только с КриптоПро и не только с российскими гостами.
А вот для проверки ЭП как раз поддерживаются оба варианта. Поскольку ЭП может формироваться сторонними средствами. На текущий момент это ПО пережило уже пару успешных сертификаций в компетентных органах. К этому моменту пока замечаний не было.

В общем, изначальный вопрос был не мой: проверка подписи работает под одним dotNet и не работает под другим.
Поскольку тут разработка только ведется, сертификация еще далеко, решил внести некоторую ясность. Может быть, уберечь кого-то от сюрпризов по факту использования(совместимость/документируемость).


Да, и тем не менее, в росстандарте - ссылка на подпись в сертификате. В отличие от ТК.


Формально атрибут timestamp - это signedData. И в rfc на TSP, кажется, нет указаний на какие-то особые условия заполнения поля SignerInfo.signatureAlgorithm.
Т.е. тут формально действует основной rfc, а в explorer.exe мы наблюдаем его конкретную реализацию.

C зоопарком, в основном попадалось только, что до сих пор часто используется countersignature.

Отредактировано пользователем 25 марта 2020 г. 13:08:08(UTC)  | Причина: Не указана

Спасибо, будем ждать релиза :)