Читать онлайн «Инфраструктуры открытых ключей». Страница 28

Сертификаты удостоверяющих центров корпоративной PKI

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

1 использовать в качестве имени субъекта отличительное имя (отличительное имя стандарта X.500 или DNS-имя); имя субъекта должно быть образовано только из рекомендуемых атрибутов имен каталогов, а любая часть имени субъекта, совпадающая с именем издателя, должна быть задана тем же типом строки;

2 устанавливать срок действия, начинающийся с момента выпуска сертификата и заканчивающийся тогда, когда истекает срок действия всех сертификатов, цифровые подписи которых могут быть проверены при помощи ключа в данном сертификате. Нежелательно устанавливать срок действия свыше 5 лет;

3 не использовать открытые ключи, связанные с алгоритмами Диффи-Хэллмана, эллиптических кривых Диффи-Хэллмана и обмена ключами; если используется RSA-ключ, то в качестве его назначения не должна указываться транспортировка ключей;

4 задавать дополнение Basic Constraints (основные ограничения) как критичное; устанавливать параметр cA в значение TRUE ; если корпоративная PKI является иерархической, то указывать значение длины пути;

5 задавать дополнение Key Usage (назначение ключа) как критичное, указывать значения: подписание сертификата открытого ключа и подписание САС;

6 задавать дополнение Certificate Policies (политики применения сертификатов) как некритичное; в нем должны быть перечислены все политики, которые УЦ субъекта может включать в подчиненные сертификаты; перечисленные политики не должны содержать никаких спецификаторов;

7 задавать дополнение Subject Key Identifier (идентификатор ключа субъекта) как некритичное; его значение должно сравниваться со значением дополнения Authority Key Identifier (идентификатор ключа УЦ) в сертификатах, изданных УЦ субъекта;

8 задавать дополнение Subject Information Access (доступ к информации о субъекте) как некритичное и указывать репозиторий, который содержит сертификаты, изданные субъектом.

В соответствии с требованиями конкретной локальной среды сертификат может содержать и другие дополнения, они должны быть помечены как некритичные.

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

К содержанию сертификата УЦ, используемого в среде нескольких корпоративных PKI, предъявляются практически те же требования, что и к содержанию сертификата УЦ корпоративной PKI, за исключением двух пунктов, касающихся соответствия политик и ограничений на имена [70]. В сертификате УЦ, который участвует во взаимодействии между разными корпоративными PKI, необходимо:

1 задавать дополнение Policy Mappings (соответствие политик) как некритичное и устанавливать в нем только соответствие политик издателя, которые указаны в дополнении Certificate Policies ;

2 задавать дополнение Name constraints (ограничения на имена) как критичное. Исключать поддеревья в иерархии отличительных имен, соответствующие локальному пространству имен каждой PKI. Это позволяет субъекту одной PKI не принимать сертификаты другой PKI, которые содержат локальные имена.

В соответствии с требованиями конкретной локальной среды в сертификате могут указываться и другие дополнения, они должны быть помечены как некритичные.

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

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

Самоподписанные сертификаты являются сертификатами только в том смысле, что имеют формат сертификата стандарта X.509. Подпись на самоподписанном сертификате подтверждает только то, что у издателя есть открытый и секретный ключи, и ничего более - ничего имеющего отношение к содержанию сертификата. Пользователь может доверять самоподписанному сертификату только тогда, когда получил его защищенным способом, гарантирующим подлинность источника - данного УЦ.

Самоподписанные сертификаты должны иметь формат X.509 v1 и не содержать дополнений, поскольку в этом нет необходимости. В такие сертификаты пока не включается информация о политиках применения сертификатов, особенно в сертификаты головного УЦ иерархической PKI. Так как изменения в наборе политик отражаются на валидности пути сертификации, можно ожидать, что в будущем самоподписанные сертификаты будут иметь формат X.509 v3 и устанавливать пункты доверия с учетом политик применения сертификатов.

Чтобы ввести в действие новый сертификат или ключ подписи САС, УЦ выпускает пару сертификатов обновления ключа. Первый сертификат содержит старый открытый ключ и подписывается новым секретным ключом. Второй сертификат содержит новый открытый ключ и подписывается старым секретным ключом. Таким образом, пользователи сертификатов, подписанных старым секретным ключом, и пользователи сертификатов, подписанных новым секретным ключом, могут проверять валидность сертификатов друг друга. В обоих сертификатах обновления имена издателя и субъекта совпадают, оба сертификата принадлежат УЦ одной и той же корпоративной PKI. Таблица 7.1 иллюстрирует некоторые отличия профилей этих сертификатов от нормального профиля сертификата УЦ [128].

Старый сертификат УЦ, подписанный новым ключом, позволяет пользователям сертификатов, подписанных новым секретным ключом, строить валидный путь сертификации к сертификатам, подписанным старым секретным ключом.

Новый сертификат УЦ, подписанный старым ключом, дает возможность пользователям сертификатов, подписанных старым секретным ключом, строить валидный путь сертификации к сертификатам, подписанным новым секретным ключом.

УЦ выпускает сертификаты обновления политики, чтобы изменить домен политики. Предположим, что УЦ выпускает сертификаты в соответствии с политиками I и II. В связи с изменениями внутри организации планируется выпускать новые сертификаты в соответствии с политиками III, IV и V. При переходе к новым политикам УЦ желает гарантировать непрерывность работы своих пользователей. Даже если бы УЦ мог моментально выпустить новые сертификаты для всех пользователей, в том числе и внешних, то пользователям пришлось бы заняться переконфигурированием своих приложений, что помешало бы их работе. Поэтому при изменении политик выпускается пара сертификатов обновления политики. В данном примере первый сертификат задает политики I и II, устанавливая их соответствие политикам III, IV и V, а второй сертификат задает политики III, IV и V, устанавливая их соответствие политикам I и II.