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-сайты. В процессе авторизации финансовой транзакции продавец должен обратиться в банк покупателя и подтвердить валидность сертификата клиента. Отметим, что во втором случае не исключена поддержка аннулирования, но она не обязательно должна базироваться на приведенных выше схемах.
Сравнительная характеристика разных схем аннулирования
Пока не накоплено достаточно информации об эффективности функционирования крупномасштабных PKI, можно сделать лишь некоторые предположения по поводу характеристик масштабируемости, скорости обработки и своевременности разных способов распространения информации об аннулировании, которые были рассмотрены в лекции. Главное - понять принципы разных схем аннулирования, чтобы сделать правильный выбор для конкретного PKI-домена или группы взаимодействующих PKI-доменов.
Вероятнее всего в средах с большим количеством пользователей при использовании полных списков САС не удастся избежать проблем масштабирования. Порог, при котором масштабирование становится проблемой, зависит от нескольких факторов, включая количество пользователей, период действия сертификатов и частоту аннулирования. Пункты распространения САС позволяют значительно повысить скорость обработки списков САС и масштабируемость, а для более эффективного и своевременного распространения информации об аннулировании с пунктами распространения САС могут комбинироваться дельта-списки САС.