Автор: TolikTipaTut1 
Код:
+----------------+-------------------+------------П1----------+-----------------П2-------------
| | | |
v v v v
c1 c2 c3 c4
Выпуск СОС 1 Отзыв сертификата Формирование CAdES-T Выпуск СОС 2
Вас смушает, что между c3 и c4, проверка возвращает положительный результат?
Замените Cades-T на Cades-BES (на самую обычную подпись) и расположитесь в рамках действия сертификата, остальное оставьте как есть.
Код:
---------------------Время действия сертификата------------------------------------------------
+----------------+-------------------+------------П1----------+-----------------П2-------------
| | | |
v v v v
c1 c2 c3 c4
Выпуск СОС 1 Отзыв сертификата Формирование CAdES-Bes Выпуск СОС 2
Легенда:
с1-с4 - состояния во времени
П1-П2 проверка подписи во времени.
Как ощущения? Почему-то когда речь идет о подписях простого типа в рамках действия сертификата вас такая ситуация устраивает (в рамка проверки подписи вызовом функции для "проверки подписи"), и вы прекрасно понимаете, что функция проверки работает так как и должна и в момент П1 возвращает Положительный ответ, а в момент П2 - Отрицательный.
Но как только кто-то достаёт красную тряпку "Cades-T" тут же начинают повторять что "это другое, это так не работает, это не должно работать". Почему? Это же таже сама ситуация!
Это пример не в тему, зачем вы смешали понятие время дейсвтия сертификата и СОС (отозван он или нет).
В СОС нет сертификатов у которых вышло действие. Проверка по СОС это ответ на вопрос отзывался или нет, ну и когда если нас время интерисует.
Да Cades-T, как Cades-BES не позволяют решить эту проблему (без дополнительных запросов), но это не мешает использовать Cades-BES и Cades-T на практике.
Как итог: описаная проблема выше это не повод рубить валидность Cades-T, иначе Cades-BES тоже НЕ имеет право использование...Автор: TolikTipaTut1
Если у вас есть все СОСы, то никакой проблемы в проверке ЭП у вас не возникнет.
Парсите все СОСы, смотрите, не был ли отозван серт, "проверяйте" штамп, и математическую корректность подписи.
Ни у кого не возникнет проблемы доказать юр. значимость без КП, проблема в том что использование "КП браузер плагин" странным образом ограничено, что не позволяет использовать его на стороне клиента для проверки подписи или получения информации о ней. Этот вопрос несколько лет возникает на форуме, но ранее им попадались "ленивцы", которым говорят, что "этот тип подписи для этого не предназначен" и они уходят потому что документы никто читать не хочет. Хотя это утверждение неверное судя по RFC для Cades* и TSP, где ч по б написано, что это всё придуманно как раз для "продления срока действия подписи" после окончания действия сертификата.
Автор: TolikTipaTut1 Но проверяйте в этом случае вручную :)
Парсите все СОСы, смотрите, не был ли отозван серт, "проверяйте" штамп, и математическую корректность подписи.
Зачем мне изобретать велосипед. Есть отличный сертифицированные инструменты, уже всё реализовано в том числе в КП, есть только искуственное ограничение на использование. Кроме того, в браузере с помощью плагина КП это сделать невозможно. А этот ответ в стиле: "нас рать".
Лично я поднял вопрос в бесполезности реализации Cades-T в рамках криптоПРО+криптоПРО плагин Browser. В случае с CADES-T он не позволяет ничего проверить и/или получить доп. информацию (время штампа например) по подписи, если у сертификата просто закончилось его действие. Ни мат значимость, ни узнать время TS, ничего... Ну кто мешает при отрицательном ответе заполнить всю структуру по Signers, ведь Signer есть, и подпись его соответствует документу, и штамп есть.
Невозможно сказать что функция проверки работает неправильно, потому что разработчик планировал разработать велосипед, который умеет ездить только прямо. Я тут пытаюсь донести до разработчика, что вроде как нигде в документациях нет таких ограничений, также нет никаких логических и юридических причин делать такое ограничение.
---
На затравочку выдержка из RFC по OCSP протоколу:
1. The "good" state indicates a positive response to the status inquiry.
2. At a minimum, this positive response indicates that no certificate
3. with the requested certificate serial number currently within its
4. validity interval is revoked.
5. This state does not necessarily mean
6. that the certificate was ever issued or that the time at which the
7. response was produced is within the certificate's validity interval.
1. Состояние "хорошо" это положительный ответ на запрос.
2-4. Как минимум, этот положительный ответ указывает на то, что ни один сертификат в настоящее время в пределах срока его действия не отозван.
5-7. Это состояние не обязательно означает, что сертификат когда-либо был выдан или что время получения ответа находится в пределах срока действия сертификата.
Это означает, что:
- OCSP выдаёт положительный ответ для сертификатов которые не отзывали (на текущее время).
- OCSP выдаёт положительный ответ для сертификатов у которых уже вышел срок действия или не наступил.
И это очередное доказательство тому, что всё было очень хорошо продумано для всех типов подписей и ситуаций.
Все иструменты по RFC предпологали работу в режиме когда у сертификата закончился срок действия.
Все проверки которые уже реализованы по RFC можно проводить и для сертификатов с истекшим сроком.
---
На самом деле ничего изобретать не надо (парсить вручную сос, мат корректность и пр). Все средства проверки уже реализованы и хорошо работают в рамках тех процессов, которые описаны в разных RFC. Зачем было делать искуственное ограничения в своей реализации на проверку подписи мне непонятно, но так видимо было задумано.
Если это не так, то дайте возможность получать полный протокол проверки подписи и ваш продкут станет гибче и лучше.
Обсуждение можно закончить и тему закрыть. Я отписываюсь. Надеюсь разработчкики почитают и сделают выводы. Всем спасибо за обсуждение!
