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