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

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline Kirillius  
#1 Оставлено : 28 июня 2013 г. 10:51:00(UTC)
Kirillius

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

Группы: Участники
Зарегистрирован: 02.12.2009(UTC)
Сообщений: 33
Мужчина
Откуда: Москва

Поблагодарили: 1 раз в 1 постах
Коллеги, добрый день!
Прошу Вас прочитать мое видение "неправильной" логики работы КриптоПро ЭЦП Browser plug-in в части усовершенствованной электронной подписи, проанализировать, дать комментарии и возможно провести доработки (если мои мысли будут верными).
Предыстория:
1. Я являюсь представителем УЦ, который выпускает для пользователей ключи и сертификаты (улучшенные). Пользователи используют ключи и сертификаты в корпоративной ИС совместно с КриптоПро CSP и КриптоПро ЭЦП Browser plug-in.
2. Для предоставления услуг OCSP и TSP я применяю соответствующие службы. Не КриптоПро!!!
Моя служба OCSP не проставляет (не всегда проставляет) поле nextUpdate (nextUpdate:null).
3. КриптоПро ЭЦП Browser plug-in считает это ошибкой и пишет: OCSP response thisUpdate is more then nextUpdate.

Попробовал проанализировать ситуацию. Вот что получилось:

По RFC 2569 поведение OCSP службы допустимо:
http://tools.ietf.org/html/rfc2560#section-2.4
nextUpdate: The time at or before which newer information will be
available about the status of the certificate

If nextUpdate is not set, the responder is indicating that newer
revocation information is available all the time.


Т.е. можно не устанавливать поле nextUpdate.
Таким образом, можно сказать, что КриптоПро клиент OCSP не соответствует п.п.6 раздела 3.2 в части «when available»:
http://tools.ietf.org/html/rfc2560#section-3.2
6. When available, the time at or before which newer information will
be available about the status of the certificate (nextUpdate) is
greater than the current time.

Другое дело, что в RFC написано, что клиенту СЛЕДУЕТ (SHALL) выполнять пункты этого раздела, что подразумевает некоторое послабление со стороны стандарта. Было бы написано ДОЛЖЕН (MUST), вопросов было бы меньше.

Что скажете? Можно ли попросить провести соответствующую доработку Вас?
Offline Новожилова Елена  
#2 Оставлено : 1 июля 2013 г. 13:52:38(UTC)
Новожилова Елена

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

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

Поблагодарили: 99 раз в 95 постах
Здравствуйте! Вы можете выложить пример OCSP-ответа, который выдает ваша служба и с которым не проходит формирование подписи?
Offline azabrodin  
#3 Оставлено : 23 августа 2013 г. 14:00:29(UTC)
azabrodin

Статус: Участник

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

К сожалению, мне придется вас разочаровать по части формулировки SHALL.

SHALL - это ОБЯЗАТЕЛЬНОЕ требование, потому что это не SHOULD, а SHALL.
Это определено в специальном RFC: http://www.ietf.org/rfc/rfc2119.txt
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest (2)
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.