Ольга Полянская - Инфраструктуры открытых ключей

Отличительные имена поддерживаются и в сертификатах формата X.509, но при этом разрешено использование альтернативных имен субъектов, таких как IP-адрес или адрес электронной почты, чтобы гарантировать уникальность имени субъекта и обеспечить связь с другими механизмами идентичности.

Строгая иерархия удостоверяющих центров обычно графически изображается в виде древовидной структуры с корнем наверху и ветвями, спускающимися вниз и заканчивающимися листьями. В этом перевернутом дереве корень представляет определенный УЦ, который обычно называется корневым(или головным) и действует как главный пункт, или корень, доверия для целого домена подчиненных ему субъектов PKI. Под корнем располагаются промежуточные удостоверяющие центры. Промежуточные удостоверяющие центры представлены в древовидной структуре промежуточными узлами, от которых отходят следующие ветви. Листья, или конечные вершины дерева, соответствуют субъектам PKI, не являющимся удостоверяющими центрами, их называют конечными субъектамиили просто конечными пользователями( см. рис. 5.1).

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

Рис. 5.1. Строгая иерархия удостоверяющих центров

В модели строгой иерархии удостоверяющих центров все субъекты иерархии доверяют одному головному УЦ (будем использовать этот аналог термина "корневой" как более традиционный и понятный) [124]. Иерархия строится следующим образом.

1Создается головной УЦ, который генерирует и подписывает сертификат для самого себя. Сертификат головного УЦ называют самоизданным(или самоподписанным) корневым сертификатом, именно он составляет основу доверия всех субъектов данной строгой иерархии.

2Головной УЦ сертифицирует, то есть выпускает и подписывает сертификаты для удостоверяющих центров, непосредственно ему подчиненных. Количество подчиненных удостоверяющих центров может быть и нулевым, то есть подчиненные центры могут отсутствовать.

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

4На уровнях иерархии от второго до последнего удостоверяющие центры сертифицируют конечных субъектов.

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

Пример 5.1. Рассмотрим, как конечный пользователь А , владеющий доверенной копией открытого ключа головного УЦ, может проверить подлинность, то есть верифицироватьсертификат другого конечного субъекта В . Предположим, что сертификат субъекта В подписан УЦ 2 , чей сертификат в свою очередь подписан УЦ 1 , сертификат которого заверен головным УЦ. Субъект А при помощи открытого ключа головного УЦ - k г может верифицировать сертификат УЦ 1 и извлечь доверенную копию открытого ключа УЦ 1 - k 1 . Затем этот ключ может быть использован для верификации сертификата УЦ 2 , в результате которой становится известна доверенная копия открытого ключа УЦ 2 - k 2 Ключ k 2 может быть использован для верификации сертификата субъекта В и получения доверенной копии его открытого ключа - k В . Субъект А может теперь использовать ключ k В (в зависимости от его типа) для шифрования сообщений, адресованных субъекту В , или проверки цифровых подписей, которые создал субъект В . Описанная процедура позволяет обеспечить защищенную связь между субъектами А и В .

Идея строгой иерархии, когда все доверие при любых обстоятельствах базируется на корне иерархии, подходит не для всех областей PKI. "Нестрогая иерархия" удостоверяющих центров позволяет доверяющим сторонам, сертифицированным одним и тем же УЦ, строить доверенный путь, не вовлекая в этот процесс никакие вышестоящие удостоверяющие центры, в том числе головной УЦ. В этом случае локальная политика разрешает доверяющим сторонам при проверке сертификатов друг друга полагаться непосредственно на общий для них локальный УЦ.

Если сертификаты пользователей А и В выпущены одним и тем же УЦ 2 , то пользователи могут проверять сертификаты друг друга без построения пути сертификации к головному УЦ только в том случае, когда пользователи относятся к иерархии одного и того же доверенного издателя. Однако, если сертификат пользователя C издан не УЦ 2 , а другим УЦ, то для проверки сертификата C пользователи А и В должны строить полный пути сертификации через головной УЦ, заверивший сертификат пользователя C . Таким образом, если доверяющая сторона оценивает сертификат, выпущенный сторонним УЦ, то должна выполнять валидацию пути сертификации в соответствии с требованиями строгой иерархии.