Статус: Активный участник
Группы: Участники
Зарегистрирован: 22.01.2008(UTC) Сообщений: 671   Откуда: Йошкар-Ола Сказал «Спасибо»: 3 раз
Поблагодарили: 93 раз в 67 постах
|
Автор: soir  Добрый день.
Ситуация: сайт, на котором покупатели/продавцы подписывают документы о купле-продаже.
Самый правильный сценарий, насколько я понимаю, таков: пользователь подписывает документ, сайт навешивает на его подпись свой таймстамп, говорит, что правомочность подписи будет установлена через X дней/часов, где X - grace period. Далее ничего не происходит в течение Х дней, после проверка проходит снова и уже затем подпись считается действительной, делу дается ход и далее можно наращивать cades хоть до архивной.
Есть ли какие-нибудь российские нормативные документы, которые этот процесс процесс описывают? Если нет, то какова практика создания усовершенствованной подписи?
Если улучшенную подпись создавать "налету" (неважно, с помощью crl или ocsp), каковы тогда алгоритмы переподписания актуальным таймстампом и вообще проверки подписей? Это ведь получается, что при проверке надо будет:
1) удостовериться, что последняя навешенная метка времени валидна.
2) проверить заново по crl валидность сертификата на момент создания подписи. Причем, корневой мог уже устареть, crl тоже, и проверять придется по устаревшим (хоть, к примеру, и подписанным каким-нибудь таймстампом).
Допустим в результате такой проверки подпись окажется невалидной - сертификат был отозван, но еще не попал с CRL/OCSP на момент создавшейся "на лету" подписи. Дальше что? Оповещать всех лиц? Кто будет нести ответственность за то, что договор купли-продажи был, фактически, уже заключен? Что если в результатах интеграций эти подписи уже ушли третьим сторонам?
И, еще один вопрос, относящийся к подписям, созданным "на лету": процедура переподписания должна как-то сохранять статус "невалиден" в подписи, если она признается невалидной на момент переподписания?
На самом деле "grace period" возникает в единственном случае - в случае заверения сертификата с помощью CRL. В случае же использования OCSP предполагается, что сервер выдаёт строго актуальную информацию по данному сертификату на данную секунду запроса (хотя это может быть на самом деле далеко от реальности). В случае же использования заверения по CRL для создания CAdES Long предлагается использовать два CRL: один список используется при создании подписи, а другой CRL добавляется в подпись после выпуска нового CRL. То есть у нас будут два CRL: в первом будет отсутствовать проверяемый сертификат (значит на дату, предшествующую созданию подписи, он был валиден), а во втором будет подтверждение, что он не отзывался на время создания подписи. Важно чтобы номера этих CRL шли один за другим. Российских нормативов по CAdES сейчас не существует. На самом деле в настоящее время реализация от "Крипто-Про" не поддерживает создание подписей CAdES с использованием CRL, только с использованием OCSP. Я написал свою собственную реализацию CAdES - там и "обкатал" эту возможность. Насчет "допустим в результате такой проверки подпись окажется невалидной". Формально в данной ситуации ничего не нужно делать. То есть даже если сертификат был отозван, то все-равно включается CRL, который это подтверждает. То есть статус этой подписи нигде в самой подписи не ставится, а находится во время проверки этой самой подписи. Насчет "Кто будет нести ответственность за то, что договор купли-продажи был, фактически, уже заключен": тот, кто эту подпись сделал. Как я уже говорил, "grace period" есть только в случае использования CRL. То есть для более надёжного создания подписей CAdES логичнее будет всегда использовать OCSP сервер. |
С уважением,
Юрий Строжевский |
