Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

3 Страницы123>
Опции
К последнему сообщению К первому непрочитанному
Offline Stazol  
#1 Оставлено : 21 октября 2013 г. 17:35:58(UTC)
Stazol

Статус: Новичок

Группы: Участники
Зарегистрирован: 13.06.2013(UTC)
Сообщений: 5

Сказал(а) «Спасибо»: 1 раз
Добрый день.
На основании документа "СТАНДАРТ ПРИМЕНЕНИЯ УСОВЕРШЕНСТВОВАННОЙ ЭЛЕКТРОННОЙ ЦИФРОВОЙ ПОДПИСИ" можно сделать вывод, что в качестве доказательств действительности сертификата подписанта при создании усовершенствованной ЭП может выступать только 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-ответ, если он фактически опирается на время обновления списков отзывов и получается на информацию из них?

Отредактировано пользователем 22 октября 2013 г. 8:13:56(UTC)  | Причина: Не указана

Offline Юрий  
#2 Оставлено : 22 октября 2013 г. 8:13:20(UTC)
Юрий

Статус: Активный участник

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 671
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 3 раз
Поблагодарили: 93 раз в 67 постах
Автор: Stazol Перейти к цитате
Добрый день.
На основании документа "СТАНДАРТ ПРИМЕНЕНИЯ УСОВЕРШЕНСТВОВАННОЙ ЭЛЕКТРОННОЙ ЦИФРОВОЙ ПОДПИСИ" можно сделать вывод, что в качестве доказательств действительности сертификата подписанта при создании усовершенствованной ЭП может выступать только OCSP-ответ. Однако в стандарте "CMS Advanced Electronic Signatures (CAdES) (RFC 5126)", из которого формат усовершенствованной подписи позаимствован, вроде бы нет прямых на то указаний, а подразумевается возможность использование CRL. Не могли бы посоветовать источники, в которых я бы мог удостоверится в необходимости использования OCSP-ответа в качестве доказательства действительности сертификата подписанта?
В общем случае, на стороне далеко не всех УЦ развернут OCSP-сервер, но практически у всех есть источник CRL. Получается, что текущая реализация усовершенствованной ЭП несколько ограничивает области ее применения.
Заранее спасибо.

Уже узнавал мнение Крипто-Про на этот счет так что напишу то, что они ответили.

Поддержка доказательств подлинности на основе CRL умышленно убрана и добавлять эту поддержку Крипто-Про не планирует добавлять (читай между строк "отказывается вносить").

Так что если есть необходимость в поддержке полного стандарта CAdES то придется делать собственную функцию проверки. И, кстати, то что названо Вами "стандарт" на самом деле является только неким предложением для стандарта. Пока нет ясности будет ли он именно в этом виде или нет (и вообще будет ли когда-нибудь этот документ стандартом).

С уважением,
Юрий Строжевский
thanks 2 пользователей поблагодарили Юрий за этот пост.
Stazol оставлено 22.10.2013(UTC), Андрей * оставлено 22.10.2013(UTC)
Offline Stazol  
#3 Оставлено : 22 октября 2013 г. 8:24:14(UTC)
Stazol

Статус: Новичок

Группы: Участники
Зарегистрирован: 13.06.2013(UTC)
Сообщений: 5

Сказал(а) «Спасибо»: 1 раз
Автор: Юрий Перейти к цитате
Уже узнавал мнение Крипто-Про на этот счет так что напишу то, что они ответили.

Поддержка доказательств подлинности на основе CRL умышленно убрана и добавлять эту поддержку Крипто-Про не планирует добавлять (читай между строк "отказывается вносить").

Так что если есть необходимость в поддержке полного стандарта CAdES то придется делать собственную функцию проверки. И, кстати, то что названо Вами "стандарт" на самом деле является только неким предложением для стандарта. Пока нет ясности будет ли он именно в этом виде или нет (и вообще будет ли когда-нибудь этот документ стандартом).

Спасибо за ответ. Стала немного яснее позиция КриптоПРО и все-таки хотелось бы услышать аргументацию такой позиции от их представителя. На первый взгляд, аргумент один и он чисто коммерческий - обязать использовать OCSP-сервер и в конечном итоге OCSP-клиент на каждом рабочем месте.

Отредактировано пользователем 22 октября 2013 г. 8:25:18(UTC)  | Причина: Не указана

Offline Юрий  
#4 Оставлено : 22 октября 2013 г. 8:36:51(UTC)
Юрий

Статус: Активный участник

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 671
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 3 раз
Поблагодарили: 93 раз в 67 постах
Автор: Stazol Перейти к цитате
Автор: Юрий Перейти к цитате
Уже узнавал мнение Крипто-Про на этот счет так что напишу то, что они ответили.

Поддержка доказательств подлинности на основе CRL умышленно убрана и добавлять эту поддержку Крипто-Про не планирует добавлять (читай между строк "отказывается вносить").

Так что если есть необходимость в поддержке полного стандарта CAdES то придется делать собственную функцию проверки. И, кстати, то что названо Вами "стандарт" на самом деле является только неким предложением для стандарта. Пока нет ясности будет ли он именно в этом виде или нет (и вообще будет ли когда-нибудь этот документ стандартом).

Спасибо за ответ. Стала немного яснее позиция КриптоПРО и все-таки хотелось бы услышать аргументацию такой позиции от их представителя. На первый взгляд, аргумент один и он чисто коммерческий - обязать использовать OCSP-сервер и в конечном итоге OCSP-клиент на каждом рабочем месте.

Опять встряну - да, именно коммерческими интересами эта позиция и мне была аргументирована.
С уважением,
Юрий Строжевский
Offline MCR  
#5 Оставлено : 22 октября 2013 г. 8:46:45(UTC)
MCR

Статус: Активный участник

Группы: Участники
Зарегистрирован: 06.03.2012(UTC)
Сообщений: 177

Сказал(а) «Спасибо»: 57 раз
Поблагодарили: 11 раз в 8 постах
Автор: Stazol Перейти к цитате
Автор: Юрий Перейти к цитате
Уже узнавал мнение Крипто-Про на этот счет так что напишу то, что они ответили.

Поддержка доказательств подлинности на основе CRL умышленно убрана и добавлять эту поддержку Крипто-Про не планирует добавлять (читай между строк "отказывается вносить").

Так что если есть необходимость в поддержке полного стандарта CAdES то придется делать собственную функцию проверки. И, кстати, то что названо Вами "стандарт" на самом деле является только неким предложением для стандарта. Пока нет ясности будет ли он именно в этом виде или нет (и вообще будет ли когда-нибудь этот документ стандартом).

Спасибо за ответ. Стала немного яснее позиция КриптоПРО и все-таки хотелось бы услышать аргументацию такой позиции от их представителя. На первый взгляд, аргумент один и он чисто коммерческий - обязать использовать OCSP-сервер и в конечном итоге OCSP-клиент на каждом рабочем месте.

Коллеги, кроме коммерческой составляющей попробуем рассмотреть ситуацию, при которой во время действия одного crl выпускается еще один новый crl, но старый crl в общедоступных точках не обновился по каким-то причинам. Мы проверяем сертификат по старому СОС, а уже в этот момент есть более новый. Но и не лишен этого недостатка OCSP сервер при методе проверки по CRL, или при проверке по БД ЦР.

Только OCSP ответ по БД ЦС даст наиболее верную картину. Но такая конфигурация может быть не у всех УЦ, и приминима только для УЦ версии 1.5.х

Отредактировано пользователем 22 октября 2013 г. 8:50:11(UTC)  | Причина: Не указана

thanks 1 пользователь поблагодарил MCR за этот пост.
Андрей * оставлено 22.10.2013(UTC)
Offline Юрий  
#6 Оставлено : 22 октября 2013 г. 9:06:07(UTC)
Юрий

Статус: Активный участник

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 671
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 3 раз
Поблагодарили: 93 раз в 67 постах
Автор: MCR Перейти к цитате
Автор: Stazol Перейти к цитате
Автор: Юрий Перейти к цитате
Уже узнавал мнение Крипто-Про на этот счет так что напишу то, что они ответили.

Поддержка доказательств подлинности на основе CRL умышленно убрана и добавлять эту поддержку Крипто-Про не планирует добавлять (читай между строк "отказывается вносить").

Так что если есть необходимость в поддержке полного стандарта CAdES то придется делать собственную функцию проверки. И, кстати, то что названо Вами "стандарт" на самом деле является только неким предложением для стандарта. Пока нет ясности будет ли он именно в этом виде или нет (и вообще будет ли когда-нибудь этот документ стандартом).

Спасибо за ответ. Стала немного яснее позиция КриптоПРО и все-таки хотелось бы услышать аргументацию такой позиции от их представителя. На первый взгляд, аргумент один и он чисто коммерческий - обязать использовать OCSP-сервер и в конечном итоге OCSP-клиент на каждом рабочем месте.

Коллеги, кроме коммерческой составляющей попробуем рассмотреть ситуацию, при которой во время действия одного crl выпускается еще один новый crl, но старый crl в общедоступных точках не обновился по каким-то причинам. Мы проверяем сертификат по старому СОС, а уже в этот момент есть более новый. Но и не лишен этого недостатка OCSP сервер при методе проверки по CRL, или при проверке по БД ЦР.

Только OCSP ответ по БД ЦС даст наиболее верную картину. Но такая конфигурация может быть не у всех УЦ, и приминима только для УЦ версии 1.5.х

Да, и этот вопрос тоже обсуждался.

На это мне было отвечено, что сейчас в регламенте УЦ заложено, что юридическое лицо само несет ответственность за использование скомпрометированного сертификата на период между сообщением в УЦ о компрометации и выпуском следующего CRL. Так что можно утверждать, что текущий CRL (пусть и выпущенный до времени создания штампа подписи) полностью отражает статус использованного в подписи сертификата.
С уважением,
Юрий Строжевский
thanks 1 пользователь поблагодарил Юрий за этот пост.
MCR оставлено 22.10.2013(UTC)
Offline Stazol  
#7 Оставлено : 22 октября 2013 г. 9:16:18(UTC)
Stazol

Статус: Новичок

Группы: Участники
Зарегистрирован: 13.06.2013(UTC)
Сообщений: 5

Сказал(а) «Спасибо»: 1 раз
Автор: MCR Перейти к цитате
Коллеги, кроме коммерческой составляющей попробуем рассмотреть ситуацию, при которой во время действия одного crl выпускается еще один новый crl, но старый crl в общедоступных точках не обновился по каким-то причинам. Мы проверяем сертификат по старому СОС, а уже в этот момент есть более новый. Но и не лишен этого недостатка OCSP сервер при методе проверки по CRL, или при проверке по БД ЦР.

Только OCSP ответ по БД ЦС даст наиболее верную картину. Но такая конфигурация может быть не у всех УЦ, и применима только для УЦ версии 1.5.х

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

Насколько критичен в данном случае момент времени между обновлением сведений в БД ЦС и обновлением CRL? Точки распространения CRL, если я не ошибаюсь, обычно "совмещены" с самим ПАК УЦ, то есть промежуток времени между обновлением сведений в БД и незапланированным выпуском CRL будет минимален.

Какова роль УЦ в данном случае, не является ли он в каком-то виде страхователем вышеозначенных рисков, который гарантирует со своей стороны наличие актуальной информации о состоянии сертификатов, им выпущенных?

У меня остался практически единственный вопрос - зачем намеренно "урезать" области применения усовершенствованной подписи?
Offline Андрей Писарев  
#8 Оставлено : 22 октября 2013 г. 10:07:07(UTC)
Андрей *

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 26.07.2011(UTC)
Сообщений: 12,719
Мужчина
Российская Федерация

Сказал «Спасибо»: 500 раз
Поблагодарили: 2054 раз в 1594 постах
Автор: MCR Перейти к цитате
Автор: Stazol Перейти к цитате
Автор: Юрий Перейти к цитате
Уже узнавал мнение Крипто-Про на этот счет так что напишу то, что они ответили.

Поддержка доказательств подлинности на основе CRL умышленно убрана и добавлять эту поддержку Крипто-Про не планирует добавлять (читай между строк "отказывается вносить").

Так что если есть необходимость в поддержке полного стандарта CAdES то придется делать собственную функцию проверки. И, кстати, то что названо Вами "стандарт" на самом деле является только неким предложением для стандарта. Пока нет ясности будет ли он именно в этом виде или нет (и вообще будет ли когда-нибудь этот документ стандартом).

Спасибо за ответ. Стала немного яснее позиция КриптоПРО и все-таки хотелось бы услышать аргументацию такой позиции от их представителя. На первый взгляд, аргумент один и он чисто коммерческий - обязать использовать OCSP-сервер и в конечном итоге OCSP-клиент на каждом рабочем месте.

Коллеги, кроме коммерческой составляющей попробуем рассмотреть ситуацию, при которой во время действия одного crl выпускается еще один новый crl, но старый crl в общедоступных точках не обновился по каким-то причинам. Мы проверяем сертификат по старому СОС, а уже в этот момент есть более новый. Но и не лишен этого недостатка OCSP сервер при методе проверки по CRL, или при проверке по БД ЦР.

Только OCSP ответ по БД ЦС даст наиболее верную картину. Но такая конфигурация может быть не у всех УЦ, и приминима только для УЦ версии 1.5.х


Еще бывают ситуации такие.


Техническую поддержку оказываем тут
Наша база знаний
Offline Stazol  
#9 Оставлено : 22 октября 2013 г. 12:33:10(UTC)
Stazol

Статус: Новичок

Группы: Участники
Зарегистрирован: 13.06.2013(UTC)
Сообщений: 5

Сказал(а) «Спасибо»: 1 раз
Автор: Андрей * Перейти к цитате
Еще бывают ситуации такие.

Пример интересный, но немного не из плоскости основного вопроса. В теме рассматривается именно усовершенствованная подпись, которая могла бы быть cades-x long type 1, но немного не удовлетворяет стандарту. Если бы он был полностью реализован, CRL №457 из вашего примера был бы приложен в качестве доказательств действительности сертификата на момент проверки подписи и сбора этих доказательств, этот момент времени был бы заверен штампом времени.
Ситуация видится слегка надуманной и теоретической, потому что причины отзыва сертификата как-то обошли вниманием, а они могут зависеть как от пользователя, так и от УЦ, и по логике ответственность за использование отозванного сертификата в зависимости от этих причин должна быть обозначена в регламенте УЦ.
Вряд ли можно поставить под сомнение тот факт, что CRL может рассматриваться как доказательство действительности сертификата на момент проверки подписи, если этот момент может быть однозначно установлен. В случае усовершенствованной ЭП вышеозначенный момент подтверждается штампом времени.

Offline Новожилова Елена  
#10 Оставлено : 22 октября 2013 г. 14:55:10(UTC)
Новожилова Елена

Статус: Сотрудник

Группы: Администраторы, Участники
Зарегистрирован: 10.12.2008(UTC)
Сообщений: 924
Женщина
Откуда: Крипто-Про

Поблагодарили: 99 раз в 95 постах
Автор: 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, а имеет более актуальную информацию об отзыве сертификатов. Например, работает по базе данных удостоверяющего центра.

Отредактировано пользователем 22 октября 2013 г. 15:03:13(UTC)  | Причина: Не указана

thanks 1 пользователь поблагодарил Новожилова Елена за этот пост.
MCR оставлено 23.10.2013(UTC)
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest
3 Страницы123>
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.