Профили сертификата и списка отмененных сертификатов
Введение в Х.509v3
Рассмотрим форматы сертификата Х.509 v3 и списка отмененных сертификатов (Certificate Revocation List – CRL) Х.509 v2. Рассмотрим стандартные расширения сертификата и CRL и определим расширения, специфичные для Internet. Рассмотрим алгоритм проверки действительности сертификационного пути.
В некоторых случаях можно дополнять или заменять данный профиль, чтобы обеспечить соответствие требованиям конкретных прикладных областей или окружений.
Пользователь сертификата должен просмотреть политику сертификата, созданную СА, прежде чем использовать сертификат.
Сертификат Х.509 версии 3
Пользователям открытого ключа требуются гарантии, что соответствующий закрытый ключ знает конкретный субъект, который указан владельцем данного открытого ключа. Это будет означать, что только названный субъект может использовать данный закрытый ключ для дешифрования или создания цифровой подписи. Такая гарантия достигается посредством использования сертификатов открытого ключа, которые являются структурами данных, связывающие значения открытого ключа с субъектами. Связывание осуществляется доверенным СА, который подписывает сертификат. При этом СА должен гарантировать, что субъект имеет соответствующий закрытый ключ (например, использовать доказательство обладания закрытым ключом с помощью протокола запрос-ответ), либо непосредственно предоставить закрытый ключ (вместе с сертификатом) субъекту.
Сертификат всегда имеет ограниченный срок действительности. В первую очередь это связано с тем, что любой криптографический алгоритм подвержен атакам с помощью простого перебора всего пространства ключей. Время действительности указывается в самом сертификате. Так как подпись сертификата и его своевременность могут быть независимо проверены клиентом, использующим сертификат, сертификаты могут распределяться по открытым коммуникациям и серверным системам, и могут быть кэшированы в небезопасной памяти системы, использующей сертификаты.
Расширения сертификата могут содержать такие данные как информация о дополнительной идентификации субъекта, информация об атрибутах ключа, информация о политике и ограничения на сертификационный путь.
Сертификационные пути и доверие
Пользователь сервиса безопасности является проверяющей стороной, которой требуется знание открытого ключа некоторого субъекта. В этом случае проверяющей стороне необходимо получить сертификат, содержащий требуемый открытый ключ и проверить его действительность. Если проверяющая сторона в настоящий момент не имеет заверенной копии открытого ключа СА, который подписал сертификат, не знает имени СА и, быть может, некоторой дополнительной информации, то ей требуется дополнительный сертификат для получения открытого ключа данного СА. В общем случае может потребоваться цепочка из нескольких сертификатов, содержащая сертификат открытого ключа конечного участника, подписанный одним СА, и ноль или более дополнительных сертификатов САs, подписанных другими САs. Такая цепочка, называемая сертификационным путем, необходима, потому что проверяющая сторона изначально обладает ограниченным количеством открытых ключей САs, полученных надежным способом.
Существуют различные способы, с помощью которых САs могут быть сконфигурированы для того, чтобы проверяющая сторона могла построить сертификационные пути. Первоначально планировалась жесткая иерархическая структура САs. При этом предполагалось существование трех типов уполномоченных органов сертификации:

1. Регистрационный уполномоченный орган политики Internet (IPRA): данный уполномоченный орган, функционирующий под руководством Internet-сообщества, действует в качестве корневого органа в сертификационной иерархии. Он выпускает сертификаты только для уполномоченных органов следующего уровня, PCAs. Все сертификационные пути начинаются с IPRA.
2. Уполномоченные органы сертификатов политики (PCAs): PCAs являются вторым уровнем иерархии, каждый PCAs сертифицирован IPRA. РСА должны установить и опубликовать утверждение о своей политике в отношении сертифицируемых пользователей или подчиненных уполномоченных органов сертификации. Различные PCAs могут удовлетворять те или иные потребности пользователей. Например, один РСА может выпускать сертификаты для электронной почты, другой РСА может иметь политику, которая удовлетворяет более строгим законодательным требованиям в отношении цифровых подписей.
3. Уполномоченные органы сертификации (САs): САs являются третьим уровнем иерархии, но могут иметь и более низкий уровень. Те, что находятся на третьем уровне, сертифицируются PCAs. САs представляют, например, отдельные организации, отдельные единицы организации (департаменты, отделы, лаборатории) или отдельные географические единицы.

RFC 1422 определяет правило подчинения имен, которое требует, чтобы СА мог выпускать сертификаты только тем пользователям, чьи имена являются подчиненными (в дереве именования Х.500) по отношению к имени самого СА. Доверие, связанное с сертификационным путем, определяется именем РСА. Правило подчинения имен гарантирует, что САs, подчиняющиеся конкретному РСА, ограничены множеством участников, которых они могут сертифицировать (т.е. СА организации может сертифицировать только сотрудников данной организации). Системы сертификации пользователей должны иметь возможность автоматически проверять, выполняется ли правило подчинения имен.
RFC 1422 использует форматы сертификатов Х.509 v1. Ограничения Х.509 v1 требуют нескольких структурных ограничений на четкое связывание информации о политике или ограничения на использование сертификатов. Эти ограничения включают:

• Строгую иерархию сверху вниз, все сертификационные пути начинаются от IPRA.
• Правило подчинения имен ограничивает имена субъектов CAs.
• Использование понятия РСА, которое требует знания индивидуальных PCAs, что встроено в логику проверки цепочки сертификатов. Знание индивидуальных PCAs требуется при определении возможности принятия цепочки сертификатов.

В Х.509 v3 большинство ограничений, определенных в RFC 1422, может быть указано в расширениях сертификата без необходимости иметь строгую иерархическую структуру САs. В частности, расширения сертификата, касающиеся политик, устраняют необходимость применения правила подчинения имен. Как результат, третья версия может поддерживать более гибкую архитектуру:

• сертификационные пути начинаются с открытого ключа СА в собственном домене пользователя или с открытого ключа верхнего уровня иерархии. Начало сертификационного пути с открытого ключа СА в собственном домене пользователя имеет определенные преимущества. В некоторых окружениях больше доверяет локальному домену.
• Ограничения имени могут определяться с помощью явного включения в сертификат расширения ограничения имени, но это не обязательно.
• Расширения политики и отображения политики заменяют понятие РСА, что допускает большую степень автоматизации. Приложение может определить, является ли сертификационный путь действительным, на основании содержимого сертификатов вместо априорного знания открытых ключей PCAs. Это позволяет лучше автоматизировать обработку сертификационного пути.

Отмена сертификата
Когда сертификат выпущен, считается, что он будет использоваться в течение всего своего периода действительности. Однако могут произойти события, в результате которых сертификат станет недействительным до завершения своего периода действительности, указанного в сертификате. К таким событиям относится изменение имени, изменение связывания между субъектом и СА (например, сотрудник увольняется из организации) и компрометация или предположение компрометации соответствующего закрытого ключа. При таких обстоятельствах СА должен отменить сертификат.
Х.509 определяет один метод отмены сертификата. Данный метод предполагает, что каждый СА периодически выпускает подписанную структуру данных, называемую списком отмененных сертификатом (CRL). CRL является помеченным временем списком, который подписан СА или специальным выпускающим CRL и в котором перечислены отмененные сертификаты. Данный список становится свободно доступен в открытом репозитории. Каждый отмененный сертификат идентифицируется в CRL своим серийным номером. Когда использующая сертификат система получает сертификат (например, для проверки цифровой подписи удаленного пользователя), эта система не только проверяет подпись сертификата и действительность, но также получает свежий CRL и проверяет, не находится ли в этом CRL серийный номер сертификата. Понятие «свежий» может зависеть от локальной политики, но обычно означает самый последний выпущенный CRL. Новый CRL выпускается регулярно (например, каждый час, день или неделю). При получении уведомления об отмене запись добавляется в CRL.
Преимущество данного метода отмены состоит в том, что CRLs могут распространяться теми же способами, что и сами сертификаты, а именно через небезопасные серверы и коммуникации.
При этом недостатком данного метода отмены CRL является то, что точность отмены ограничена периодом выпуска CRL. Например, если об отмене сообщено в текущий момент, то об отмене не будут надежно оповещены использующие сертификат системы до тех пор, пока не будет выпущен новый CRL – это может занять час, день или неделю, в зависимости от частоты создания CRLs.
Как и формат сертификата Х.509 v3, для того, чтобы обеспечить интероперабельность реализаций различных производителей, необходимо иметь строгий формат Х.509 CRL v2. Существуют также специальные протоколы и соответствующие им форматы сообщений, поддерживающих on-line оповещения об отмене. On-line методы оповещения об отмене могут применяться в некоторых окружениях как альтернатива CRL. On-line проверка отмены может существенно уменьшить промежуток между отправкой сообщения об отмене и получением этой информации проверяющей стороной. После того как СА принимает и аутентифицирует сообщение от субъекта сетификата или от RA о необходимости отмены данного сертификата, любой запрос к on-line сервису будет корректно отображать действительность сертификата. Однако эти методы навязывают новые требования безопасности: проверяющая сторона должна доверять on-line сервису действительности, в то время как репозиторий не обязательно должен быть доверяемым.

Профиль сертификата и расширений сертификата
Основные поля сертификата
Сертификат Х.509 v3 определяется следующим образом. Для вычисления подписи данные, которые должны быть подписаны, представляются с использованием ASN.1 однозначных правил представления (DER).
Certificate  ::=  SEQUENCE  {
tbsCertificate     TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue     BIT STRING 
}
TBSCertificate  ::= SEQUENCE  {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT
UniqueIdentifier OPTIONAL,
-- если присутствует, версия должна
-- быть v2 или v3
subjectUniqueID [2] IMPLICIT
UniqueIdentifier OPTIONAL,
-- если присутствует, версия должна быть
-- v2 или v3
extensions [3] EXPLICIT Extensions OPTIONAL
-- если присутствует, версия должна быть v3     
}
Version ::= INTEGER { v1(0), v2(1), v3(2) }
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE {
notBefore Time,
notAfter  Time
}
Time ::= CHOICE {
utcTime     UTCTime,
generalTime GeneralizedTime
}
UniqueIdentifier ::= BIT STRING
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm        AlgorithmIdentifier,
subjectPublicKey BIT STRING 
}
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
Extension ::= SEQUENCE  {
extnID    OBJECT IDENTIFIER,
critical  BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING 
}
Поля сертификата
Сертификат есть последовательность трех обязательных полей: tbsCertificate, signatureAlgorithm и signatureValue.
tbsCertificate
Поле содержит имена субъекта и выпускающего, открытый ключ, связанный с субъектом, период действительности и другую связанную с этим сертификатом информацию. Поля подробно описаны далее; tbsCertificate обычно включают расширения, которые тоже будут описаны ниже.
signatureAlgorithm
Поле signatureAlgorithm содержит идентификатор криптографического алгоритма, используемого СА для подписывания данного сертификата. Существуют стандартные алгоритмы, которые должны поддерживаться всеми реализациями, но конкретная реализация может поддерживать и другие алгоритмы.
Идентификатор алгоритма определяется следующей ASN.1-структурой:
AlgorithmIdentifier ::= SEQUENCE  {
algorithm  OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL
}
Идентификатор алгоритма используется для определения криптографического алгоритма. Компонент OBJECT IDENTIFIER идентифицирует алгоритм (такой как DSA с SHA-1). Компоненты поля параметров изменяются в соответствии с указанным алгоритмом.
Поле должно содержать тот же самый идентификатор алгоритма, что и поле подписи в tbsCertificate.
signatureValue
Поле signatureValue содержит цифровую подпись, вычисленную для поля tbsCertificate, записанном в DER-представлении ASN.1. Это означает, что поле tbsCertificate, представленное как ASN.1 DER, используется в качестве входа в функцию подписи. Полученное значение подписи представлено как BIT STRING и включено в поле подписи. Детали данного процесса могут отличаться для каждого конкретного алгоритма подписи.
Созданием данной подписи СА подтверждает действительность информации в поле tbsCertificate. В частности, СА подтверждает связь между материалом открытого ключа и субъектом сертификата.

TBSCertificate
Последовательность TBSCertificate содержит информацию, связанную с субъектом сертификата и СА, который выпустил сертификат. Каждый TBSCertificate содержит имена субъекта и выпускающего, открытый ключ, связанный с субъектом, период действительности, номер версии и серийный номер сертификата; некоторые поля могут (но это не обязательно) содержать уникальный идентификатор. Рассмотрим синтаксис и семантику таких полей. TBSCertificate обычно включает расширения. Рассмотрим также наиболее часто используемые в Internet расширения.
Version
Данное поле описывает версию представления сертификата. Если используются расширения, то версия должна быть 3 (значение – 2). Если расширения не указаны, но UniqueIdentifier представлен, версия может быть 2 (значение – 1); но версия может быть и 3. Если представлены только базовые поля, версия может быть 1 (значение в сертификате опущено как значение по умолчанию); но версия может быть 2 или 3.
Реализации должны быть готовы принимать любую версию сертификата. Как минимум конформные реализации должны распознавать версию 3 сертификатов.
Serial number
Серийный номер должен быть положительным целым, назначаемым СА для каждого сертификата. Он должен быть уникальным для каждого сертификата, выпущенного данным СА. Таким образом, имя выпустившего и серийный номер однозначно определяют сертификат. САs должны обеспечивать, чтобы серийные номера были неотрицательными целыми. Считается, что серийные номера могут иметь длину до 20 октетов.
Signature
Данное поле содержит идентификатор алгоритма, используемого СА для подписывания сертификата.
Данное поле должно содержать тот же самый идентификатор алгоритма, что и поле signatureAlgorithm в Certificate. Содержание необязательного поля параметров зависит от конкретного алгоритма.
Issuer
Поле issuer идентифицирует того, кто подписал и выпустил сертификат. Поле issuer должно содержать непустое уникальное имя (DN). Имя определяется в соответствии со следующей ASN.1 структурой:
Name ::= CHOICE { RDNSequence }
RDNSequence ::= SEQUENCE OF
RelativeDistinguishedName
RelativeDistinguishedName ::=
SET OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type   AttributeType,
value  AttributeValue
}
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY DEFINED BY
AttributeType
Имя описывает иерархическое имя, состоящее из атрибутов, таких, например, как название страны, и соответствующих значений, таких как RU. Тип компонента AttributeValue определяется значением AttributeType.
Стандарт Х.509 не ограничивает набор типов атрибутов, которые могут появиться в имени. Тем не менее, стандартом рекомендуется поддерживать следующие типы атрибутов в именах выпускающего и субъекта:

• Страна
• Организация
• Организационная единица
• Обозначение уникального имени
• Название штата или региона
• Общепринятое имя (например, Иванов Иван)
• Серийный номер

Дополнительно могут присутствовать некоторые другие типы атрибутов в именах выпускающего и субъекта, например:

• Локализация
• Заголовок
• Отчество
• Назначенное имя
• Инициалы
• Псевдоним
• Специальное название (например, «Jr.», «3-ий» или «IV»).

Также может присутствовать атрибут domainComponent. DNS предоставляет собой иерархическую систему обозначения ресурсов. Данный атрибут предоставляет удобный механизм для организаций, которые хотят использовать уникальные DN имена параллельно со своими DNS-именами. Это не заменяет dNSName компонент альтернативного поля имени. Стандарт не требует конвертировать такие имена в DNS-имена.
Проверяющая сторона должна обрабатывать поля уникального имени выпускающего и уникального имени субъекта для получения цепочки имен при проверке действительности сертификационного пути. Цепочка имен получается в случае соответствия уникального имени выпускающего в первом сертификате имени субъекта в сертификате СА.
Действительность сертификата
Период действительности сертификата является интервалом времени, в течение которого СА гарантирует, что он поддерживает информацию о статусе сертификата. Поле представлено как SEQUENCE двух дат: дата, с которой начинается период действительности сертификата (notBefore), и дата, которой заканчивается период действительности сертификата (notAfter). Обе даты могут иметь представление как UTCTime, так и GeneralizedTime.
САs должны всегда указывать даты действительности сертификата до 2049 года как UTCTime; даты действительности сертификатов, начиная с 2050 года и далее, должны быть представлены как GeneralizedTime. Основная разница между представлениями времени в UTCTime и в GeneralizedTime заключается в том, что в UTCTime для значения года отводится две цифры, а в GeneralizedTime – четыре. В случае UTCTime, если год больше или равен 50, то он должен интерпретироваться как 19YY, а если год меньше 50, то он должен интерпретироваться как 20YY.
Период действительности сертификата является периодом времени от notBefore до notAfter включительно.
Subject
Поле subject идентифицирует участника, который является собственником сертификата и соответствующего закрытого ключа. Имя участника может быть указано в поле subject и/или в расширении subjectAltName. Если субъект является СА (т.е. основное обязательное расширение сА есть TRUE), то поле subject должно содержать непустое уникальное имя, соответствующее содержимому поля issuer во всех сертификатах, выпущенных данным СА. Если субъект является выпускающим CRL (т.е. присутствует расширение использования ключа keyUsage, и значение cRLSign есть TRUE), то поле субъекта должно содержать непустое уникальное имя, соответствующее содержимому поля issue во всех CRLs, выпущенных данным субъектом. Если информация именования субъекта представлена только расширением subjectAltName (т.е. ключ связан только с e-mail адресом или URI), то имя субъекта должно быть пустой последовательностью, и расширение subjectAltName должно быть обязательным.
Поле subject, если оно не пусто, должно содержать уникальное имя в форме DN. СА может выпустить более одного сертификата с одним и тем же DN для одного и того же участника, определенного в subject.
Поле subject определено как тип Name в терминологии стандарта Х.501.
Следует учитывать, что существуют наследуемые реализации сертификационных центров, в которых имя из RFC 822 встроено в уникальное имя субъекта как атрибут EmailAddress. Значение атрибута для EmailAddress является типом IA5String, благодаря чему допускается включение символа «@», который не входит в набор символов PrintableString. Значения атрибута EmailAddress нечувствительны к регистру (aaa@msu.ru – то же самое, что и AAA@MSU.RU ).
Новые реализации сертификационных центров при создании сертификатов с адресами электронной почты для указания данного атрибута должны использовать rfc822Name в альтернативном поле имени субъекта. Одновременное включение атрибута EmailAddress в уникальное имя субъекта для поддержки наследуемых реализаций не приветствуется, но допускается.
Информация открытого ключа субъекта
Данное поле используется для указания использования открытого ключа, в частности для идентификации алгоритма данного ключа (например, RSA, DSA или Diffie-Hellman). Алгоритм идентифицируется использованием AlgorithmIdentifier структуры. Идентификаторы объекта для поддерживаемых алгоритмов и методы представления материала открытого ключа (т.е. открытый ключ и параметры) определяются IANA.
Уникальные идентификаторы
Данные поля должны присутствовать только в том случае, если версия сертификата есть 2 или 3. Эти поля не должны присутствовать, если версия равна 1. Уникальные идентификаторы субъекта и выпускающего представлены в сертификате для получения возможности повторного использования имен субъекта и/или выпускающего в более позднее время. САs не должны создавать сертификаты с одинаковыми идентификаторами.
Расширения
Данное поле должно появляться только в том случае, если версия равна 3. Если оно присутствует, данное поле есть последовательность одного или более расширений сертификатов.

Расширения сертификата

Расширения, определенные для сертификатов Х.509 v3, предоставляют методы для связывания дополнительных атрибутов с пользователями или открытыми ключами и для управления сертификатами. Формат сертификата Х.509 v3 также допускает определение частных расширений.
Каждое расширение в сертификате может быть либо критичным, либо некритичным. Система, использующая сертификаты, должна отвергать сертификат, если она встретила критичное расширение, которое не в состоянии распознать; однако некритичные расширения могут игнорироваться, если они не распознаются. Рассмотрим рекомендуемые в Internet расширения сертификатов. Могут использоваться дополнительные расширения; однако следует осторожно устанавливать любые критические расширения в сертификаты, так как это может препятствовать проверке действительности сертификатов.
Каждое расширение должно иметь соответствующий OID и определяться ASN.1-структурой. Когда расширение появляется в сертификате, OID появляется как поле extnID, и соответствующая ASN.1 структура представления является значением строки октетов extnValue. Сертификат не должен включать более одного экземпляра конкретного расширения. Например, сертификат может содержать только одно расширение для идентификатора ключа уполномоченного органа. Расширение включает булево значение критичности со значением по умолчанию, равным FALSE. Для каждого расширения должны быть определены допустимые значения для поля критичности.
САs должны поддерживать расширения для идентификатора ключа, основных ограничений использования ключа и политик сертификатов. Если СА выпустил сертификаты с пустой последовательностью для поля субъекта, СА должен указать расширение альтернативного имени субъекта. Поддержка оставшихся расширений необязательна. САs могут поддерживать расширения, которые текущим стандартом не определены; при этом сертификационные центры должны учитывать, что расширения, помеченные как критичные, могут препятствовать интероперабельности.
Как минимум должны распознаваться следующие расширения: использование ключа, политики сертификата, альтернативное имя субъекта, базовые ограничения, ограничения имени, расширенное использование ключа и запрет произвольной политики.
Могут также распознаваться расширения идентификаторов ключа сертификационного центра и субъекта и расширение отображения политики.

Стандартные расширения

Рассмотрим стандартные расширения сертификата, определенные в стандарте X.509. Каждое расширение имеет определенный OID. Эти OIDs являются элементами id-ce множества, которое определено следующим образом:

id-ce OBJECT IDENTIFIER ::=

    { joint-iso-ccitt(2) ds(5) 29 }

Идентификатор ключа сертификационного центра

Расширение для идентификатора ключа сертификационного центра предоставляет способ идентификации открытого ключа, соответствующего закрытому ключу, который использовался для подписывания сертификата. Данное расширение используется, когда выпускающий имеет несколько ключей для подписывания. Идентификация может быть основана либо на идентификаторе ключа (идентификатор ключа субъекта в сертификате выпускающего), либо на имени выпускающего и серийном номере.
Поле keyIdentifier расширения authorityKeyIdentifier должно быть включено во все сертификаты, выпущенные СА для обеспечения возможности создания сертификационного пути. Существует одно исключение: когда СА распространяет свой открытый кюч в форме самоподписанного сертификата, идентификатор ключа уполномоченного органа может быть опущен. Подпись для самоподписанного сертификата создается закрытым ключом, соответствующим открытому ключу субъекта. Это доказывает, что выпускающий обладает как открытым ключом, так и закрытым. В таком случае идентификаторы субъекта и уполномоченного органа должны быть одинаковыми, и идентификатор ключа может быть указан только для открытого ключа субъекта.
Значение поля keyIdentifier должно быть получено из открытого ключа, используемого для проверки подписи сертификата, или методом, который создает уникальные значения. Рассмотрим два метода создания идентификаторов ключей из открытого ключа и один метод создания уникальных значений для keyIdentifier. Если идентификатор ключа не был предварительно определен, рекомендуется использовать один из этих методов для создания keyIdentifiers. Если идентификатор ключа был предварительно определен, СА должен задействовать предварительно определенный идентификатор.
Рекомендуется поддерживать метод идентификации ключа всем пользователям сертификатов.
Данное расширение не должно помечаться как критичное.

id-ce-authorityKeyIdentifier OBJECT 

    IDENTIFIER ::= { id-ce 35 }

AuthorityKeyIdentifier ::= SEQUENCE {

  keyIdentifier [0] KeyIdentifier OPTIONAL,

  authorityCertIssuer [1] GeneralNames

      OPTIONAL,

  authorityCertSerialNumber [2] 

      CertificateSerialNumber OPTIONAL

}

KeyIdentifier ::= OCTET STRING

Идентификатор ключа субъекта

Расширение идентификатора ключа субъекта предоставляет способ идентификации сертификата, содержащего конкретный открытый ключ.
Для упрощения создания сертификационного пути данное расширение должно появляться во всех сертификатах СА, т.е. во всех сертификатах, в которых значение сА есть TRUE. Значение идентификатора ключа субъекта должно быть значением, указанным в поле идентификатора ключа сертификационного центра, который выпустил сертификат для данного субъекта.
Для сертификатов СА идентификаторы ключа субъекта должны быть получены из открытого ключа или методом, который создает уникальные значения. Существует два метода для создания идентификаторов ключей из открытого ключа:

1. keyIdentifier получается из 160-битного хэша SHA-1 значения битовой строки subjectPublicKey (исключая тег, длину и неиспользуемые биты).
2. keyIdentifier получается из четырех битов поля типа со значением 0100, следующим за младшими 60 битами хэша SHA-1 значения битовой строки subjectPublicKey (исключая тег, длину и неиспользуемые биты).

Метод создания уникальных значений состоит в использовании монотонно возрастающей последовательности целых чисел.
Для сертификатов конечных участников расширение идентификатора ключа субъекта предоставляет способы для идентификации сертификатов, содержащих конкретный открытый ключ, используемый в приложении. Если конечный участник получает несколько сертификатов, возможно от нескольких САs, идентификатор ключа субъекта обеспечивает способы быстрого поиска конкретного открытого ключа, содержащегося в некотором множестве сертификатов. Для того чтобы помочь приложениям идентифицировать соответствующий сертификат конечного участника, данное расширение должно быть включено во все сертификаты конечного участника.
Данное расширение не должно быть помечено как критичное.

id-ce-subjectKeyIdentifier OBJECT 

    IDENTIFIER ::=  { id-ce 14 }

SubjectKeyIdentifier ::= KeyIdentifier

Использование ключа

Расширение keyUsage определяет назначение (например, шифрование, подпись, подписывание сертификатов) ключа, содержащегося в сертификате. Ограничение использования должно применяться, когда ключ ограничивается использованием только в одной операции. Например, когда ключ RSA должен использоваться только для проверки подписей для объектов, отличных от сертификатов открытого ключа и CRLs, биты digitalSignature и/или nonRepudiation должны присутствовать. Также когда ключ RSA должен использоваться только для транспортировки ключа, бит keyEncipherment должен присутствовать.
Данное расширение должно присутствовать в сертификатах, которые содержат открытые ключи, используемые для проверки действительности цифровых подписей над другими сертификатами открытых ключей или CRLs. Когда данное расширение присутствует, оно должно помечаться как критичное.

id-ce-keyUsage OBJECT IDENTIFIER ::=

     { id-ce 15 }

keyUsage ::= BIT STRING {

    digitalSignature (0),

    nonRepudiation   (1),

    keyEncipherment  (2),

    dataEncipherment (3),

    keyAgreement (4),

    keyCertSign  (5),

    cRLSign      (6),

    encipherOnly (7),

    decipherOnly (8) 

}

Биты в keyUsage типе используются следующим образом:
Бит digitalSignature установлен, когда окрытый ключ субъекта используется с механизмом цифровой подписи для поддержки сервисов безопасности, отличных от подписывания сертификата (бит 5) или подписывания CRL (бит 6). Например, если механизмы цифровых подписей используются для аутентификации участника или аутентификации и целостности исходных данных.
Бит nonRepudiation установлен, когда открытый ключ субъекта используется для проверки цифровых подписей в сервисе невозможности отказа, который защищает от того, что подписавший участник может отказаться от совершенного действия. Это включает подписывание сертификата или CRL. В случае последующего конфликта третья доверенная сторона может определить аутентичность подписанных данных.
Более тонкое различие между битами digitalSignature и nonRepudiation может определяться конкретными политиками сертификации.
Бит keyEncipherment установлен, когда открытый ключ субъекта используется для пересылки ключа. Например, когда ключ RSA применяется для шифрования ключа сессии, этот бит должен быть установлен.
Бит dataEncipherment установлен, когда открытый ключ субъекта используется для шифрования пользовательских данных, отличных от криптографических ключей.
Бит keyAgreement установлен, когда открытый ключ субъекта используется для согласования ключа. Например, когда ключ Диффи-Хеллмана используется для управления ключом, этот бит установлен.
Бит keyCertSign установлен, когда открытый ключ субъекта используется для проверки подписи в сертификатах открытого ключа. Если бит keyCertSign установлен, то бит сА в расширении базовых ограничений также должен быть установлен.
Бит cRLSign установлен, когда открытый ключ субъекта используется для проверки подписи в списке отмененных сертификатов.
Значение бита encipherOnly при отсутствии бита keyAgreement не определено. Когда установлены биты encipherOnly и keyAgreement, открытый ключ субъекта может использоваться только для шифрования данных при выполнении согласования ключа.
Значение бита decipherOnly не определено при отсутствии бита keyAgreement. Когда бит decipherOnly установлен, и бит keyAgreement также установлен, открытый ключ субъекта может использоваться только для дешифрования данных при выполнении согласования ключа.
Стандарт Х.509 не ограничивает комбинации битов, которые могут быть установлены в конкретном расширении keyUsage. Тем не менее соответствующие значения расширений keyUsage для конкретных алгоритмов строго определены (исходя из возможностей самого алгоритма).

Период использования закрытого ключа

Данное расширение не предполагается использовать в PKI Internet. Оно скорее предназначено для использования в системах электронного документооборота, когда требуется иметь возможность проверять подписи хранимых документов, но не подписывать новые документы закрытым ключом, срок действительности которого истекает в ближайшее время.
Увеличение периода использования закрытого ключа позволяет выпускающему сертификат указать период действительности закрытого ключа, отличный от периода действительности сертификата. Данное расширение предназначено для использования с ключами цифровых подписей. Расширение состоит из двух необязательных компонентов, notBefore и notAfter. Закрытый ключ, связанный с сертификатом, не должен использоваться для подписывания объектов до и после времени, указанного соответственно этими двумя компонентами. САs не должны создавать сертификаты с расширениями периода использования закрытого ключа, если, по крайней мере, один из компонентов не присутствует; расширение является некритичным.
Если расширение используется, notBefore и notAfter представлены как GeneralizedTime.

id-ce-privateKeyUsagePeriod OBJECT 

    IDENTIFIER ::=  { id-ce 16 }

PrivateKeyUsagePeriod ::= SEQUENCE {

    notBefore [0] GeneralizedTime OPTIONAL,

    notAfter  [1] GeneralizedTime OPTIONAL 

}

Политики сертификата

Расширение политик сертификата certificatePolicies содержит последовательность из одного или более идентификаторов политики, каждый из которых может иметь квалификатор. Эти квалификаторы не должны изменять определение политики.
В сертификате конечного участника данное расширение определяет политику, при которой был выпущен сертификат, и цели, для которых он может использоваться. В сертификате СА данное расширение ограничивает множество политик, которые могут присутствовать в сертификатах из сертификационного пути, включающего данный сертификат. Когда СА не хочет ограничивать множество политик для сертификатов из сертификационного пути, который включает данный сертификат, СА может указать специальную политику anyPolicy.
Считается, что приложения, допускающие только определенные политики, имеют список тех политик, которые они принимают, и сравнивают OIDs политик в сертификате с этим списком. Если данное расширение критичное, ПО проверки действительности пути должно иметь возможность интерпретировать его (включая необязательный квалификатор) или ему придется отвергать сертификат.
Для обеспечения интероперабельности рекомендуется, чтобы элементы политики состояли только из OID. Когда одного OID недостаточно, использование квалификаторов рекомендуется ограничивать теми, которые указаны ниже.
В настоящий момент определено два типа квалификаторов политики: CPS Pointer и User Notice.
Квалификатор CPS Pointer содержит указатель на Certification Practice Statement (CPS) – регламент сертификационной практики, опубликованный СА. Указатель должен быть представлен в виде URI.
Считается, что квалификатор User Notice будет показан соотвествующему участнику при использовании сертификата. Данный квалификатор имеет два необязательных поля: поле noticeRef и поле explicitText.
Поле noticeRef обозначает организацию и определяет конкретное текстовое определение, представленное данной организацией. Например, оно может идентифицировать организацию MSUCert и номер уведомления 1. В типичной реализации ПО приложения имеет файл уведомлений, содержащий текущее множество уведомлений для MSUCert; приложение извлекает текст уведомления из файла и показывает его. Сообщения могут быть многоязыковыми, что позволяет ПО выбирать сообщения конкретного языка в соответствии с окружением.
Поле explicitText включает текст непосредственно в сертификат. Оно является строкой максимального размера 200 символов.
Обе опции notifyRef и explicitText включаются в один квалификатор, и если ПО приложения может разместить текст уведомления, указанный опцией noticeRef, то этот текст должен быть показан; в противном случае должна быть показана строка explicitText.

id-ce-certificatePolicies OBJECT 

    IDENTIFIER ::=  { id-ce 32 }

anyPolicy OBJECT IDENTIFIER ::= {

    id-ce-certificate-policies 0 }

certificatePolicies ::= SEQUENCE SIZE (

    1..MAX) OF PolicyInformation

PolicyInformation ::= SEQUENCE {

  policyIdentifier CertPolicyId,

  policyQualifiers SEQUENCE SIZE (1..MAX) OF

      PolicyQualifierInfo OPTIONAL 

}

CertPolicyId ::= OBJECT IDENTIFIER

PolicyQualifierInfo ::= SEQUENCE {

  policyQualifierId  PolicyQualifierId,

  qualifier ANY DEFINED BY policyQualifierId

}

    -- policyQualifierIds для квалификаторов

   -- политики в Internet

  id-qt         OBJECT IDENTIFIER ::= { 

      id-pkix 2 }

  id-qt-cps     OBJECT IDENTIFIER ::= { 

      id-qt 1 }

  id-qt-unotice OBJECT IDENTIFIER ::= { 

      id-qt 2 }

PolicyQualifierId ::= OBJECT IDENTIFIER (

     id-qt-cps | id-qt-unotice )

Qualifier ::= CHOICE {

  cPSuri     CPSuri,

  userNotice UserNotice }

CPSuri ::= IA5String

UserNotice ::= SEQUENCE {

  noticeRef    NoticeReference OPTIONAL,

  explicitText DisplayText OPTIONAL

}

NoticeReference ::= SEQUENCE {

  organization  DisplayText,

  noticeNumbers SEQUENCE OF INTEGER 

}

DisplayText ::= CHOICE {

  ia5String     IA5String     (SIZE (1..200)),

  visibleString VisibleString (SIZE (1..200)),

  bmpString     BMPString     (SIZE (1..200)),

  utf8String    UTF8String    (SIZE (1..200)) 

}

Отображения политик

Данное расширение используется в сертификатах СА. Оно перечисляет одну или более пар OIDs; каждая пара включает issuerDomainPolicy и subjectDomainPolicy. Пара определяет, что выпустивший СА считает свою issuerDomainPolicy эквивалентной subjectDomainPolicy субъекта СА.
Отображение политик определяет список политик, связанных с субъектом СА, которые могут приниматься как эквивалентные issuerDomainPolicy.
Каждая issuerDomainPolicy, перечисленная в расширении отображения политик, должна также быть установлена в расширении политик сертификата в том же самом сертификате. Политики не должны отображаться в специльное значение anyPolicy.
Данное расширение может не поддерживаться САs и/или приложениями, и оно не должно быть критичным.

id-ce-policyMappings OBJECT IDENTIFIER ::= {

    id-ce 33 }

PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {

  issuerDomainPolicy  CertPolicyId,

  subjectDomainPolicy CertPolicyId

}

Альтернативное имя субъекта

Расширение альтернативных имен субъекта допускает дополнительные идентификации, связанные с субъектом сертификата. Данная опция включает e-mail адрес, DNS-имя, IP-адрес и URI. Существуют и другие формы имени, в том числе полностью локальные определения. Может быть включено несколько форм имени и несколько экземпляров для каждой из них. Если подобные идентификации необходимо ввести в сертификат, должно использоваться расширение, описывающее альтернативное имя субъекта (или альтернативное имя выпускающего); однако DNS-имя может быть представлено в поле субъекта посредством атрибута domainComponent.
Так как альтернативное имя субъекта надежно связывается с открытым ключом, считается, что все части альтернативного имени субъекта должны быть проверены СА.
Более того, если идентификация субъекта, включенная в сертификат, является только формой альтернативного имени (например, адрес электронной почты), то расширение subjectAltName должно быть помечено как критичное.
Когда расширение subjectAltName содержит электронный адрес, он должен иметь вид, определенный в RFC 822, т.е. иметь форму local-part@domain.
Когда расширение subjectAltName содержит iPAddress, адрес должен храниться в строке октетов в «сетевом порядке байтов», как определено в RFC 791. Для IP версии 4 строка октетов должна содержать строго четыре октета. Для IP версии 6 строка октетов должна содержать строго 16 октетов.
Когда расширение subjectAltName содержит метку доменного имени системы, доменное имя должно храниться в dNSName (IA5String). Имя должно иметь вид, определенный в RFC 1034. Заметим, что хотя буквы верхнего и нижнего регистров в доменном имени допустимы, регистр не имеет значения. Кроме того, хотя строка « » является допустимым доменным именем, расширения subjectAltName с dNSName в виде « » использоваться не должны. Наконец, использование DNS-представления для адресов e-mail (xxx.cmc.msu.ru вместо xxx@cmc.msu.ru) не допускается.
Замечание: в настоящее время ведется работа по представлению доменных имен в международном наборе символов. Такие имена не могут быть представлены в виде IA5String. После того как работа будет завершена, данный стандарт будет пересмотрен, и будут добавлены соответствующие функциональности.
Когда расширение subjectAltName содержит URI, имя должно храниться в uniformResourceIdentifier (как IA5String). Имя не должно быть относительным URL и должно следовать синтаксису URL и правилам представления, описанным в RFC 1738. Имя должно включать схему (например, HTTP или FTP) и конкретную часть этой схемы. Конкретная часть схемы должна включать полностью определенное доменное имя или IP-адрес хоста.
Как указано в RFC 1738, имя схемы нечувствительно к регистру (т.е. http эквивалентно HTTP). Часть хоста также нечувствительна к регистру, но остальные компоненты конкретной части схемы могут быть чувствительны к регистру.
Когда расширение subjectAltName содержит DN в directoryName, DN может не быть уникальным для субъекта, который сертифицируется СА, определяемым полем issuer name. СА может выпустить более одного сертификата с одним и тем же DN для некоторого субъекта.
subjectAltName может поддерживать дополнительные типы имен с помощью поля otherName. Формат и семантики имени определяются с помощью OBJECT IDENTIFIER. Само имя определяется как значение поля otherName. Например, имена формата Kerberos могут быть представлены в otherName с использованием OID-имени принципала Kerberos и последовательности Realm и PrincipalName.
Альтернативные имена субъектов могут создаваться тем же способом, что и уникальные имена субъектов, с помощью расширения ограничений имен, как было описано.
Если расширение subjectAltName присутствует, последовательность должна содержать, по крайней мере, одну запись. В отличие от поля субъекта, САs не должны выпускать сертификаты с subjectAltNames, содержащими пустые поля GeneralName. Например, rfc822Name представляется как IA5String. Хотя IA5String допускает пустую строку, такое rfc822Name использоваться не должно.

id-ce-subjectAltName OBJECT IDENTIFIER ::= {

    id-ce 17 }

SubjectAltName ::= GeneralNames

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF

    GeneralName

GeneralName ::= CHOICE {

  otherName     [0] OtherName,

  rfc822Name    [1] IA5String,

  dNSName       [2] IA5String,

  x400Address   [3] ORAddress,

  directoryName [4] Name,

  ediPartyName  [5] EDIPartyName,

  uniformResourceIdentifier [6] IA5String,

  iPAddress     [7] OCTET STRING,

  registeredID  [8] OBJECT IDENTIFIER

}

OtherName ::= SEQUENCE {

  type-id OBJECT IDENTIFIER,

  value [0] EXPLICIT ANY DEFINED BY type-id

}

EDIPartyName ::= SEQUENCE {

  nameAssigner [0] DirectoryString OPTIONAL

  partyName    [1] DirectoryString 

}

Альтернативные имена выпускающего

Данное расширение используется для связывания идентификации в стиле Internet с выпускающим сертификаты. Альтернативные имена выпускающего должны иметь такое же представление, как альтернативные имена субъекта.
Когда данное расширение присутствует, оно не должно быть помечено как критичное.

id-ce-issuerAltName OBJECT IDENTIFIER ::= {

    id-ce 18 }

IssuerAltName ::= GeneralNames

Атрибуты директории субъекта

Расширение атрибутов директории субъекта используется для представления идентификационных атрибутов субъекта (например, гражданство). Расширение определено как последовательность одного или более атрибутов. Данное расширение должно быть некритичным.

id-ce-subjectDirectoryAttributes OBJECT 

    IDENTIFIER ::= { id-ce 9 }

SubjectDirectoryAttributes ::= 

    SEQUENCE SIZE (1..MAX) OF Attribute

id-ce-basicConstraints OBJECT IDENTIFIER ::=

    { id-ce 19 }

BasicConstraints ::= SEQUENCE {

  cA  BOOLEAN DEFAULT FALSE,

  pathLenConstraint INTEGER (0..MAX) OPTIONAL

}

id-ce-nameConstraints OBJECT IDENTIFIER ::=

    { id-ce 30 }

NameConstraints ::= SEQUENCE {

  permittedSubtrees [0] GeneralSubtrees 

      OPTIONAL,

  excludedSubtrees  [1] GeneralSubtrees 

      OPTIONAL 

}

GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) 

    OF GeneralSubtree

GeneralSubtree ::= SEQUENCE {

  base        GeneralName,

  minimum [0] BaseDistance DEFAULT 0,

  maximum [1] BaseDistance OPTIONAL 

}

BaseDistance ::= INTEGER (0..MAX)

id-ce-policyConstraints OBJECT IDENTIFIER ::=

    { id-ce 36 }

PolicyConstraints ::= SEQUENCE {

  requireExplicitPolicy [0] SkipCerts 

      OPTIONAL,

  inhibitPolicyMapping  [1] SkipCerts 

      OPTIONAL 

}

SkipCerts ::= INTEGER (0..MAX)

Расширенное использование ключа

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

id-ce-extKeyUsage OBJECT IDENTIFIER ::= 

    { id-ce 37 }

ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX)

    OF KeyPurposeId

KeyPurposeId ::= OBJECT IDENTIFIER

Цели ключа могут быть при необходимости определены любой организацией.
Данное расширение может быть как критичным, так и некритичным.
Если расширение присутствует, то сертификат должен использоваться только для одной из указанных целей. Если указано несколько целей, то приложение не обязательно должно распознавать их все, а также расширенную цель, если она присутствует. Приложение, использующее сертификат, может потребовать указать конкретную цель, чтобы сертификат принимался данным приложением.
Если СА включает расширенные использования ключа, чтобы соответствовать таким приложениям, но не хочет ограничивать использование ключа, он может включить специальный keyPurposeID anyExtendedKeyUsage. Если keyPurposeID anyExtendedKeyUsage присутствует, расширение не должно быть критичным.
Если сертификат содержит как расширение использования ключа, так и расширение расширенного использования ключа, оба расширения должны обрабатываться независимо, и сертификат должен использоваться только для целей, содержащихся в обоих расширениях. Если нет целей, содержащихся в обоих расширенях, то сертификат не должен использоваться ни для какой цели (т.е. считается недействительным).
Определены следующие цели использования ключа:

anyExtendedKeyUsage OBJECT IDENTIFIER ::=

    { id-ce-extKeyUsage 0 }

id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }

id-kp-serverAuth OBJECT IDENTIFIER ::= 

    { id-kp 1 }

-- аутентификация сервера TLS  

-- биты использования ключа, которые могут

-- быть ограничением: digitalSignature,

-- keyEncipherment или keyAgreement

id-kp-clientAuth OBJECT IDENTIFIER ::= 

    { id-kp 2 }

-- аутентификация клиента TLS 

-- биты использования ключа, которые могут

-- быть ограничением: digitalSignature 

-- и/или keyAgreement

id-kp-codeSigning OBJECT IDENTIFIER ::= 

    { id-kp 3 }

-- подписывание загруженного выполняемого кода

-- биты использования ключа, которые могут 

-- быть ограничением: digitalSignature

id-kp-emailProtection OBJECT IDENTIFIER ::= 

    { id-kp 4 }

-- защита е-mail

-- биты использования ключа, которые могут 

-- быть ограничением: digitalSignature,

-- nonRepudiation, и/или (keyEncipherment 

-- или keyAgreement)

id-kp-timeStamping OBJECT IDENTIFIER ::= 

    { id-kp 8 }

-- связывание хэша объекта со временем 

-- биты использования ключа, которые могут 

-- быть ограничением: digitalSignature 

-- и/или nonRepudiation

id-kp-OCSPSigning OBJECT IDENTIFIER ::= 

    { id-kp 9 }

-- подписывание ответов OCSP

-- биты использования ключа, которые могут 

-- быть ограничением: digitalSignature 

-- и/или nonRepudiation

Точки распространения CRL

Расширение для точек распространения CRL определяет, как может быть получена информация CRL. Расширение должно быть некритичным, но рекомендуется, чтобы оно поддерживалось как САs, так и приложениями. Далее мы подробно рассмотрим управление CRL.
Расширение cRLDistributionPoints является последовательностью DistributionPoint. DistributionPoint состоит из трех полей, каждое из которых является необязательным: distributionPoint, reasons и cRLIssuer. Хотя каждое из этих полей является необязательным, DistributionPoint не должно состоять только из поля reasons; либо distributionPoint, либо cRLIssuer должно присутствовать. Если выпускающий сертификата не является выпускающим CRL, то поле cRLIssuer должно присутствовать и содержать имя выпускающего CRL. Если выпускающий сертификата является также и выпускающим CRL, то поле cRLIssuer должно быть опущено, и поле distributionPoint должно присутствовать. Если поле distributionPoint опущено, cRLIssuer должно присутствовать и включать имя, соответствующее записи Каталога Х.500 или LDAP, в которой размещен CRL.
Когда поле distributionPoint присутствует, оно содержит либо последовательность общих имен, либо единственное значение nameRelativeToCRLIssuer. Если расширение cRLDistributionPoints содержит общее имя типа URI, предполагается следующая семантика: URI является указателем на текущий CRL для соответствующих кодов причин и выпускается соответствующим cRLIssuer.
Если DistributionPointName содержит несколько значений, каждое имя описывает определенный механизм получения одного и того же CRL. Например, один и тот же CRL может быть доступен как по LDAP, так и по HTTP.
Если DistributionPointName содержит единственное значение nameRelativeToCRLIssuer, значение представляет собой фрагмент уникального имени. Фрагмент присоединяется к уникальному имени Х.500 выпускающего CRL для получения уникального указателя имени. Если поле cRLIssuer в DistributionPoint присутствует, то фрагмент имени присоединяется к уникальному имени выпускающего сертификат. DistributionPointName не должно использовать альтернативное nameRelativeToCRLIssuer, когда cRLIssuer содержит более одного уникального имени.
Если в DistributionPoint поле reasons опущено, CRL должен включать информацию об отмене для всех кодов причин.
Поле сRLIssuer определяет участника, который подписал и выпустил CRL. Если оно присутствует, cRLIssuer должно содержать, по крайней мере, одно уникальное имя (DN) X.500 и может включать другие формы имени. Так как cRLIssuer сравнивается с именем выпускающего CRL,

id-ce-cRLDistributionPoints OBJECT 

    IDENTIFIER ::= { id-ce 31 }

CRLDistributionPoints ::= 

  SEQUENCE SIZE (1..MAX) OF DistributionPoint

DistributionPoint ::= SEQUENCE {

  distributionPoint [0] DistributionPointName

      OPTIONAL,

  reasons   [1] ReasonFlags OPTIONAL,

  cRLIssuer [2] GeneralNames OPTIONAL 

}

DistributionPointName ::= CHOICE {

  fullName  [0]   GeneralNames,

  nameRelativeToCRLIssuer [1]   

      RelativeDistinguishedName 

}

ReasonFlags ::= BIT STRING {

  unused               (0),

  keyCompromise        (1),

  cACompromise         (2),

  affiliationChanged   (3),

  superseded           (4),

  cessationOfOperation (5),

  certificateHold      (6),

  privilegeWithdrawn   (7),

  aACompromise         (8) 

}

Предотвращение anyPolicy

Расширение предотвращения anyPolicy может быть использовано в сертификатах, выпущенных САs. Предотвращение any-policy указывает, что конкретный anyPolicy OID со значениями { 2 5 29 32 0 } не считается явно соответствующим остальным политикам сертификата. Значение определяет количество дополнительных сертификатов, которые могут появиться в пути до того как anyPolicy будет запрещена. Например, значение, равное единице, указывает, что anyPolicy может быть обработана в сертификатах, выпущенных субъектом данного сертификата, но не в дополнительных сертификатах в пути.
Данное расширение должно быть критическим.

id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::=

    { id-ce 54 }

InhibitAnyPolicy ::= SkipCerts

SkipCerts ::= INTEGER (0..MAX)

Самый свежий CRL (точка распространения Delta CRL)
Расширение с информацией о самом свежем CRL указывает, как должна быть получена информация о дельта CRL. Расширение должно быть некритичным.
Для данного расширения используется тот же синтаксис, что и для расширения cRLDistributionPoints, описанного выше. Для обоих расширений применяются одни и те же соглашения.

id-ce-freshestCRL OBJECT IDENTIFIER ::=

    { id-ce 46 }

FreshestCRL ::= CRLDistributionPoints

Частные расширения Internet

На сегодня определено два расширения для использования в PKI Internet. Эти расширения могут применяться для предоставления приложениям on-line информации о выпускающем СА или о субъекте. Так как информация может быть доступна в нескольких формах, каждое расширение является последовательностью IA5String значений, представляющих собой URI. URI неявно определяют размещение и формат информации, а также метод ее получения.

id-pkix  OBJECT IDENTIFIER ::=

  { iso(1) identified-organization(3) dod(6)

    internet(1) security(5) mechanisms(5)

   pkix(7) 

}

id-pe  OBJECT IDENTIFIER ::= { id-pkix 1 }

Доступ к информации уполномоченного органа

Расширение доступа к информации уполномоченного органа определяет, как получить доступ к информации и сервисам СА для сертификата, в котором расширение присутствует. Информация и сервисы могут включать on-line сервисы проверки действительности и данные политики СА. Расположение CRLs в данном расширении не указывается; эта информация предоставляется расширением cRLDistributionPoints. Данное расширение может включаться в сертификаты конечного участника или СА и не должно быть критичным.

id-pe-authorityInfoAccess OBJECT 

  IDENTIFIER ::= { id-pe 1 }

AuthorityInfoAccessSyntax  ::=

  SEQUENCE SIZE (1..MAX) OF AccessDescription

AccessDescription ::= SEQUENCE {

  accessMethod    OBJECT IDENTIFIER,

  accessLocation  GeneralName  

}

id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }

id-ad-caIssuers OBJECT IDENTIFIER ::= 

    { id-ad 2 }

id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

Каждая запись в последовательности AuthorityInfoAccessSyntax описывает формат и размещение дополнительной информации, предоставляемой СА, который выпустил сертификат с данным расширением. Тип и формат информации определяется полем accessMethod; в поле accessLocation указывается место размещения информации. Механизм получения может предполагаться accessMethod или указываться accessLocation.
В настоящий момент определено два accessMethod OIDs:

id-ad-caIssuers и id-ad-ocsp.

Когда accessMethod представляет собой id-ad-caIssuers, поле accessLocation определяет сервер и протокол доступа для получения указанного описания. Поле accessLocation определяется как GeneralName, которое может принимать несколько форм. Когда информация доступна через HTTP, FTP или LDAP, accessLocation должно быть uniformResourceIdentifier. Когда информация доступна через Протокол Доступа к Директории (DAP), accessLocation должно быть directoryName. Запись для этого directoryName содержит сертификаты СА в атрибуте crossCertificatePair. Когда информация доступна через e-mail, accessLocation должен быть rfc822Name.
id-ad-ocsp OID используется, когда информация отмены для сертификата, содержащего данное расширение, доступна с использованием Online Certificate Status Protocol (OCSP). В этом случае в поле accessLocation указывается размещение OCSP сервера.

Информационный доступ субъекта

Расширение информационного доступа субъекта указывает, как получить доступ к информации и сервисам для субъекта сертификата, в котором данное расширение присутствует. Когда субъект является СА, информация и сервисы могут включать сервисы действительности сертификата и данные политики СА. Когда субъект является конечным участником, информация описывает тип предоставляемых сервисов и как получить доступ к ним. В этом случае содержание данного расширения определяется в спецификациях протокола для поддерживаемых сервисов. Данное расширение может включаться в сертификаты СА или субъекта, и оно должно быть некритичным.

id-pe-subjectInfoAccess OBJECT IDENTIFIER ::=

    { id-pe 11 }

SubjectInfoAccessSyntax ::=

    SEQUENCE SIZE (1..MAX) OF 

       AccessDescription

AccessDescription ::= SEQUENCE {

    accessMethod    OBJECT IDENTIFIER,

    accessLocation  GeneralName  

}

Каждая запись в последовательности SubjectInfoAccessSyntax описывает формат и размещение дополнительной информации, предоставленной субъектом сертификата, в котором данное расширение появилось. Тип и формат информации определяется полем accessMethod; в поле accessLocation указывается место размещения информации.
В настоящий момент определен один метод доступа, который должен использоваться, когда субъект является СА, и один метод доступа, когда субъект является конечным участником.
id-ad-caRepository OID используется, когда субъект является СА и публикует свои сертификаты и CRLs (если выпускает) в репозотории. Поле accessLocation определено как GeneralName, которое может иметь несколько форм. Когда информация доступна через HTTP, FTP или LDAP, accessLocation должен быть uniformResourceIdentifier. Когда информация доступна через Протокол Доступа к Директории (DAP), accessLocation должен быть directoryName. Когда информация доступна по e-mail, accessLocation должен быть rfc822Name. Семантики остальных форм имени для accessLocation (когда accessLocation есть id-ad-caRepository) в настоящее время не определены.