На самом деле в настоящий момент я пишу статью по CAdES и технологиям, связанным с этим видом подписей. Статья также будет затрагивать другие возможности обеспечения долговременного хранения подписей и вопросы предоставления вторичных сервисов. Буду рад по окончанию написания получить критические отзывы :)

Сергей и Андрей, никто (и даже МКС) пока не знает что же это за загадочные реестры и какой у них формат ведения. Вот когда нам всем ясно скажут, то тогда можно будет подискутировать.

Отредактировано пользователем 13 февраля 2014 г. 18:21:02(UTC)  | Причина: Не указана

В Приказе ФСБ 795 про формат сертификатов есть отсылочная норма на RFC 5280, в том смысле что если что не написано в Приказе, то смотри там. Так вот в этой RFC (с названием: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) есть целый раздел про CRL, так что думаю не стоит уж слишком сильно выдумывать и ожидать, что кто то будет расписывать всё в деталях, что и так очевидно и упоминается в НПА. К слову, в Приказе нет отсылки на RFC 2560 (OCSP), к сожалению :-(
А вот то что при аккредитации не сильно углубляются в технические детали - это очень плохо :-(

Отредактировано пользователем 13 февраля 2014 г. 20:03:38(UTC)  | Причина: Не указана

Хотелось бы более внятно, вернувшись к самому первому посту, понять, что у нас есть в части «Грейс-периода» и когда же все таки подпись можно считать действительной.
По сути «Грейс-период» в отношении к исходной задачке - это ни что иное, как реакция некой системы на изменение статуса сертификата. Которая распадается на два направления: организационное и техническое. В организационном плане для нашей задачи существенным будет время на выполнения комплекса процедур (принятие заявки на отзыв от клиента, внутренние согласования и тайм-ауты и т.д. и финалом будет изменение статуса сертификата в базе, Реестре и т.д.). В техническом – процедура опубликования и обеспечение беспрепятственного доступа к информации о статусах.
На сейчас существует единственный НПА нормативно ограничивающий временной предел на эти процедуры – это 63-ФЗ, говорящий о НЕ более 24 часах.
Так вот, работать с временем реакции на изменение статуса менее 24 часов – это добрая воля конкретного УЦ и к технической реализации (использования специальных протоколов статусов – OCSP, VPKC …. или списков CRL, возможно с публикацией дельт) мало относится. Поясню, что проку в «моментальности» OCSP, VPKC или дельт, если в базе информация изменяется по факту только раз в сутки! А отсюда вывод, чтобы работать «по-умолчанию» в режиме публичных систем, следует (чтобы избежать рисков) ориентироваться на 24 часа из 63-ФЗ как максимально допустимое время, если во главу угла ставиться приближение реакции с реал-тайму, то следует изучать Регламент конкретного УЦ, в котором он обязан документально зафиксировать взятые на себя «повышенные обязательства» и время реакции брать оттуда, а сам Регламент сохранять в системе, таким образом, чтобы была возможность на него сослаться при разборе полётов как на юридически значимый документ. Всё остальное, штампы времени, квитки OCSP и ниже с ним, дельты – это всё вторичное.