а зачем тогда и CSP, раз от квал.подписей уходите? Сразу свой сделаете, встроенный... накиньте ещё ... сколько там в днях будет реализация...

давайте отстрить четко по теме. а то я сейчас перейду на драконов и садомазо. просто из специфики восприятия мира некоторыми пользователями на форумах. еще раз уточню. любой виртуальный мир является калькой с реального. если директор в реальности подписывает одной ручкой все документы .. пока не кончилась паста ... так должно быть и в цифре. одна подпись ... квалифицированная и подтвержденная .. для всех порталов, сервисов, памперсов, больничных, горчичных и тд. точка! и ведется журнал входящихи исходящих. это нормально. это правильно. а если вы любитель извращений ... это ваше полное право. но это не отменяет нормальность мира.

Добрый день. У меня примерно такие же рассуждения, только я предрагаю вообще отказаться от TLS на сервисе - вместо этого взять пример с сервиса ФСС для ЭЛН (благо код для него есть на форуме под разные языки программирования).

Каждое сообщение-запрос может быть либо подписано сертификатом либо предоставить некие данные авторизации (билет пользователя в рамнах Single Sign On в домене, JWT/OAuth токен, хэш от (хэша пароля + случайная соль) и т.д.), включает сертификат/открытый ключ для ответа. Далее подписанное сообщение шифруется с эфемерным ключом по стандарту EncryptXML в адрес нужного сертификата и отправляется на сервис. Так мы и избавимся от мороки с серверным сертификатом, получим нужное для проверки прав пользователя и обеспечим выбор нужного сертификата и защиту возможно конфиденциальных данных в сообщении.

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

В случае токенов или билета еще и вовлекается некий корпоративный сервер (AD или тому подобное), поэтому проще подписать запрос, например, сертификатом бухгалтера. Так мы убедимся, что запрос отправил бухгалтер и результат подписания получит бухгалтер.

По поводу хранения и защиты от изменений - на настоящий момент самое надежное это блокчейн, но думаю поднимать свой блокчейн для такой задачи немного несоразмерно. Защиту от удаления записи можно по типу блокчейна - допустим, включать хэш от предыдущей записи в следующую. Защита от изменений: для записи журнала можно вычислять хэш и на этот хэш делать штамп времени от доверенного сервера; сохранить хэш и штамп вместе с записью.

По поводу общей схемы я это представляю так: на "сервере" стоит "эмулятор браузера" (приложение Электрон?), который соединен с сервисом - показывает что пришло на подпись, через расширение производит подписание, возврат результата сервису. Сервис взаимодействует с "клиентом". "Клиент" это своего рода "эмулятор плагина". Расширение из браузера на клиентском компьютере обращается к "эмулятору плагина", который если есть сертификат - обращается к плагину, нет такого локально - обращается к серверу, на котором есть сертификат. Тут как раз пригодится функция анонса от сервера. Еще можно прикрутить "эмулятор токена" - интерфейс PKCS11, так можно захватить приложения в которых плагин не подходит.

Добрый день!

То, что вы описываете, можно реализовать на основе интерфейса модулей подтверждения операция "КриптоПро CSP 5.0 R2". Сертифицировать - очень вряд ли, но работать для каких-то задач, не требующих оценки регулятора, вполне может.

В SDK провайдера есть тестовый модуль rdk/reader/source/hvisdef, который показывает локальное окно "Подтвердите операцию" при попытке доступа к закрытому ключу на любом носителе. "Возьмите любой готовый протокол с шифрованием" и доработайте этот проект для удаленного подтверждения.

Сложно сказать, это юридический вопрос.
А вы можете себе представить ситуацию, когда директор завода на 1000 человек, сам, единолично, подписывает все платежки, отчетности, заявки на тендера и т.д.?
Я - нет и никогда такого не видел.

Теперь вопрос - как с этим работать в реальной жизни?