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