Статус: Активный участник
Группы: Участники
Зарегистрирован: 22.01.2008(UTC) Сообщений: 671   Откуда: Йошкар-Ола Сказал «Спасибо»: 3 раз
Поблагодарили: 93 раз в 67 постах
|
Автор: Новожилова Елена  Стандарт "CMS Advanced Electronic Signatures (CAdES)" действительно предусматривает возможность использования CRL в качестве доказательства действительности сертификата. Но поле thisUpdate такого CRL должно содержать время более позднее, чем указано в штампе времени на подпись. В противном случае CRL не доказывает действительность сертификата в момент создания подписи. Поскольку ждать следующего обновления CRL возможно придется насколько дней, то такое время формирования подписи никого не устроит. На всякий случай скажу, что я создавал тестовую CAdES подпись в которой использовался CRL, выпущенный на следующий день от даты, упомянутой в "signature-time-stamp". То есть создал ситуацию которую описывает Елена. Такую подпись существующие функции "Крипто-Про CAdES SDK" все-равно посчитали ошибочной. |
С уважением,
Юрий Строжевский |
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники Зарегистрирован: 10.12.2008(UTC) Сообщений: 924  Откуда: Крипто-Про Поблагодарили: 99 раз в 95 постах
|
Да, потому что сейчас в качестве доказательств действительности сертификата ключа конечного пользователя принимаются только OCSP-ответы. В следующих версиях это поведение, скорее всего, будет изменено.
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 13.06.2013(UTC)
Сообщений: 5
Сказал(а) «Спасибо»: 1 раз
|
Автор: Новожилова Елена
Здравствуйте!
Стандарт "CMS Advanced Electronic Signatures (CAdES)" действительно предусматривает возможность использования CRL в качестве доказательства действительности сертификата. Но поле thisUpdate такого CRL должно содержать время более позднее, чем указано в штампе времени на подпись. В противном случае CRL не доказывает действительность сертификата в момент создания подписи. Поскольку ждать следующего обновления CRL возможно придется насколько дней, то такое время формирования подписи никого не устроит.
CRL можно было бы использовать при дополнении подписи формата CAdES-T до других форматов подписи, но в данный момент формат CAdES-T не поддерживается. Для сертификатов промежуточных центров сертификации CRL можно использовать и сейчас.
Что касается семантики полей thisUpdate, nextUpdate и producedAt, то в RFC сказано что они имеют такой же смысл, как и в CRL. Как правило, подразумевается, что служба актуальных статусов работает не на основании CRL, а имеет более актуальную информацию об отзыве сертификатов. Например, работает по базе данных удостоверяющего центра.
Спасибо за ваш ответ, но хочется ссылок на источники, на основании которых Вы утверждаете, что дата или по крайней мере время издания CRL должно быть позже, чем указано в штампе времени ЭП. Чисто по человечески, я тогда просто не понимаю смысл CRL - получается как доверенный источник информации он практически ничего не стоит, так как период его обновления может достигать месяцев в зависимости от УЦ. Смысл форматов начиная от cades-c заканчивая cades-a в принципе в каком-то смысле теряется, так как не может быть создана такая подпись налету в отсутствии OCSP-сервера на стороне УЦ.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 06.03.2012(UTC)
Сообщений: 177
Сказал(а) «Спасибо»: 57 раз
Поблагодарили: 11 раз в 8 постах
|
Автор: Новожилова Елена Автор: Stazol Добрый день. На основании документа "СТАНДАРТ ПРИМЕНЕНИЯ УСОВЕРШЕНСТВОВАННОЙ ЭЛЕКТРОННОЙ ЦИФРОВОЙ ПОДПИСИ" можно сделать вывод, что в качестве доказательств действительности сертификата подписанта при создании усовершенствованной ЭП может выступать только OCSP-ответ. Однако в стандарте "CMS Advanced Electronic Signatures (CAdES) (RFC 5126)", из которого формат усовершенствованной подписи позаимствован, вроде бы нет прямых на то указаний, а подразумевается возможность использование CRL. Не могли бы вы посоветовать источники, в которых я бы мог удостоверится в необходимости использования OCSP-ответа в качестве доказательства действительности сертификата подписанта? В общем случае, на стороне далеко не всех УЦ развернут OCSP-сервер, но практически у всех есть источник CRL. Получается, что текущая реализация усовершенствованной ЭП несколько ограничивает области ее применения. Заранее спасибо. UPD: просмотрел форум и нашел похожий вопрос в теме Усовершенствование подписи используя только списки отзывов. Показалось странным, так как такая позиция фактически говорит нам о том, что актуальный на дату создания подписи CRL как источник информации ничего не стоит. Почитал стандарт " X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", в частности о том, что понимается под временем OCSP-ответа и его актуальностью. Наиболее интересная информация была в пунктах "2.4 Semantics of thisUpdate, nextUpdate and producedAt" и "4.2.2.1 Time". Очень заинтересовала отсылка к CRL, цитирую п. 4.2.2.1: "The thisUpdate and nextUpdate fields define a recommended validity interval. This interval corresponds to the {thisUpdate, nextUpdate} interval in CRLs. ... Responses where the nextUpdate value is not set are equivalent to a CRL with no time for nextUpdate (see Section 2.4)." Правильно ли я понимаю, что время создания OCSP-ответа должно находиться в интервале дат "Действителен с" - "Следующее обновление" CRL? Если так, то почему для сертификата подписанта в качестве доказательства действительности при создании усовершенствованной подписи необходим именно OCSP-ответ, если он фактически опирается на время обновления списков отзывов и получается на информацию из них? Здравствуйте! Стандарт "CMS Advanced Electronic Signatures (CAdES)" действительно предусматривает возможность использования CRL в качестве доказательства действительности сертификата. Но поле thisUpdate такого CRL должно содержать время более позднее, чем указано в штампе времени на подпись. В противном случае CRL не доказывает действительность сертификата в момент создания подписи. Поскольку ждать следующего обновления CRL возможно придется насколько дней, то такое время формирования подписи никого не устроит. CRL можно было бы использовать при дополнении подписи формата CAdES-T до других форматов подписи, но в данный момент формат CAdES-T не поддерживается. Для сертификатов промежуточных центров сертификации CRL можно использовать и сейчас. Что касается семантики полей thisUpdate, nextUpdate и producedAt, то в RFC сказано что они имеют такой же смысл, как и в CRL. Как правило, подразумевается, что служба актуальных статусов работает не на основании CRL, а имеет более актуальную информацию об отзыве сертификатов. Например, работает по базе данных удостоверяющего центра. Елена, выходит как вариант, остается публиковать crlы с периодичностью 1 раз в 5-10 секунд и перекладывать их. Нет уверенности, что в распределенной структуре они успеют перекачаться с сервера на сервер. И выдержит ли УЦ, и континент такую нагрузку? Под хранение всех срл надо будет отдельное хранилище СХД заводить. Интересно, что же будет со службами УЦ для версии 2.0? Отредактировано пользователем 23 октября 2013 г. 12:00:10(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники Зарегистрирован: 10.12.2008(UTC) Сообщений: 924 Откуда: Крипто-Про Поблагодарили: 99 раз в 95 постах
|
Посмотрите первоисточник - стандарт ETSI TS 101 733 Electronic Signatures and Infrastructures (ESI);
CMS Advanced Electronic Signatures (CAdES).
Параграф 4.4.2 ES with Complete Validation Data References (CAdES-C) - и далее поиском по словам "grace period".
Обоснование форматов подписи, начиная с CAdES-C можно посмотреть в том же стандарте.
Я понимаю, что вам хочется не разворачивая OCSP-сервер создавать "налету" подпись формата CAdES-X Long Type 1, но так не бывает.
Допустим есть CRL, выпущенный 5 дней назад. Подпись вы создаете сейчас. Время, на которое можно доказать существование подписи - это время, которое указано в штампе времени на подпись. Очевидно, что CRL, выпущенный 5 дней назад, никоим образом не доказывает действительность сертификата в момент создания подписи.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 22.01.2008(UTC) Сообщений: 671 Откуда: Йошкар-Ола Сказал «Спасибо»: 3 раз
Поблагодарили: 93 раз в 67 постах
|
Автор: Новожилова Елена Посмотрите первоисточник - стандарт ETSI TS 101 733 Electronic Signatures and Infrastructures (ESI);
CMS Advanced Electronic Signatures (CAdES).
Параграф 4.4.2 ES with Complete Validation Data References (CAdES-C) - и далее поиском по словам "grace period".
Обоснование форматов подписи, начиная с CAdES-C можно посмотреть в том же стандарте.
Я понимаю, что вам хочется не разворачивая OCSP-сервер создавать "налету" подпись формата CAdES-X Long Type 1, но так не бывает.
Допустим есть CRL, выпущенный 5 дней назад. Подпись вы создаете сейчас. Время, на которое можно доказать существование подписи - это время, которое указано в штампе времени на подпись. Очевидно, что CRL, выпущенный 5 дней назад, никоим образом не доказывает действительность сертификата в момент создания подписи. Кстати если подходить уж очень формально то и использование OCSP тоже может предоставлять доказательства валидности сертификата с некоторой задержкой. В частности это может быть если OCSP сервер использует в качестве базы всё те же CRL, а не некую локальную базу (и OCSP сервер от Крипто-Про обладает такой возможностью). |
С уважением,
Юрий Строжевский |
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники Зарегистрирован: 10.12.2008(UTC) Сообщений: 924 Откуда: Крипто-Про Поблагодарили: 99 раз в 95 постах
|
Автор: MCR
Елена, выходит как вариант, остается публиковать crlы с периодичностью 1 раз в 5-10 секунд и перекладывать их. Нет уверенности, что в распределенной структуре они успеют перекачаться с сервера на сервер. И выдержит ли УЦ, и континент такую нагрузку?
Под хранение всех срл надо будет отдельное хранилище СХД заводить.
Интересно, что же будет со службами УЦ для версии 2.0?
А зачем вам лишняя нагрузка на УЦ, на инфраструктуру, заводить отдельное хранилище? Ведь как раз для того, чтобы лишней нагрузки избежать, и предназначен протокол OCSP. Напоминаю, в настоящий момент в "КриптоПро ЭЦП" поддерживается только один вид информации об отзыве для сертификата конечного пользователя - это OCSP-ответ. Поскольку не было других реализаций, то и при проверке был поддержан только этот вариант (для сертификата конечного пользователя). В будущем планируется поддержка и других форматов подписи, тогда это поведение изменится. Но это не в ближайших планах.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники Зарегистрирован: 10.12.2008(UTC) Сообщений: 924 Откуда: Крипто-Про Поблагодарили: 99 раз в 95 постах
|
Автор: Юрий
Кстати если подходить уж очень формально то и использование OCSP тоже может предоставлять доказательства валидности сертификата с некоторой задержкой. В частности это может быть если OCSP сервер использует в качестве базы всё те же CRL, а не некую локальную базу (и OCSP сервер от Крипто-Про обладает такой возможностью).
Если подходить формально, то в режиме работы КриптоПро OCSP Server по CRL в OCSP-ответ будут проставлены те же времена thisUpdate и nextUpdate, что и в CRL, из которого взята информация об отзыве. А если оператор службы принимает решение включить опцию "заменять время последнего обновления CRL текущим временем", то всю ответственность за возможную выдачу недостоверных ответов он берет на себя.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 22.01.2008(UTC) Сообщений: 671 Откуда: Йошкар-Ола Сказал «Спасибо»: 3 раз
Поблагодарили: 93 раз в 67 постах
|
Автор: Новожилова Елена Автор: Юрий
Кстати если подходить уж очень формально то и использование OCSP тоже может предоставлять доказательства валидности сертификата с некоторой задержкой. В частности это может быть если OCSP сервер использует в качестве базы всё те же CRL, а не некую локальную базу (и OCSP сервер от Крипто-Про обладает такой возможностью).
Если подходить формально, то в режиме работы КриптоПро OCSP Server по CRL в OCSP-ответ будут проставлены те же времена thisUpdate и nextUpdate, что и в CRL, из которого взята информация об отзыве. А если оператор службы принимает решение включить опцию "заменять время последнего обновления CRL текущим временем", то всю ответственность за возможную выдачу недостоверных ответов он берет на себя. Мой пост был призван только предоставить дополнительную информацию в споре "CRL - ерунда, OCSP - forever". |
С уважением,
Юрий Строжевский |
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники Зарегистрирован: 10.12.2008(UTC) Сообщений: 924 Откуда: Крипто-Про Поблагодарили: 99 раз в 95 постах
|
Так речь же не о том, что CRL плох или хорош. Речь в данном случае о применимости CRL в конкретной ситуации - для "моментального" формирования подписи CAdES-X Long Type 1.
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
