Форум КриптоПро
»
Средства криптографической защиты информации
»
КриптоПро ЭЦП (усовершенствованная ЭЦП)
»
Проблема с проверкой подписи в формате CAdES-X Long Type 1, ошибка CERT_E_REVOCATION_FAILURE
Статус: Активный участник
Группы: Участники
Зарегистрирован: 17.09.2012(UTC) Сообщений: 31  Откуда: Москва Сказал «Спасибо»: 4 раз
|
Лена здравствуйте, вы уверены, что проблема из-за этого? Вроде бы по спецификации параметр thisUpdate и должен быть меньше чем время подписания: Код: - thisUpdate: The time at which the status being indicated is known to be correct
- nextUpdate: The time at or before which newer information will be available about the status of the certificate
- producedAt: The time at which the OCSP responder signed this response.
Цитата:... The thisUpdate and nextUpdate fields define a recommended validity interval. ... Responses whose thisUpdate time is later than the local system time SHOULD be considered unreliable. Responses whose nextUpdate value is earlier than the local system time value SHOULD be considered unreliable. ... В указанной подписи эти параметры соответственно: producedAt: 2012-09-17 10:39:54 UTC thisUpdate: 2012-09-17 06:25:36 UTC nextUpdate: 2012-09-19 18:45:36 UTC Отредактировано пользователем 18 сентября 2012 г. 13:41:04(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники Зарегистрирован: 10.12.2008(UTC) Сообщений: 924  Откуда: Крипто-Про Поблагодарили: 99 раз в 95 постах
|
Я говорила не о времени подписания OCSP-ответа, а о времени подписания документа. Точнее о доказанном времени существования подписи этого документа, указанного в штампе времени на подпись. Если интересно, можете почитать про grace period в стандарте CAdES (ETSI TS 101 733), параграф 4.4.2.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 17.09.2012(UTC) Сообщений: 31 Откуда: Москва Сказал «Спасибо»: 4 раз
|
Уважаемые коллеги, здравствуйте! Если сравнить временные результаты, полученные от разных OCSP служб OCSP служба "http://certenroll.ca.rt.ru/ocsp/ocsp.srf" *** Код:timeStampToken 2012-09-17 10:39:48 UTC
revocationValues
producedAt: 2012-09-17 10:39:54 UTC
thisUpdate: 2012-09-17 06:25:36 UTC
nextUpdate: 2012-09-19 18:45:36 UTC
escTimeStamp 2012-09-17 10:41:12 UTC
OCSP служба "http://www.cryptopro.ru/ocspnc/ocsp.srf" Код:timeStampToken 2012-09-18 15:01:27 UTC
revocationValues
producedAt: 2012-09-18 15:01:30 UTC
thisUpdate: 2012-09-18 15:01:30 UTC
nextUpdate: 2012-09-13 13:56:17 UTC
escTimeStamp 2012-09-18 15:01:31 UTC
Правильно ли я понимаю, что значение thisUpdate должно быть таким же, как и значение producedAt, т.е. текущим? И нам нужно соответствующим образом настроить OCSP службу. Это функциональная специфика работы cadescom.dll или есть соответствующие документы? Просто из описания "grace period" не совсем понятно, как это противоречит спецификации RFC 2560. Насколько я понял, thisUpdate просто указывает на время обновления статуса сертификата и не более.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники Зарегистрирован: 10.12.2008(UTC) Сообщений: 924 Откуда: Крипто-Про Поблагодарили: 99 раз в 95 постах
|
Никакого противоречия в данном случае нет, ссылку на стандарт я вам давала.
Попробую коротко объяснить. Подпись CAdES-X Long Type 1 предполагает возможность проверки даже в случае отзыва сертификата ключа подписи. Для этого в нее должны быть вложены достаточные для такой проверки доказательства действительности сертификата в момент создания подписи.
Все просто - время, на которое нам точно известен статус сертификата, должно быть более поздним, чем время создания подписи. Нужно объяснять почему или это и так понятно?
Дальше смотрим - время получения _актуальной_ информации о статусе сертификата указывается в поле thisUpdate OCSP-ответа (или CRL). Для краткости обозначим это время Т1.
Время создания подписи (документально подтвержденное) - время указанное в signatureTimeStamp. Обозначим его Т2. То есть известно, что подпись создана не позднее, чем в момент времени Т2.
Если Т1 < Т2, то у нас нет никаких доказательст того, что сертификат не был отозван в некоторый момент времени ТХ между Т1 и Т2. То есть Т1 < ТХ < Т2.
В таких случаях при _создании_ подписи следует подождать до появления более свежей информации о статусе сертификата, чтобы время ее получения было более поздним, чем Т2. То есть при _создании_ подписи нужно получать новый OCSP-ответ, время thisUpdate в котором будет больше, чем Т2.
Дальше возникает вопрос - а сколько ждать-то? Для этого смотрим в поле nextUpdate и выясняем, что более свежая информация будет доступна через 2 дня, а 2 дня на создание подписи - это много.
Служба OCSP на нашем сервере работает по базе данных ЦС и предоставляет информацию о статусах сертификатов на текущий момент.
Ваша служба OCSP скорее всего работает по CRL и в поле ThisUpdate ставит время выпуска CRL. Вариантов настройки 2: либо переводить службу на режим работы по БД, либо ставить галочку в настройках службы "Заменять время последнего обновления CRL текущим временем". Второй вариант подразумевает определенный риск.
|
 1 пользователь поблагодарил Новожилова Елена за этот пост.
|
Adapik оставлено 29.10.2015(UTC)
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 17.09.2012(UTC) Сообщений: 31 Откуда: Москва Сказал «Спасибо»: 4 раз
|
Спасибо огромное за разъяснения, всё стало понятно. Смущает только один момент: Цитата:Если Т1 < Т2, то у нас нет никаких доказательств того, что сертификат не был отозван в некоторый момент времени ТХ между Т1 и Т2. То есть Т1 < ТХ < Т2. А зачем нам нужны доказательства, если кроме OCSP службы, никто информацией об отзыве сертификата не владеет. Если служба сказала, что следующее обновление статуса для данного сертификата будет обновлено существенно позже времени подписи, а текущий статус установлен существенно раньше, то значит всё хорошо. Т.е. другими словами, какая разница что время T1 меньше T2 или равна ей, главное что статус последний и с того момента обновлений не происходило. Или ещё другими словами: - важность для подписчика доказательства отзыва сертификата в момент времени TX определяется уровнем доверия вообще к OCSP службе - online службе, которая в каждый момент времени и владеет статусами сертификатов. Если этой информацией кроме неё владеет ещё кто-то, то смысл тогда к ней обращаться... Ещё раз спасибо, будем считать вопрос решённым, настроим службу, как вы рекомендуете
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники Зарегистрирован: 10.12.2008(UTC) Сообщений: 924 Откуда: Крипто-Про Поблагодарили: 99 раз в 95 постах
|
Цитата:...что статус последний и с того момента обновлений не происходило... Не происходило обновлений на службе и не был отозван сертификат - это разные вещи. И формально нужен не OCSP-ответ, а доказательство действительности сертификата в момент подписи. И OCSP-ответ, в котором время thisUpdate меньше, чем время создания подписи, такого доказательства не обеспечивает. А тот факт, что "правильный" ответ можно получить только через 2 дня (неделю, месяц) и никак не раньше, никакого отношения к доказательству действительности сертификата не имеет. Сертификат мог быть отозван? Мог. Доказательства, что он не был отозван, есть? Нет.
|
|
|
|
|
|
Форум КриптоПро
»
Средства криптографической защиты информации
»
КриптоПро ЭЦП (усовершенствованная ЭЦП)
»
Проблема с проверкой подписи в формате CAdES-X Long Type 1, ошибка CERT_E_REVOCATION_FAILURE
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
