В том случае, если удостоверяющие центры выпускают сертификаты в соответствии с общими политиками, в дополнении certificatePolicy указываются идентификаторы этих политик, и нет необходимости использовать другие дополнения и ограничения. Когда удостоверяющие центры работают в разных доменах политики, то процедуры согласования политик становятся более сложными [84] и требуется тщательный анализ соответствия политики каждого УЦ политикам других удостоверяющих центров. Отношения между политиками фиксируются в дополнении соответствия политик policyMappings. Это дополнение сертификата позволяет удостоверяющим центрам задавать ограниченный набор приемлемых политик и отклонять сертификаты, выпущенные в соответствии с неприемлемой для данного УЦ политикой. Кроме того, функциональная совместимость доменов может достигаться в результате заключения формальных соглашений между корпоративными доменами, желающими взаимодействовать в соответствии с одной или несколькими междоменными политиками.
ППС обеспечивает определенный уровень доверия доверяющей стороны к сертификату, изданному на условиях, описанных в этой политике. Если, например, организация передает функции УЦ на аутсорсинг и ей необходим очень надежный сертификат, то она может запросить от УЦ сертификат высокого уровня безопасности. В этом случае УЦ, прежде чем выпустить сертификат, будет выполнять огромное число проверок. Другой крайностью может быть выдача сертификатов, перед выпуском которых выполняется минимальная проверка, например, правильности адреса электронной почты будущего владельца сертификата.
Регламент описывает процессы и процедуры выполнения УЦ операций с сертификатами. ППС характеризует надежность конкретного сертификата, а регламент - надежность самого УЦ. ППС разрабатывается на достаточно длительный срок и должна удовлетворять строгим требованиям, обычно она излагается в соответствии с форматом описания политики, который задает документ RFC 2527 Certificate Policy and Certification Practices Framework [152]. Этот документ содержит стандартный иерархический набор положений, сгруппированный в 8 основных разделов и 185 подразделов второго и третьего уровней (подробное описание формата ППС и регламента УЦ см. в лекции 14). Примерный перечень положений служит ориентиром при описании политики применения сертификатов и разработке регламента УЦ и помогает разработчикам политики и регламента не упустить важные моменты.
Соглашение между УЦ и РЦ
Это соглашение охватывает все стороны отношений между УЦ и РЦ. Если УЦ и РЦ являются компонентами модели инсорсинга, то соглашение между ними упрощается и приобретает статус внутреннего юридического соглашения между УЦ (обычно работающим под управлением ИТ-штата) и РЦ (обычно функционирующим под управлением штата, занимающегося административной и операционной работой). В любом случае это соглашение обязательно должно проходить процедуру утверждения и содержать следующие положения:
* размере компенсации РЦ удостоверяющему центру;
* финансовых гарантиях непрерывности функционирования УЦ;
* размере компенсации УЦ доверяющей стороне в случае выпуска фальшивого сертификата.
Соглашение между конечным субъектом и РЦ
Это соглашение описывает отношения между пользователем сертификата и РЦ той организации, которая выпустила данный сертификат. Соглашение должно включать обязательства пользователя:
* предоставлять правдивую информацию, которая используется при выпуске сертификата;
* использовать сертификат в соответствии с регламентом УЦ;
* обращаться с заявлением об аннулировании сертификатов, если соответствующие секретные ключи потеряны или скомпрометированы;
* прекращать использование всех пар ключей (открытый/секретный), срок действия которых истек, и не стараться выдать их за действующие ключи.
Соглашение между конечным субъектом и УЦ
Это соглашение можно назвать соглашением с доверяющей стороной. Оно содержит следующие положения:
* обязательство доверяющей стороны проверять статус сертификата перед его использованием, то есть убеждаться в том, что сертификат не просрочен и не аннулирован;
* обязательство доверяющей стороны использовать сертификат только по назначению, то есть в целях, установленных ППС и регламентом УЦ;
* размеры компенсации РЦ или УЦ в случае причинения ущерба доверяющей стороне.
В моделях аутсорсинга все эти соглашения уже существуют. В моделях инсорсинга требуется тщательное составление таких соглашений.
Модель доверия и архитектура PKI
Фундаментом доверия PKI являются надежные сертификаты открытых ключей. Надежность сертификатов открытых ключей зависит от надежности удостоверяющих центров, которые их подписывают. Это допущение формирует отношения доверия между различными сторонами - участниками системы PKI и позволяет конечным субъектам считать свои транзакции надежными.
Широкомасштабное развертывание PKI может вовлекать в инфраструктуру многие удостоверяющие центры, которые выпускают разнообразные сертификаты, создавая множественные отношения доверия в зависимости от области применения сертификатов, типов используемых приложений, пользователей сертификатов и видов деловых операций. Для обеспечения функциональной совместимости компонентов PKI должны быть определены отношения между этими удостоверяющими центрами и задана архитектура PKI.
Отношения между взаимодействующими удостоверяющими центрами формируют один или несколько путей сертификации, в результате верификации которых принимается решение о доверии к сертификату участника системы PKI. Организации, развертывающей PKI, необходимо определить, как строить пути сертификации и подтверждать надежность сертификатов. В PKI закрытой корпоративной системы все владельцы сертификатов работают в одной организации, доверяют одному и тому же УЦ, и путь сертификации строится на базе корневого сертификата этого центра.
При развертывании PKI сложной структуры организация должна определить, будет ли она доверять сертификатам пользователей и приложений только своего домена доверия или других доменов тоже. Как уже упоминалось ранее, домен доверия, или домен политик, характеризуется набором политик, в соответствии с которыми выпускает сертификаты данный УЦ. Если принимается решение о доверии ограниченному набору доменов, то должны быть выпущены кросс-сертификаты и тем самым внедрена в другие домены модель доверия данной организации. Если организация планирует использовать, например, приложение глобальной защищенной электронной почты, то потребуется более сложная структура кросс-сертификации всех входящих в состав PKI удостоверяющих центров, способная обеспечить построение путей сертификации между любыми двумя владельцами сертификатов из любых доменов доверия.