Типы списков аннулированных сертификатов и схемы аннулирования

Механизмы онлайновых запросов

Обсудим механизмы онлайновых запросов для поиска информации об аннулировании сертификатов. Онлайновые механизмы в некотором отношении отличаются от механизмов периодической публикации - в основном тем, что онлайновые механизмы обычно требуют, чтобы доверяющая сторона была доступна (находилась на связи) в любой момент, когда бы ни решался вопрос о статусе сертификата. Механизмы периодической публикации лучше подходят для автономной работы, потому что информация об аннулировании может размещаться в кэш-памяти. Кэширование информации, получаемой по онлайновым запросам, не всегда согласуется с требованием гарантированного предоставления доверяющей стороне в любой момент самой "свежей" информации.

Разработкой онлайновых протоколов статуса сертификата занималась рабочая группа IETF PKIX. В июне 1999 года онлайновый протокол статуса сертификата Online Certificate Status Protocol ( OCSP ) был предложен в качестве стандарта RFC 2560 [155]. Поскольку это был первый шаг в разработке протоколов такого рода, функциональность OCSP была намеренно ограничена его разработчиками.

Онлайновый протокол статуса сертификата

Онлайновый протокол статуса сертификата OCSP - относительно простой протокол (типа "запрос-ответ") для получения информации об аннулировании от доверенного субъекта, называемого OCSP-респондером . OCSP-запрос состоит из номера версии протокола, типа запроса на обслуживание и одного или нескольких идентификаторов сертификатов. Идентификатор сертификата включает хэш-коды отличительного имени и открытого ключа издателя сертификата, а также серийный номер сертификата. В запросе иногда могут присутствовать необязательные дополнения.

OCSP-ответ также достаточно прост и состоит из идентификатора сертификата, статуса сертификата ("нормальный", "аннулированный" или "неизвестный") и срока действия ответа, связанного с идентификатором каждого указанного в исходном запросе сертификата. Если сертификат имеет статус аннулированного, то отображается время аннулирования и может быть указана причина аннулирования (необязательно). Срок действия задается интервалом от текущего обновления (параметр This Update ) до следующего обновления (параметр Next Update ). Ответ может содержать необязательные дополнения, а также код ошибки, если обработка запроса не была завершена корректно.

Рис. 9.4 иллюстрирует взаимодействие между доверяющей стороной и OCSP-респондером. OCSP-сервер может поддерживать разные стратегии аннулирования, на рисунке они отображаются в прямоугольнике, помеченном как внутренняя база данных. OCSP-ответы должны быть заверены цифровой подписью, гарантирующей, что ответ исходит от доверенного субъекта и не был изменен при передаче. Ключ подписи может принадлежать тому же УЦ, который выпустил данный сертификат, доверенной третьей стороне или субъекту, которому издатель сертификата делегировал право подписи [155].

увеличить изображение
Рис. 9.4. Взаимодействие OCSP-компонентов

В любом случае доверяющая сторона должна доверять ответу на запрос, что подразумевает доверие к тому, кто подписал ответ. Следовательно, доверяющая сторона должна получить копию сертификата открытого ключа OSCP-респондера, и этот сертификат должен быть подписан доверенным источником. Запросы также могут заверяться цифровой подписью (например, если OCSP-респондер действует как платный сервис), но это - необязательная опция протокола OCSP. Информация о местонахождении OCSP-респондера, отвечающего на запросы о статусе данного сертификата, содержится в самом сертификате в дополнении Authority Information Access [167]. Дополнение Distribution Points используется для указания на часть САС.

протокол OCSP разрабатывался исключительно для поддержки сообщений о статусе сертификатов и не позволяет определять валидность сертификата. Другими словами, протокол OCSP не подтверждает, что сертификат не был просрочен, и не гарантирует, что сертификат используется в точном соответствии с назначением, которое обычно указывается в дополнениях данного сертификата: Key Usage, Extended Key Usage или Policy Qualifier. Кроме того, доверяющим сторонам не стоит переоценивать возможности протокола доставлять самую "свежую" информацию об аннулировании сертификатов в режиме реального времени. Даже если сам протокол предлагает ответ на запрос в режиме реального времени (в предположении, что OCSP-респондер доступен в онлайновом режиме для обслуживания запросов), это не обязательно означает, что протокол OCSP -ответ о текущем состоянии сертификата придет без задержки, особенно если сервисы УЦ и OCSP-респондера реализованы на одном сервере. То есть доверяющим сторонам не стоит полагаться на то, что по протоколу OCSP автоматически доставляется самая "свежая" информация, даже если считается, что информирование о статусе сертификатов - это сервис реального времени.

К тому же, поскольку в целях обеспечения целостности ответы от OCSP-респондера при передаче их доверяющей стороне должны быть заверены цифровой подписью, этот процесс может создать серьезную нагрузку на сетевые ресурсы.

Простой протокол валидации сертификатов

Простой протокол валидации сертификатов (Simple Certificate Validation Protocol - SCVP) разрабатывался рабочей группой PKIX для обеспечения делегирования процессов валидации и обнаружения пути сертификации доверенным сторонам в среде Интернет [91]. Делегированная валидация пути (Delegated Path Validation - DPV) позволяет доверяющей стороне переложить процесс валидации пути сертификации на доверенную третью сторону. Это имеет смысл в тех средах, где локальная валидация пути невозможна или нежелательна, а также в случае поддержки в среде централизованной политики валидации. По аналогии с DVP делегированное обнаружение пути (Delegated Path Discovery - DPD) позволяет доверяющей стороне поручить трудоемкий процесс построения пути сертификации доверенной третьей стороне. Это избавляет доверяющую сторону от необходимости поиска сертификатов, составляющих путь сертификации.

Другие режимы аннулирования

Бывают обстоятельства, когда прямое распространение информации об аннулировании доверяющей стороне бывает невозможным или нежелательным. Существуют, по крайней мере, два случая. Первый случай касается краткосрочных сертификатов, период действия которых настолько мал, что не имеет смысла их аннулировать. Например, организация может установить окно аннулирования не более 8 часов. Если выпускаемые ею сертификаты действуют не более 8 часов, то их не нужно аннулировать. Такая политика может поддерживаться только в относительно закрытых средах, где легко решаются проблемы производительности, связанные с непрерывным обновлением сертификатов. Тогда клиентское ПО доверяющих сторон должно быть настроено таким образом, чтобы при проверке валидности сертификатов не выполнялся поиск информации об аннулировании. В этом случае в краткосрочных сертификатах просто указывается идентификатор объекта (OID) соответствующей политики.

Второй случай встречается тогда, когда одобрение любой транзакции исходит от одного и того же субъекта. Это характерно для банковского сектора, где онлайновые транзакции всегда проходят через банк клиента. Банк использует свою базу данных, чтобы установить соответствие между клиентом и счетом, к которому ему разрешен доступ. Поскольку информация об аннулировании может поддерживаться на основе данных о счетах клиентов и все транзакции проходят через банк, нет необходимости передавать эту информацию на компьютер клиента. Точно так же происходит авторизация транзакций по дебетовым или кредитным картам при совершении сделок через торговые web-сайты. В процессе авторизации финансовой транзакции продавец должен обратиться в банк покупателя и подтвердить валидность сертификата клиента. Отметим, что во втором случае не исключена поддержка аннулирования, но она не обязательно должна базироваться на приведенных выше схемах.