Важнейшим вопросом в смысле возможных правовых последствий применения электронной цифровой подписи является вопрос: когда сертификат становится валидным. Выпуск сертификата открытого ключа и подписание его УЦ после аутентификации лица, обращающегося с запросом о выдаче сертификата, не являются достаточным условием для придания сертификату статуса валидного. Сертификат становится валидным только после его открытой публикации в репозитории PKI, и наоборот, сертификат теряет статус валидного после его включения в список аннулированных сертификатов и публикации последнего [10].
Рис. 7.3. Жизненный цикл сертификата
Некоторые удостоверяющие центры требуют, чтобы пользователь, обращающийся с запросом о выдаче сертификата, стал подписчиком УЦ, прежде чем сертификат этого пользователя будет опубликован в репозитории.
На практике сертификат может быть отправлен пользователю вместе с договором подписчика с условием, что пользователь не будет использовать сертификат, пока формально не подпишет договор. Как только УЦ получает согласие пользователя, то публикует сертификат в открытом репозитории, придавая сертификату правовую силу, после этого сертификат и открытый ключ становятся общедоступными в PKI.
Пользователи нуждаются в сертификатах, различных по уровню безопасности и дополнительным возможностям управления сертификатами. Обычно пользователь имеет, по крайней мере, две пары ключей: одну пару для шифрования, а другую - для электронной цифровой подписи. Политикой PKI должны быть определены типы выпускаемых сертификатов и их сроки действия. Вообще говоря, теоретически сертификаты могут действовать в течение длительного времени, но из практических соображений многие сертификаты имеют ограниченный срок действия, позволяющий уменьшить риск их неправильного употребления.
Большинство персональных сертификатов действуют в течение одного-двух лет после выпуска, а сертификаты серверов обычно сохраняют свою силу два года и более. Для целей архивирования и долговременного шифрования используются специальные сертификаты с длительным периодом действия.
Рис. 7.3 иллюстрирует жизненный цикл сертификата. Стрелки, которые отображают нормальный жизненный цикл, выделены более ярко, в отличие от тех стрелок, которыми отмечены моменты вмешательства УЦ или РЦ. Так, например, в корпоративной PKI, где владельцами сертификатов являются служащие организации, вмешательство УЦ в нормальный жизненный цикл сертификата требуется в случаях:
1 аннулирования сертификата при увольнении служащего, владеющего этим сертификатом;
2 аннулирования сертификата при утере служащим своего секретного ключа или пароля доступа к секретному ключу;
3 приостановления действия сертификата, выпущенного для служащего, который в данный момент времени увольняется или находится под следствием;
4 возобновления сертификата служащего при отказе от увольнения или после прояснения обстоятельств судебного дела и т.п.
Иногда в PKI выпускаются сертификаты с различными сроками действия для служащих в зависимости от их статуса, например, служащие, работающие по контракту, могут иметь сертификаты на период их запланированной работы, а постоянные работники - сертификаты, обновляемые через каждые 12 месяцев.
Примерные сценарии управления жизненным циклом сертификатов и ключей
Рассмотрим возможные сценарии управления жизненным циклом сертификатов и ключей PKI, предполагая, что политикой применения сертификатов установлен срок действия сертификата открытого ключа - 1 год, секретного ключа - 10 лет, цифровой подписи - 25 лет с момента подписания электронного документа [80].
Пример 7.1. Пусть секретный ключ используется для подписания деловых контрактов. Так как срок действия секретного ключа - 10 лет и ключ был создан в начале 2000 года, то он должен храниться до начала 2010 года. На рис. 7.4 символом Х в середине 2001 года помечен момент подписания контракта, который будет действовать до середины 2026 года. Цифровая подпись этого документа остается действительной по истечении срока действия секретного ключа, который использовался для создания этой подписи, поэтому открытый ключ должен храниться дольше секретного, так как он будет использоваться для верификации цифровой подписи и после окончания действия секретного ключа. Действительно, вполне вероятно, что другой электронный документ будет подписан в конце 2009 года непосредственно перед тем, как истечет срок действия секретного ключа, следовательно, открытый ключ должен храниться, по крайней мере, до 2035 года, потому что он может потребоваться для верификации цифровой подписи спустя 25 лет после подписания документа.
Рис. 7.4. Сценарий использования секретного ключа для подписания деловых контрактов
В период 2010-2035 годов секретный ключ не может быть скомпрометирован, так как он либо уничтожается, либо защищенно хранится в архиве, таким образом, нет необходимости устанавливать более длительный срок хранения сертификата открытого ключа.
Пример 7.2. Рассмотрим более сложный случай: компрометацию секретного ключа подписи. На рис. 7.5 момент компрометации помечен символом Х в начале 2002 года. После обнаружения компрометации секретного ключа УЦ вносит сертификат соответствующего открытого ключа в список аннулированных сертификатов.
Если последний документ был подписан при помощи секретного ключа (до его компрометации) в начале 2002 года, то открытый ключ должен оставаться доступным до начала 2027 года, следовательно, сертификат открытого ключа должен быть доступен, несмотря на то, что он внесен в список аннулированных сертификатов.
Рис. 7.5. Сценарий компрометации секретного ключа подписи
Политика PKI должна определять, может ли надежность документа, подписанного до компрометации секретного ключа, подтверждаться в результате верификации подписи при помощи старого открытого ключа, или же для этой цели должен быть создан новый сертификат. В процессе развертывания PKI и выработки политики должны быть проанализированы все возможные сценарии управления жизненным циклом сертификатов и ключей и оценены последствия компрометации ключей.
Лекция 8. Формат списков аннулированных сертификатов
Описываются способы проверки статуса сертификата, дается краткая характеристика механизмам периодической публикации информации об аннулированных сертификатах, вводится определение списка аннулированных сертификатов (САС), подробно рассматривается структура САС, обсуждаются стандартные дополнения САС и дополнения точек входа в САС, дается представление о дельта-списках САС, приводятся коды причин аннулирования сертификатов.
Списки аннулированных сертификатов
УЦ выпускает сертификат только после проверки той информации, которая включается в содержание сертификата. Если информация неверна или сертификат утратил валидность, УЦ должен его аннулировать. Существует множество причин, по которым сертификат аннулируется до истечения срока его действия: компрометация секретного ключа, политика безопасности конкретной организации в отношении сертификатов уволившихся служащих и др. В таких ситуациях конечные субъекты PKI должны быть своевременно проинформированы о том, что дальнейшее использование сертификата больше не считается безопасным.
Традиционным инструментом распространения информации об аннулировании сертификатов являются публикуемые в репозитории списки аннулированных сертификатов (САС), которые содержат уникальные серийные номера всех аннулированных сертификатов. Цифровая подпись, сопровождающая САС, обеспечивает его целостность и аутентичность. Обычно САС подписывается тем же субъектом, который подписал сертификаты, указанные в списке. Однако САС может быть подписан не только издателем сертификатов.
Статус сертификата на предмет аннулирования должен проверяться перед каждым его использованием. Поэтому PKI должна поддерживать масштабируемую систему аннулирования сертификатов. Удостоверяющий центр должен иметь возможность безопасно публиковать информацию о статусе каждого сертификата данного PKI-домена. Клиентское программное обеспечение перед использованием любого сертификата должно проверять эту информацию от имени пользователя. Существуют три способа проверки статуса сертификата [80].
