Доброго дня!

В документации отсутствует запрет на формирование "нового" формата данных на основе указанного в документации набора вызовов. Если все выбранные вызовы интерфейса КриптоПро CSP есть в перечне, тогда действительно возможно их использовать без создания нового СКЗИ после проведения работ по оценке влияния.

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

За полным ответом лучше обратиться к регулятору. Если предположить, что формируемые на стороне прикладного ПО сообщения формата cades-bes нужны не просто так, а так или иначе для защиты информации, тогда наверняка потребуется разработать отдельное СКЗИ. Если сообщения будут целиком формироваться средствами КриптоПро CSP, то можно пытаться обойтись без создания нового СКЗИ, однако порядок работ для конечной информационной системы будет подлежать обсуждению с регулятором.

Отредактировано пользователем 30 января 2020 г. 15:20:52(UTC)  | Причина: Не указана

Если отвечать как можно проще, то -
да, самостоятельное формирование структуры CMS, идентичной создаваемой CryptSignMessage, по умолчанию приводит к созданию нового СКЗИ (кажется, что могут быть исключения, но на это не стоит закладываться). Из документации это следует только опосредованно.

Меня тоже интересует такой вопрос. Как мне кажется проблема возникнет не с тем, что упаковать результат в массив (тут все прозрачно и скзи на мой взгляд не возникнет как не конвертируй результат), а с тем что cades xades в ряде случаев подписывают не то, что передает пользователь, например, не исходный файл, а атрибуты в которых хэш исходных данных или тег SignedInfo c хэшами фрагментов документа. Вот именно с генерацией подписываемого, не связанного напрямую с подписываемыми данными, возникнет проблема корректности. Фактически Вы уже сами частично сделаете ту же операцию подписания (для более широкого формата подписи cades чем низкоуровневая RawSignature), что может быть расценено как новое скзи.

С другой стороны, если сделать просто список хэшей (возвращенных белым списком) файлов, а потом от списка посчитать и подписать хэш (белым списком), приклеить к списку значение подписи и сертификат, то скзи с моей точки зрения не возникнет, так как компоненты подписания четко разделены на 2 операции: формирование списка хэшей произвольного формата и raw подписание.

В конечном счете, выходит все зависит называть самодельное подписью или нет? Скажете, что это массив байт "как есть" без всяких гарантий, по чистой случайности совпавший с cades и Ваша программа не скзи? Если пользователи будут использовать массив как cades это уже их проблема? Скажете, что делаете подпись cades и программа внезапно скзи?

Отредактировано пользователем 4 февраля 2020 г. 7:52:28(UTC)  | Причина: Не указана

Я не предлагаю использовать CryptSetHashParam, в процитированном имелось в виду подписать список хэшей (с именами или другими отличительными идентификаторами файлов) уже как данные, то есть это CryptCreateHash, CryptHashData (список хэшей), CryptSignHash, а CryptSetHashParam не используется. Действительно, вернемся к теме.

Отредактировано пользователем 5 февраля 2020 г. 9:49:01(UTC)  | Причина: Не указана

Документы, обозначенные выше, прояснить ситуацию не могут. Никак.
Естественно, в ТЗ будет написано "<Наименование ПО> предназначено для формирования и проверки ЭП средствами КриптоПро CSP"
+ перечисление (список сертифицированных криптопровайдеров, для которых существует своя докумеентация). КриптоПро CSP- лишь один из используемых.
Не будем усложнять, в этом кейсе для простоты только КриптоПро CSP.
Набор используемых вызовов будет соответствовать Приложению 2. Само собой. Однако,


В Приложении 2 присутствуют именно вызовы функций, т.е. операции над данными, а не сами форматы данных. Может ли формат данных быть "криптографическим" сам по себе? Так легко объявить криптографическими все операции над ASN.1.
Общее понимание того, что можно, а что нельзя, существует. Я не задаю вопрос, могу ли я, используя криптографические функции из Приложения 2, в дополнение к ним использовать еще и собственную реализацию ГОСТ Р 34.11-2012 с какими-то целями. Есть какие-то ссылки на "общую тенденцию"?


У Вас, возможно, есть опыт обращения к регулятору с подобными запросами? Интересно было бы посмотреть практику. Легко представить, что такая консультация закончится вопросом, умею ли я читать, и если да, то -> ПКЗ2005 и документация на СКЗИ.
Т.е. данный случай это игра в рулетку, я верно понимаю? т.е. подготовка и передача ТЗ, а там, как карта ляжет. так?

Отредактировано пользователем 5 февраля 2020 г. 17:49:29(UTC)  | Причина: Не указана