Книга: Инфраструктуры открытых ключей
Списки аннулированных сертификатов
УЦ выпускает сертификат только после проверки той информации, которая включается в содержание сертификата. Если информация неверна или сертификат утратил валидность, УЦ должен его аннулировать. Существует множество причин, по которым сертификат аннулируется до истечения срока его действия: компрометация секретного ключа, политика безопасности конкретной организации в отношении сертификатов уволившихся служащих и др. В таких ситуациях конечные субъекты PKI должны быть своевременно проинформированы о том, что дальнейшее использование сертификата больше не считается безопасным.
Традиционным инструментом распространения информации об аннулировании сертификатов являются публикуемые в репозитории списки аннулированных сертификатов (САС), которые содержат уникальные серийные номера всех аннулированных сертификатов. Цифровая подпись, сопровождающая САС, обеспечивает его целостность и аутентичность. Обычно САС подписывается тем же субъектом, который подписал сертификаты, указанные в списке. Однако САС может быть подписан не только издателем сертификатов.
Статус сертификата на предмет аннулирования должен проверяться перед каждым его использованием. Поэтому PKI должна поддерживать масштабируемую систему аннулирования сертификатов. Удостоверяющий центр должен иметь возможность безопасно публиковать информацию о статусе каждого сертификата данного PKI-домена. Клиентское программное обеспечение перед использованием любого сертификата должно проверять эту информацию от имени пользователя. Существуют три способа проверки статуса сертификата>[80].
1 Способ извлечения ("pull") или проверки с опросом наличия изменений. Этот способ заключается в том, что клиентское приложение периодически выполняет поиск в репозитории последней версии САС и использует ее для проверки статуса сертификата. Приложение выполняет "вытягивание" списка аннулированных сертификатов при каждом запланированном обновлении списка.
2 Способ проталкивания ("push") или принудительной рассылки изменений, при котором удостоверяющий центр рассылает приложениям, использующим сертификаты, новый САС всякий раз, когда какой-либо сертификат аннулируется.
3 Способ онлайновой верификации или использования онлайнового протокола статуса сертификата ( Online Certificate Status Protocol - OCSP ). Сервер удостоверяющего центра, известный как OCSP-респондер, в режиме реального времени обрабатывает запросы приложений о статусе сертификатов и предоставляет заверенные цифровой подписью ответы о текущем состоянии каждого сертификата. Ответ содержит информацию об идентификаторе сертификата, его статусе (нормальный, аннулированный, неизвестный), периоде действия, а при необходимости - о времени и причине аннулирования>[2].
К механизмам периодической публикации информации об аннулированных сертификатах относятся:
* полные списки САС ;
* списки аннулирования сертификатов удостоверяющих центров ( САС УЦ);
* списки аннулирования сертификатов конечных субъектов ( САС КС);
* пункты распространения САС (также известные как частичные списки САС );
* дельта-списки и косвенные дельта-списки САС ;
* косвенные списки САС ;
* переадресующие списки САС ;
* деревья аннулирования сертификатов.
В полной системе аннулирования сочетаются публикация и последующее использование информации об аннулировании сертификатов. УЦ аннулирует сертификат, включая его серийный номер в САС. Синтаксис САС также разрешает УЦ приостанавливать действие сертификатов. Сертификат, действие которого приостановлено, передается на хранение. УЦ может затем аннулировать сертификат или возобновить его действие.
Формат списка аннулированных сертификатов
Формат списка аннулированных сертификатов определен в рекомендациях Международного Союза по телекоммуникациям ITU (X.509) и документах PKIX >[167]. Существуют две различные версии САС, первая версия описывалась в первых спецификациях X.509. Сейчас списки САС первой версии не используются, поскольку они не позволяют решать проблемы масштабируемости и добавлять необходимые функции, а также не способны противостоять атакам подмены. В настоящее время общепринята вторая версия списков САС (см. табл. 8.1), в которой перечисленные проблемы решены при помощи дополнений.
Дополнения могут быть помечены как критичные и некритичные. Некритичные дополнения могут быть проигнорированы, если доверяющая сторона их не понимает (без каких-либо действий с ее стороны). Критичные дополнения должны обрабатываться доверяющей стороной и быть понятны ей. Даже если некоторые дополнения не распознаются, доверяющая сторона должна, по крайней мере, понимать, что сертификаты, перечисленные в списке, аннулированы. Однако без распознавания определенных дополнений невозможно оценить, является ли САС полным.
Список аннулированных сертификатов (Certificate Revocation List - CRL) представляет собой структурированную двоичную запись в формате абстрактной синтаксической нотации ASN.1. Структура, располагающаяся в верхней части САС, подобна конверту для содержания списка и состоит из трех полей:
1 первое поле tbs Cert List - это заверенное цифровой подписью содержание списка аннулированных сертификатов, который должен быть подписан (tbs - сокращение от английского выражения "to-be-signed", означающего "быть подписанным");
2 второе поле Signature Algorithm содержит идентификатор алгоритма цифровой подписи, который применил издатель САС для подписания этого списка. Идентификатор алгоритма задается при помощи соответствующего идентификатора объекта (OID). Значение поля должно совпадать со значением идентификатора алгоритма, указываемого в соответствующем поле САС ;
3 третье поле Signature Value содержит значение цифровой подписи, вычисленной на основе содержания САС ; значение подписи - это строка битов в формате ASN.1.
После этой структуры следует непосредственно содержание списка, который подписывается. САС состоит из набора обязательных полей и нескольких опциональных дополнений. В содержании всегда указывается идентификатор алгоритма цифровой подписи, имя издателя и дата выпуска САС. В соответствии со стандартом RFC 3280 >[167] рекомендуется включать дату выпуска нового САС, несмотря на то, что поле Next Update (следующее обновление) считается необязательным, а использование этого поля значительно усложняет валидацию сертификата.
Если аннулированных сертификатов нет, часть структуры списка, описывающая аннулированные сертификаты, отсутствует. Если аннулированные сертификаты имеются, то каждый из них, представляющий собой вход в САС, задается структурой, которая состоит из серийного номера сертификата, даты аннулирования и необязательных дополненийточек входа в САС. Дополнения точек входа в САС ( CRL Entry Extensions ) описывают данные одного аннулированного сертификата, помимо которых в состав содержания САС входят дополнения САС ( CRL Extensions ), характеризующие весь список аннулированных сертификатов в целом. Структура САС X.509 v2 приведена в табл. 8.1.
|Поле | Содержание |
|Version | Версия (1 означает v2) |
|signature | Идентификатор алгоритма цифровой подписи |
|issuer | Уникальное имя издателя САС(УЦ) |
|thisUpdate | Дата выпуска текущего САС |
|nextUpdate | Планируемая дата выпуска следующего САС |
|revokedCertificates
.
user Certificate
revocation Date
cRLEntryExtensions
| Перечень аннулированных сертификатов.
Для каждого сертификата указываются:
1) серийный номер;
2) дата аннулирования;
3) дополненияточки входа в САС
|
|cRLExtensions | Дополнительная информация, характеризующая САСв целом |
|signatureAlgorithm | Идентификатор алгоритма цифровой подписи |
|signatureValue | Значение цифровой подписи (строка битов) |
Таблица 8.1.Структура списка аннулированных сертификатов X.509 v2
Необязательное поле Version при помощи номера версии задает синтаксис САС, это поле заполняется только в списке второй версии, поскольку в формате САС первой версии оно не представлено.
Поле Signature идентифицирует алгоритм цифровой подписи, который используется издателем САС при подписании списка. Это поле должно содержать тот же самый идентификатор алгоритма, задаваемый идентификатором объекта (OID), что и соответствующее поле Signature Algorithm в структуре, располагающейся в верхней части списка (см. выше).
Обязательное поле Issuer содержит отличительное имя издателя САС (в соответствии со стандартом X.500). Документ RFC 3280 >[167] требует, чтобы это поле не было пустым, в нем указываются идентификационные признаки УЦ. Если УЦ делегирует некоторые или все функции по поддержке САС другому центру, то включает в выпускаемые сертификаты дополнение CRL Distribution Point. Issuer.
Поле This Update указывает дату выпуска текущего САС. Дата может быть представлена в одном из двух возможных форматов: в обобщенном формате времени или в формате скоординированного универсального времени UTC (Universal Coordinated Time). Издатель САС должен использовать формат UTC для дат до 2049 года включительно и обобщенный формат времени для дат после 2050 года.
Поле Next Update отображает дату выпуска следующего САС. Здесь также поддерживаются два формата времени. Следующий САС необходимо выпустить не позднее указанной даты. Издатель САС должен включать это поле в состав содержания САС, хотя формально оно не является обязательным.
Поле Revoked Certificates содержит перечень аннулированных сертификатов. Эта структура необязательна, но может отсутствовать только тогда, когда отсутствуют аннулированные сертификаты, срок действия которых не истек. В поле указываются:
* серийные номера аннулированных сертификатов user Certificate ;
* их даты аннулирования Revocation Date (в одном из двух форматов времени);
* необязательные дополненияточек входа в САСCRL Entry Extensions.
Каждый аннулированный сертификат является отдельным входом в САС. Сертификаты уникально идентифицируются комбинацией имени и серийного номера. Чаще всего издатель сертификата и издатель САС - это один и тот же УЦ, поэтому имя издателя указывается один раз и применяется ко всему списку серийных номеров. Если издатель САС и издатель сертификата - разные лица, то имя издателя указывается в паре с серийным номером каждого сертификата.
Поле CRL Extensions используется для включения дополнительной информации, характеризующей САС в целом.
- Хранение сертификатов и САС в архиве
- Лекция 8. Формат списков аннулированных сертификатов
- Лекция 9. Типы списков аннулированных сертификатов и схемы аннулирования
- Выявление в пути сертификации аннулированных сертификатов
- Выпуск сертификатов
- Деревья аннулирования сертификатов
- Формат сертификатов
- Классы сертификатов
- Стандартные списки
- Отправка данных в списки SharePoint по электронной почте
- Списки, запятые и командные строки
- Нумерованные и маркированные списки