Роман, спасибо за подробный и аргументированный ответ.

Хуже уже не будет. Если Вы однозначно будете привязывать время перекрытия к периоду публикации, то 12 или 24 часа уже не будет иметь значение. Смысл был именно в независимости этих параметров.
Я понимаю зачем был придуман интервал перекрытия. Это, кстати, довольно не плохо описано в документации к КриптоПро УЦ. И использую я его именно по назначению. Вам, жителям европейской части России сложно представить, как может не быть связи у целого города в течении 2-3 дней или день-два в офисе отсутствовать электроэнергия.... Мне же приходится учитывать и возможность собственной болезни и различные технические казусы и т.п.
Это не так. Передача CRL до CDP осуществляется на съёмном носителе ежедневно, да и ходить далеко мне не нужно (в соседнюю комнату). 3-4 дня это именно запас, позволяющий сделать доставку гарантированной. Если на CDP не окажется действующего CRL (где-нибудь в разгар сдачи налоговой отчётности) пара тысяч клиентов съедят меня живьём...
Это отдельный вопрос. Но сейчас дело совсем не в этом. Хотя если Вы его затронули спрошу, а как этот механизм описать в регламенте УЦ? Я что-то не придумал. Подскажите пожалуйста.
Я описал ситуацию выше. Кроме внесения изменений в регламент УЦ я не вижу других способов решения. Если у Вас будут идеи - я готов их воспринимать.

Отредактировано пользователем 28 сентября 2009 г. 17:47:09(UTC)  | Причина: Не указана

Думаю все-таки, что вы не совсем по назначению используете интервал перекрытия. Он предназначен, чтобы учесть транспортную составляющую механизма публикации. Поясню. Например, если публикация осуществляется копированием файла через http или ftp сразу в пункт CDP, то разумно поставить небольшой интервал перекрытия, скажем, 1 минуту. Если копирование происходит по некоторому расписанию (например, в нашем УЦ есть задача по копированию CRL с компьютера на компьютер), скажем раз в час, то разумно поставить интервал перекрытия 1-2 часа. Если перенос осуществляется человеком, которому идти 5 минут, который работает 8 часов в день, у которого может быть поставлено напоминание в телефоне, но которому позволено инструкцией забыть об этом не более чем до конца рабочего дня, то разумно поставить интервал 8 часов.

Если необходимы боольшие интервалы, то это уже не транспортная составляющая. Это уже сам интервал публикации. Вам удобно иметь большой интервал публикации, который будет включать в себя вероятность отключения энергии на 2-3 дня, вероятность болезни (только легкий насморк , на случай пневмонии уже надо что-то лучшее придумать, скажем, сменщика).

Если сделать наоборот, интервал публикации CRL 4 дня, а интервал перекрытия 1 день, ваши пользователи как видели 5 дней от this update до next update, так и увидят, разница только
в том, что чуть более свежий CRL не будет появляться раз в день в пункте CDP. Это сделает вам жизнь чуть более легкой. Пользователи, которые откачали CRL в первый день после выпуск
а как не приходили за обновлениями следующие 4 дня, так и будут приходить. Однако, в вашем варианте эта часть пользователей, работая в последующие дни, "пропускала" следующие 4 дополнительных CRL, что может и не так здорово. По сравнению с другими пользователями, которые откачивали CRL позже, их "обделили" - дали более старую информацию.



Скорее всего, это так и есть, в регламенте надо закрепить реальное текущее положение дел (ваш срок от this update до next update - 5 дней).
Либо как-то дополнительными орг. мерами обеспечить заявленный срок в 1 день.

Могу немного рассказать про наш действующий УЦ, ведь мы решали точно такие же проблемы. Отключения энергии происходят не только а азиатской части России, и когда ее отключают, то маршрутизаторы у провайдера сети тоже отключаются, CDP становится не доступен, это все знакомо. Решается все в принципе понятными мерами, чуть более мощные UPS, беседы с провайдерам и, чтобы они тоже установили мощные UPS, которые обеспечат работу в нужный интервал времени. Инструкция, которая обеспечит в этот интервал выпуск "длинного" CRL до конца беспорядков. Наличие штата уполномоченных лиц на случай болезни, SMS-оповещения и т.п. В решении этих проблем нам сильно помогает реализованный механизм публикации CRL по расписанию. Расписание можно оперативно менять при возникновении внештатных ситуаций и выпускать "длинные" CRL любой длины.

В регламенте нашего УЦ записано, что он (УЦ) работает с 10:00-18:00 MSK только по рабочим дням, т.е. CRL выпускаются только в это время, когда сотрудники на рабочем месте, раз в час(!).

В принципе, особо добавить нечего.

Позволю себе только несколько лирических замечаний.

ЦС, который выпускает CRL, в котором написано NextUpdate - через неделю, а на самом деле выпустит новый CRL через день - нагло врет своим пользователям. С этой точки зрения интервал перекрытия - измеряет эту "степень лжи". Идеально, когда этот интервал 0. Для небольшого удобства можно пойти на ненулевые значения, но не надо увлекаться.

Все беды, видимо, в желании соответствовать неразумным регламентам условных "торговых площадок". "Торговая площадка" требует ежедневный CRL, хотя инфраструктура не может обеспечить этот срок по объективным причинам. Надо либо менять инфраструктуру, либо скорректировать регламент. Отчего это случается, отчего площадки требуют такой небольшой интервал? Видимо, от принятых неправильных технических решений - в первую очередь, от критической зависимости от отзыва сертификата. Такое возникает, когда на отзыв сертификата возлагают задачу по блокировке работы пользователя или карточки. Мне представляется, что действия по блокировке пользователя/карточки должны быть отделены от отзыва ключа. Системы должны предусматривать особую операцию по блокировке пользователей/карточек, не связанную с отзывом ключа. Отзыв ключа - это крайний случай, когда все остальное не помогло.

Поясню на примерах. У всех сейчас есть пластиковые карты. У меня тоже. Я не большой специалист по "пластику", сужу просто как обыватель. Если бы я потерял карту, позвонил в банк с требованием заблокировать ее, и получил в ответ, что извини, но до конца дня любой злоумышленник сможет пользоваться твоей картой, а потом вот УЦ выпустит CRL и почти все об этом узнают, кроме тех, которые откачивают CRL раз в неделю, то меня это бы совсем не удовлетворило. Срок CRL в один час в этой ситуации мне бы тоже показался очень чрезмерно большим. Хорошо, что банковские карты работают не так. Существует механизм блокировки, который отсчитывается от момента моего обращения, после которого эта карта достаточно быстро перестает проходить процедуру аутентификации на большинстве терминалов.

Другой пример. В ОС Windows можно настроить вход в домен по смарткартам. Некоторые этим пользуются. И я тоже. Предположим, я обнаружил отсутствие у меня карты входа в домен. Если карта попала к злоумышленнику, он мог бы войти в домен от моего имени и совершить много чего. Меня это, естественно, не устраивает. Причем меня не устраивает и ждать до конца дня или даже час. Я просто звоню администратору домена и прошу заблокировать мою учетную запись в домене, дабы ничего плохого не вышло. Вход моментально блокируется, злоумышленники остановлены. Потом я обращаюсь в УЦ с заявлением, что не могу найти ключ, прошу приостановить сертификат. При этом, когда выйдет CRL меня почти не волнует. После чего я начинаю поиски карточки, вспоминаю где я был, где мог ее оставить. Проверяю дома, проверяю в сейфе, в машине и т.п. На это уходит день-другой. Если нахожу, пишу заявление администратору (в УЦ), что компрометации ключа не было потому-то потому-то. Если не нахожу, то пишу в УЦ заявление, что ключ, вероятно, компрометирован, прошу отозвать. После этого администратор еще может учинить разборку, не хотел ли я как-то схитрить на мнимой компрометации и т.п. Потом администратор принимает решение отозвать ключ. И говорит, что в конце недели выйдет CRL, после чего дадим тебе другую карту. Я потерял карту, я сам себя наказал тем, что не мог работать, но домен не пострадал. Если я все-же должен был работать, то администратор создает мне временную учетную запись с новой картой.

Примеры, может, слишком упрощенные, но надеюсь, что мысль ясна.

Небольшой вопросик: а для чего "точность часов УЦ" сделана по дефолту такой большой (10 минут)?

Допустим у меня есть ИВЧ-1, сервер на этих "часах" объявлен мастером и все сервера УЦ (+ у можно еще и АРМы) синхронизируются с ним. Какое д.б. значение "точности часов УЦ" в таком случае?