Информационная технология. Взаимосвязь открытых систем ...

ГОСУДАРСТВЕННЫЙ СТАНДАРТ УЗБЕКИСТАНАO′z DSt 1108:2006Информационная технологияВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМСтруктура сертификата открытого ключа ЭЦПи сертификата атрибутаИздание официальноеУзбекское агентство стандартизации, метрологии и сертификацииТашкент

O′z DSt 1108:2006Предисловие1 ВНЕСЕН Центром научно – технических и маркетинговыхисследований (ЦНТМИ) Узбекского агентства связи и информатизации.2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ постановлением Узбекскогоагентства стандартизации, метрологии и сертификации (агентство«Узстандарт») от 31.05.2006 № 05-183 Настоящий стандарт является модифицированным по отношению кмеждународной рекомендации ITU-T X.509:2000 «Информационныетехнологии. Взаимодействие открытых систем. Структура сертификатаоткрытого ключа и сертификата атрибута» («Information Technologies. OpenSystem Interconnection. Public key and certificate attribute frameworks»).4. ВВЕДЕН ВПЕРВЫЕИнформация о введении в действие (прекращении действия) настоящегостандарта и изменений к нему на территории Узбекистана публикуется вуказателе, издаваемом агентством «Узстандарт».Исключительное право официального опубликования настоящегостандарта на территории Узбекистана принадлежит агентству «Узстандарт».II

O′z DSt 1108:2006Содержание1 Область применения ………………………………………………………………… 12 Нормативная ссылка…………………………………………………………………… 13 Термины, определения и сокращения ……………………………..………………….. 13.1 Термины и определения …………………………………………………………… 13.2 Сокращения …………………………………………………………..…………. 44 Общие положения ……………………………………………………………………… 55 Открытые ключи и сертификаты открытых ключей ……………………………… 65.1 Генерация пары ключей …………………………………………………………. 65.2 Создание сертификата открытого ключа ………………………………………. 65.3 Действительность сертификата ………………………………………………… 126 Расширение сертификата открытого ключа и расширение CRL …………………… 146.1 Обработка политики …………………………………………………………….. 146.2 Расширения информации о ключе и о политике………………………………… 186.3 Расширения информации о субъекте и издателе ……………………………… 236.4 Расширения ограничения пути сертификации……………………………….......... 266.5 Расширение базового CRL ………………………………………………………... 306.6 Расширения пункта распределения CRL и дельта-CRL ………………………. 377. Дельта CRL, имеющий связь с базой ………………………………………………… 428 Процедура обработки пути сертификации …………………………………………... 438.1 Входные данные обработки пути сертификации ……………………………….. 438.2 Выходные данные обработки пути сертификации ………………………….... 448.3 Переменные величины обработки пути сертификации …..……………………… 448.4 Этап инициализации ……………………………………………………………… 448.5 Обработка сертификата……………………………………………………………… 459. Схема директории PKI ..………………………………………………………………. 479.1 Классы объекта директории PKI и формы названия ……………………………. 479.2 Атрибуты директории PKI ………………………………………………………… 499.3 Правила соответствия директории PKI …………………………………………... 5210. Сертификаты атрибута ……………….……………………………………………... 5610.1 Структура сертификата атрибута…………………………………..……………. 5610.2 Пути сертификата атрибута ……………………………………………………….. 6011 Взаимоотношения органа по присвоению атрибутов, источника полномочий исертифицирующего органа ……………………………………………………… 6011.1 Привилегия в сертификатах атрибута ………………………………………….. 6011.2 Привилегия в сертификатах открытого ключа ………………………………… 6112. Модели PMI ………………………………………………………………………….. 6112.1. Общая модель …………………………………………………………………… 6112.2 Модель управления PMI …………………………………………………………... 6312.3 Модель делегирования …………………………………………………………... 6412.4 Модель ролей …………………………………………………………………….. 6513 Расширения сертификата для управления привилегиями ….……………………… 6613.1 Базовое расширение управления привилегиями ……………………………... 6613.2 Расширения аннулирования привилегий ………………………………………… 7013.3 Расширения источника полномочий……………………………………………… 7113.4 Расширения роли …………………………………………..……………………… 7313.5 Расширение делегирования …………………………………………………….... 7414 Процедура обработки пути привилегий…………………………….…………….... 7814.1 Процедура простой обработки ………………………………………………….. 7814.2 Процедура обработки роли ……………………………………………………… 8014.3 Процедура обработки делегирования ………………………………………....... 8015. Схема директории PMI ……………………………….……………………………... 82III

O′z DSt 1108:200615.1 Класс объекта директории PMI ………………………………………………… 8215.2 Атрибуты директории PMI ………………………………….…………………….. 8315.3 Общие правила соответствия директории PMI …………………………………. 8516 Аутентификация директории …………………………………………..…………….. 8616.1 Процедура простой аутентификации ……………………………………... 8616.2 Жесткая аутентификация ………………………………………………………..... 89Приложение A (обязательное) Структура сертификата открытого ключа исертификата атрибута …………………………………………………. 93Приложение B (обязательное) Правила генерации и обработки CRL ….………..…… 112Приложение C (обязательное) Эталонное определение алгоритма идентификаторовобъекта …………………………………………………………………. 120Приложение D (обязательное) Технические отклонения и их объяснения …………. 121Библиография …………………..…………………………………………………………. 123IV

ГОСУДАРСТВЕННЫЙ СТАНДАРТ УЗБЕКИСТАНААхборот технологиясиОЧИҚ ТИЗИМЛАР ЎЗАРО БОҒЛИҚЛИГИЭРИ очиқ калити сертификати ваатрибут сертификатининг тузилмасиИнформационная технологияВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМСтруктура сертификата открытого ключа ЭЦПи сертификата атрибутаInformation technologiesOPEN SYSTEM INTERCONNECTIONPublic key and attribute certificate frameworksO′z DSt 1108:20061 Область примененияДата введения 01.07.2006Настоящий стандарт предназначен для обеспечения требований безопасности вобласти аутентификации и других услуг безопасности, посредством установления структур,на которых могут быть основаны другие услуги безопасности. В частности, данный стандартопределяет структуру для:- сертификатов открытого ключа;- сертификатов атрибута;- услуг аутентификации.2 Нормативная ссылкаВ настоящем стандарте использована ссылка на следующий стандарт:O’z DSt 1047: 2003 Информационные технологии. Термины и определения.Примечание – При пользовании настоящим стандартом целесообразно проверить действие ссылочногостандарта на территории Узбекистана по соответствующему указателю стандартов, составленному посостоянию на 1 января текущего года, и по соответствующим информационным указателям, опубликованным втекущем году. Если ссылочный документ заменен (изменен), то при пользовании настоящим стандартомследует руководствоваться замененным (измененным) стандартом. Если ссылочный документ отменен беззамены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку.3 Термины, определения и сокращения3.1 Термины и определенияВ настоящем стандарте применены термины по O’z DSt 1047, а также следующиетермины с соответствующими определениями:3.1.1 базовый CRL: CRL, который используется как основа при генерации дельта-CRLdCRL.3.1.2 верификатор привилегий: Объект, удостоверяющий подлинность сертификатовв соответствии с политикой привилегий.1

O′z DSt 1108:20063.1.3 владелец: Объект, которому были делегированы некоторые привилегиинепосредственно одним источником полномочий (Центром регистрации) или косвенно черезцентр по присвоению атрибутов (Центром регистрации, присваиваивающим атрибуты).3.1.4 доверие: В общем случае, объекту может быть указано «доверять» второмуобъекту, когда он (первый объект) делает предположение, что второй объект будет вестисебя точно так, как ожидает первый объект.3.1.5 доверяющая сторона: Пользователь или агент, который полагается на данные всертификате при принятии решений.3.1.6 делегирование: Передача привилегий от одного объекта, который владеетопределенной привилегией, другому объекту.3.1.7 дельта-CRL (dCRL): Неполный список аннулирования, который содержиттолько список, содержащий записи только для тех сертификатов, статус аннулированиякоторых изменялся с момента составления справочной (реестровой) базы CRL.3.1.8 жесткая аутентификация: Аутентификация посредством верительных грамот,созданных с помощью криптографических методов.3.1.9 закрытый ключ ЭЦП: Последовательность символов, полученная сиспользованием средств электронной цифровой подписи, известная толькоподписывающему лицу и предназначенная для создания электронной цифровой подписи вэлектронном документе.3.1.10 инфраструктура открытых ключей (PKI): Техническая и организационнаяинфраструктура, которая обеспечивает поддержку использования технологийкриптопреобразований с открытым ключом.3.1.11 инфраструктура управления привилегиями (PMI): Инфраструктура,способная поддерживать управление привилегиями в подтверждении комплексной службыавторизации и во время взаимоотношений с PKI.3.1.12 источник полномочий (SOA) (Центр регистрации, присваивающийатрибуты): Центр по присвоению атрибутов (Центр регистрации), который являетсяверификатором привилегий для отдельного ресурса, ответственного как первичный орган,назначающий набор привилегий.3.1.13 конечный объект: Объект сертификата, который использует его секретныйключ для других целей кроме подписания сертификатов или объект, который являетсядоверяющей стороной.3.1.14 конфиденциальность данных: Это услуга, используемая для защиты данных отвозможности прочтения содержания данных не имеющим привилегий объектам и котораяподдерживается структурой аутентификации.3.1.15 косвенный CRL (iCRL): Список аннулирования, который содержитминимальную информацию об аннулировании сертификатов, изданных другими органами,отличными от органа выпустившего данный CRL.3.1.16 криптографический алгоритм, криптоалгоритм: Математический алгоритмпреобразования информации с целью предотвратить возможность её искажения изащитить от несанкционированного доступа.3.1.17 критичность: Характеристика ресурса, которая подразумевает его значение иважность.3.1.18 маркер (признак) аутентификации: Информация, сообщаемая во время обменапри жесткой аутентификации, которая может быть использована для подтвержденияподлинности её отправителя.3.1.19 назначитель привилегий: Владелец привилегий, использующий сертификататрибута или сертификат открытого ключа для назначения привилегий.3.1.20 объектный метод: Действие, которое может быть совершено над ресурсом(например, файловая система может иметь объектные методы чтения, записи и выполнения).3.1.21 однонаправленная функция: Функция, для которой по заданному аргументу xлегко вычислить значение функции f(x), но определение x из f(x) трудно вычислимо.3.1.22 орган: Объект, ответственный за выдачу сертификатов.2

O′z DSt 1108:20063.1.23 орган по присвоению атрибутов (AA): Орган (Центр регистрации), которыйназначает привилегии посредством выдачи сертификата атрибута.3.1.24 открытый ключ ЭЦП: Последовательность символов, полученная сиспользованием средств электронной цифровой подписи, соответствующая закрытомуключу электронной цифровой подписи, доступная любому пользователю информационнойсистемы и предназначенная для подтверждения подлинности электронной цифровойподписи в электронном документе.3.1.25 отображение политики: Признание того, что, когда Центр регистрации (далееЦР) в одном домене сертифицирует ЦР, находящийся в другом домене, политикасертификата, действующая во втором домене, может рассматриваться органом в первомдомене как эквивалентная (но не обязательна идентичность во всех отношениях) политикесертификата, действующей в первом домене.3.1.26 переменные среды: Это те аспекты политики, которые требуются дляавторизованных решений, которые не содержатся в статических структурах, но доступны дляверификатора привилегий с помощью некоторых локальных средств (например, время сутокили текущий баланс отчета).3.1.27 персональный идентификационный номер: Последовательность чисел,которая идентифицирует личность (например, при доступе к различным видам услуг).3.1.28 политика безопасности: Набор правил, установленных органом побезопасности, контролирующим использование и обеспечение услуг и средствбезопасности.3.1.29 политика сертификата: Установленный набор правил, который указываетприменимость сертификата к конкретному семейству и/или классу приложений с общимитребованиями безопасности.3.1.30 полный CRL: Полный список аннулирования, который содержит отдельныезаписи для всех сертификатов, которые отменены в данной области.3.1.31 пользователь сертификата: Объект, которому необходимо знать открытыйключ другого объекта.3.1.32 привилегия: Атрибут или свойство, назначенное объекту соответствующиморганом.3.1.33 проверка достоверности сертификата: Процесс удостоверения того, чтосертификат действителен на данный момент времени, включая возможность построения иобработки пути сертификата, и удостоверения того, что все сертификаты в данном путибудут действительны (т.е. не истек ли срок или не аннулирован ли сертификат) на данныймомент.3.1.34 простая аутентификация: Аутентификация посредством соглашений простыхпаролей.3.1.35 пункт распределения CRL: Элемент директории (реестра) или другой источникраспространения CRL; CRL распространенный пунктом распределения CRL можетсодержать элементы аннулирования только для поднабора полного набора сертификатов,изданных одним ЦР или может содержать элементы аннулирования для множества ЦР.3.1.36 путь делегирования: Упорядоченная последовательность сертификатов,которые, вместе с идентифицирующей информацией назначителя привилегий могут бытьобработаны для подтверждения аутентичности привилегий назначителя привилегий.3.1.37 путь сертификации: Упорядоченная последовательность сертификатовобъектов в информационном дереве директории (DIT), которые вместе с открытым ключомисходного объекта могут быть обработаны, чтобы достичь конечного объекта в пути.3.1.38 сертификат назначения роли: Сертификат, который содержит атрибут роли,назначающий одну или более одной роли субъекту/владельцу.3.1.39 серийный номер сертификата: Целое число, уникальное для выдавшегооргана, которое однозначно связано с сертификатом, выпущенным данным ЦР.3

O′z DSt 1108:20063.1.40 сертификат атрибута: Структура цифровых данных, подписанная органом поприсвоению атрибутов (Центром регистрации), которая связывает некоторые значенияатрибута с идентифицирующей информацией о ее владельце.3.1.41 сертификат определения роли: Сертификат, который содержит назначениепривилегий для роли.3.1.42 сертификат открытого ключа: Документ, подтверждающий соответствиеоткрытого ключа ЭЦП закрытому ключу ЭЦП и выданный Центром регистрации владельцузакрытого ключа ЭЦП.3.1.43 сертификат органа: Сертификат, выпущенный для органа (например, дляЦентра регистрации).3.1.44 Центр регистрации: Юридическое лицо, прошедшее государственнуюрегистрацию в Органе регистрации Центров регистрации и выполняющее функции,предусмотренные законодательством.3.1.45 сертификат – центра регистрации: Сертификат для одного ЦР, изданныйОрганом регистрации.3.1.46 система, использующая сертификат: Система, реализующая те функции,которые определены в данном стандарте и, которые используются пользователемсертификата.3.1.47 список аннулированных органов по присвоению атрибута (AARL): Списоканнулирования, содержащий список ссылок на сертификаты атрибутов, выданных для органапо присвоению атрибутов, которые больше не считаются действительными при авторизации.3.1.48 соглашение о ключах: Метод онлайнового согласования значения ключа, безпередачи ключа, даже в зашифрованном виде (например, метод Диффи-Хеллмана).3.1.49 список аннулированных сертификатов (CRL): Подписанный список,указывающий на набор сертификатов, которые больше не считаются действительнымииздателем сертификатов.3.1.50 список аннулированных сертификатов атрибута (ACRL): Списоканнулирования, содержащий список ссылок на сертификаты атрибутов, которые больше несчитаются действительными издающим органом.3.1.51 список аннулированных сертификатов атрибутов конечного объекта(EARL): Список аннулирования, содержащий список сертификатов атрибутов, которыевыданы держателям – не являющимися органами по присвоению атрибутов, которые большене считаются действительным органом, издающим сертификаты.3.1.52 список аннулированных сертификатов открытых ключей конечногообъекта (EPRL): Список аннулирования, содержащий список сертификатов открытыхключей, которые изданы субъектом - не являющимся ЦР, которые больше не считаютсядействительным органом, выдающим сертификаты.3.1.53 список аннулированных центров регистрации (CARL): Списоканнулирования, содержащий список сертификатов открытых ключей, изданных Центрамрегистрации, которые больше не считаются действительными издателем сертификатов.3.1.54 среднее время по Гринвичу: Время по Гринвичу (Англия), используемое какначало отсчета для вычисления временных зон земли.3.1.55 хэш-функция: Функция, отображающая строки бит в строки бит фиксированнойдлины.43.2 СокращенияВ данном стандарте применяются следующие сокращения:AA - Attribute AuthorityAARL -Attribute Authority Revocation Listорган по присвоению атрибутовсписок аннулированных органов поприсвоению атрибутовACRL - Attribute Certificate Revocation List список аннулированныхсертификатов атрибута

O′z DSt 1108:2006CA - Certification Authorityцентр регистрацииCARL - Certification Authority Revocation List список аннулированных центроврегистрацииCRL - Certificate Revocation List список аннулированныхсертификатовdCRL - Delta Certificate Revocation List дельта список аннулированныхсертификатовDIB - Directory Information Baseинформационная база директорииDIT - Directory Information Treeинформационное дерево директорииDSA - Directory System Agentсистемный агент директорииDUA - Directory User Agentагент пользователя директорииEARL - End-entity Attribute certificate Revocation List список аннулированныхсертификатов атрибута конечногообъектаEPRL - End-entity Public-key certificate Revocation List список аннулированныхсертификатов открытого ключаконечного объектаiCRL - Indirect Certificate Revocation Listсписок аннулированных косвенныхсертификатовPKCS - Public-Key Cryptosystemкриптосистема с открытым ключомPKI - Public-Key Infrastructureинфраструктура открытых ключейPMI - Privilege Management Infrastructure инфраструктура управленияпривилегиямиSOA - Source of Authorityисточник полномочий4 Общие положенияСтруктура сертификата открытого ключа, определенная в данном стандарте, включаетопределение информационного объекта для инфраструктуры открытого ключа (PKI),включающего сертификаты открытого ключа и список аннулированных сертификатов (CRL).Структура сертификата атрибута включает определение информационного объекта дляинфраструктуры управления привилегиями, включающего сертификаты атрибута и списоканнулированных сертификатов атрибута. Данный стандарт дает возможность структуревыпускать, управлять, использовать и аннулировать сертификаты.Данный стандарт также включает набор стандартных расширений, которые рассчитанытак, чтобы они были пригодными для большого количества приложений PKI и PMI. Вданный стандарт включены компоненты схемы, классы объектов, имеющие типы атрибутови правила согласования для хранения в директории (реестре) объектов PKI и PMI. Другиеэлементы PKI и PMI, такие как протоколы управления ключом и сертификатом, протоколэксплуатации, дополнительный сертификат и расширение CRL выходят за пределырассмотрения данного стандарта.Схема аутентификации, определенная в данном стандарте, является общей, и можетбыть использована в различных приложениях и средах.Директория (реестр) [2] использует сертификаты открытого ключа и сертификатыатрибута. Технология открытого ключа включает сертификаты, используемые директорией(реестром), для активизации жесткой аутентификации, операций подписания и шифрованияи для хранения подписанных или зашифрованных данных в директории (реестре).Сертификаты атрибута могут быть использованы директорией (реестром) для активизацииуправления доступом, основанного на ролях.Данный стандарт определяет структуру услуг аутентификации следующим образом:- установлением формы информации для аутентификации, содержащейся в директории(реестре);5

O′z DSt 1108:2006- описанием, как из директории (реестра) может быть получена информация дляаутентификации;- установлением правил формирования и расположения информации дляаутентификации в директории (реестре);- определением трех методов, с помощью, которых приложения могут использоватьданную информацию для выполнения аутентификации, и описанием, как с помощьюаутентификации могут поддерживаться другие сервисы безопасности.Данный стандарт описывает два уровня аутентификации: простая аутентификация,использующая пароль как подтверждение предъявленного идентификатора; и жесткаяаутентификация, включающая в себя оформленные верительные грамоты, использующиекриптографические методы. Простая аутентификация обеспечивает несколько ограниченнуюзащиту от несанкционированного доступа, только жесткая аутентификация может бытьиспользована как основа для обеспечения услуг безопасности.Аутентификация (и другие услуги безопасности) может быть обеспечена только впределах контекста определённой политики безопасности. Она предназначена дляпользователей приложений, чтобы определить их собственную политику безопасности,которая может быть ограничена услугами, обеспечиваемыми стандартом.Аутентификация предназначена для стандартно-определямых приложений, которыеиспользуют структуру аутентификации для определения протоколов обмена, которыедолжны быть выполнены для того, чтобы успешно завершить аутентификацию, основаннуюна информации для аутентификации полученной из директории (реестра). Протокол,используемый приложениями для получения верительной грамоты, называется протоколомдоступа к директории (реестру).5 Открытые ключи и сертификаты открытых ключей5.1 Генерация пары ключейОбщая политика управления безопасностью реализации определяется жизненнымциклом пары ключей и выходит за область рассмотрения данного стандарта. Однако, крайненеобходимо, чтобы общая безопасность закрытых ключей зависела от того, что ониоставались известными только пользователю, которому они принадлежат.Ключевые данные нелегко запомнить простому пользователю, поэтому должныупотребляться подходящие методы для их сохранения в удобных для транспортировкимеханизмах. Один из используемых механизмов это «Smart Card». Он должен хранитьзакрытый и открытый ключ пользователя, сертификат пользователя и копию открытогоключа ЦР. Использование этой карты обеспечивает дополнительную безопасность,например, использование персонального идентификационного номера (PIN) увеличиваетбезопасность системы требуемую пользователем. Однако, конкретный метод сохранениятакого рода данных выходит за пределы этого стандарта.Существуют три метода изготовления пары ключей:а) пользователь генерирует свои пары ключей. Этот метод имеет преимущество тем,что закрытый ключ пользователя никогда не будет передан другим объектам, но здесьтребуется определенный уровень знаний пользователя;b) пара ключей генерируется третьей стороной. Третья сторона должна передаватьзакрытый ключ пользователю физически безопасным методом, затем уничтожить всюинформацию, связанную с созданием пары ключей и с самими ключами. Должны бытьприменены подходящие критерии соответствующей физической безопасности длягарантирования, что третья сторона и данные о действиях будут защищены от подделки;c) пара ключей генерируется центром регистрации. Это частный случай вариантаа) и b).6

O′z DSt 1108:20065.2 Создание сертификата открытого ключаСтруктура сертификата открытого ключа, определенная данным стандартом,предназначена для использования приложениями, требующими аутентификации,целостности, конфиденциальности и безотказности от авторства.Формат сертификатов открытого ключа определенный в данном стандарте включаетмеханизм расширяемости и набор специфических расширений сертификата. Если понекоторым причинам орган аннулирует заранее выданный сертификат открытого ключа,пользователи должны быть уведомлены о том, что произошло аннулирование, чтобы они неиспользовали не надежные сертификаты. Списки аннулирования это одна из структур,которая может быть использована для уведомления пользователей об аннулировании.Формат списков аннулирования определенный в данном стандарте включает механизмрасширяемости и набор расширений списков аннулирования. И в сертификате, и в спискеаннулирования могут быть также определены другие расширения, которые пригодны для ихспецифических сред.Система, использующая сертификат открытого ключа, должна подтверждатьсертификат до использования этого сертификата для приложения. Процедуры длявыполнения подтверждения, определенные в данном стандарте, включают проверкуцелостности сертификата изданного для себя, его статус аннулирования, и егодействительность для его использования в определенных целях.Директория (реестр) использует сертификат открытого ключа при обеспечении услугбезопасности, которые включают:- жесткую аутентификацию между (и среди) компонентами директории (реестра);- аутентификацию, целостность и конфиденциальность операций директории(реестра);- целостность и аутентификацию хранимых данных.Для аутентификации подлинности определенного пользователя, открытый ключдолжен быть получен от доверенного источника. Таким источником может быть центррегистрации (далее ЦР), удостоверяющий открытый ключ посредством выдачи сертификатаоткрытого ключа, который связывает открытый ключ с соответствующим закрытым ключомобъекта. Процедуры, используемые ЦР для обеспечения гарантии того, что объект на самомделе владеет закрытым ключом, и другие процедуры, связанные с изданием сертификатаоткрытого ключа, выходят за пределы рассмотрения данного стандарта. Сертификат, формакоторого определена в данном стандарте, имеет следующие свойства:- любой пользователь, имеющий доступ к открытому ключу центра регистрации можетобратно получить открытый ключ, который был сертифицирован;- не существует другого субъекта, кроме центра регистрации, который мог бымодифицировать сертификат (сертификаты не подделываемы).Из-за того, что сертификаты не подделываемы, они могут быть опубликованы вопределённых местах, в директории (реестре), без необходимости дальнейших усилийзащитить их.ЦР создает сертификаты пользователей с помощью совокупности информации, в томчисле различительного имени пользователя и открытого ключа, а также необязательногоуникального идентификатора, включающего дополнительную информацию о пользователе.Точная форма состава уникального идентификатора не определена в данном стандарте и онаопределяется ЦР: например, может быть идентификатор объекта, сертификат, дата, иликакая-нибудь другая форма сертификации, которая определяет достоверностьразличительного имени. Сертификат пользователя с именем A и уникальнымидентификатором УA, выданный Центром регистрации с названием ЦР и уникальнымидентификатором УЦР, имеет следующую форму:ЦР=ЦР{В, СН, ИА, ЦР, УЦР, A, УА, A p , T A }7

O′z DSt 1108:2006где, В - это версия сертификата, СН - это серийный номер сертификата, ИА -идентификатор алгоритма, использованного для подписания сертификата, УЦР - этонеобязательный уникальный идентификатор ЦР, УА - необязательный уникальныйидентификатор пользователя A, T A - указывает период действия сертификата и содержит дведаты, начало и окончание действительности сертификата. Период действительностисертификата это интервал времени в течении которого ЦР гарантирует что он будетподдерживать информацию о статусе сертификата, т.е. не будет издавать данные обаннулировании. Сразу после получения T A изменения будут введены не менее чем за 24часа, здесь предполагается, что система будет использовать среднее время по Гринвичу(GMT) как эталонное время. Подпись в сертификате будет проверена на достоверностьлюбым пользователем знающим ЦР P . Для представления сертификатов могут бытьиспользованы нижеприведенные типы данных:Certificate ::= SIGNED { SEQUENCE {version [0] Version DEFAULT v1,serialNumberCertificateSerialNumber,signatureAlgorithmIdentifier,issuerName,validityValidity,subjectName,subjectPublicKeyInfoSubjectPublicKeyInfo,issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL,--агар келтирилган бўлса, у ҳолда версия v2 ёки v3 бўлиши керакsubjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL,--агар келтирилган бўлса, у ҳолда версия v2 ёки v3 бўлиши керакextensions [3] Extensions OPTIONAL--агар келтирилган бўлса, у ҳолда версия v3 бўлиши керак } }Version ::= INTEGER { v1(0), v2(1), v3(2) }CertificateSerialNumber ::= INTEGERAlgorithmIdentifier ::= SEQUENCE {algorithmALGORITHM.&id ({SupportedAlgorithms}),parameters ALGORITHM.&Type ({SupportedAlgorithms}{ @algorithm})OPTIONAL }SupportedAlgorithms ALGORITHM ::= { ... }Validity ::= SEQUENCE {notBefore Time,notAfter Time }SubjectPublicKeyInfo ::= SEQUENCE {algorithmAlgorithmIdentifier,subjectPublicKey BIT STRING }Time ::= CHOICE {utcTimeUTCTime,generalizedTime GeneralizedTime }Extensions ::= SEQUENCE OF ExtensionExtension ::= SEQUENCE {extnId EXTENSION.&id ({ExtensionSet}),critical BOOLEAN DEFAULT FALSE,extnValue OCTET STRING}ExtensionSet EXTENSION ::= { ... }Перед значением Time используется любая операция сравнения, например, как частьправила согласования при поиске, а если синтаксис Time выбран как тип UTCTime,8

O′z DSt 1108:2006значение двухцифрового поля будет усовершенствовано в четырёх цифровое значение, какприведено ниже:- если двухцифровое значение от 00 до 49 включительно, то значение равно 2000 вдополнение к нему;- если двухцифровое значение от 50 до 99 включительно, то значение равно 1900 вдополнение к нему;Ниже приведены описания каждых типов данных:version - это версия сертификата. Если в сертификате представляется основная частьextensions (расширения), то версия сертификата будет v3 [1]. Если представляетсякомпонента issuerUniqueIdentifier или subjectUniqueIdentifier, то версия сертификатабудет v2 или v3. Если появляются неизвестные элементы в пределах расширения ирасширение не отмечено критическим, эти неизвестные элементы игнорируются согласноправилам расширяемости.serialNumber целое число, отведенное ЦР для каждого сертификата. Значениесерийного номера должно быть уникальным для каждого сертификата, выданногоопределенным ЦР (например, выданное название и серийный номер определяютуникальность сертификата).signature состоит из идентификатора алгоритма и хеш-функций использованных ЦРдля подписания сертификата (например, md5WithRSAEncryption, sha-1WithRSAEncryption,id-dsa-with-sha1, и т.д.).issuer устанавливает объект, который подписывает и выдает сертификат.validity временной интервал, в течении которого ЦР гарантирует, что он будетподдерживать информацию о статусе сертификата.subject устанавливает объект, который связан с открытым ключом получаемого из поляоткрытого ключа субъекта.subjectPublicKeyInfo используется для сообщения о том, что открытый ключсертифицирован и для идентификации алгоритма (например rsaEncryption, dhpublicnumber,id-dsa).issuerUniqueIdentifier используется, чтобы уникально идентифицировать выдающийорган в случае повторного использования имени.subjectUniqueIdentifier используется, чтобы уникально идентифицировать субъект вслучае повторного использования имени.В случае, где различительное имя могло быть передано другому пользователю органом,выдающим имена (центром регистрации), ЦР может использовать уникальныйидентификатор, чтобы была возможность различать случаи повторного использования имён.Однако, если одинаковые пользователи обеспечены сертификатами различных ЦР,необходимо, чтобы ЦР координировали выдачу уникальных идентификаторов как часть ихпроцедуры регистрации пользователей.Поле extensions позволяет добавлять новые поля в структуру без модификацииопределения ASN.1 (язык). Поле расширения содержит идентификатор расширения, флагкритичности, зашифрованное значение данных типа ASN.1, связанного сидентифицированным расширением. Для этих расширений, где установка индивидуальныхрасширений указан в пределах SEQUENCE, спецификация этих индивидуальныхрасширений должна включать правила для выражения порядка. Когда реализация обработкисертификата не распознает расширение и если флаг критичности, имеет значение FALSE,она может игнорировать его. Если флаг критичности имеет значение, нераспознанныерасширения будут причиной того, что структура будет принята недействительной,например, в сертификате нераспознанное расширение будет причиной утверждения подписи,использующей этот сертификат, поврежденной. Когда реализация, использующаясертификат распознает и обрабатывает расширения, тогда эта реализация будетобрабатывать расширения вне зависимости от значения флага критичности. Любыерасширения, которые обозначены как некритические будут причиной несовместимостимежду системами, которые используют сертификат и обрабатывают расширения, и9

O′z DSt 1108:2006системами, использующими сертификат и которые не распознают расширение и игнорируетего.Если в пределах расширения появились не известные элементы и расширение неотмечено как критическое, эти неизвестные элементы будут игнорированы согласноправилам расширяемости.ЦР имеют три варианта, касающихся расширения и могут:1) исключить расширение из сертификата;2) включить расширение и его флаг как некритические;3) включить расширение и его флаг как критические.Процедура подтверждения производится в двух возможных действиях, касающихсярасширения:1) игнорированием расширения и принятием сертификата (все другие действияпроизводятся эквивалентно);2) обработкой расширения и принятием или отклонением сертификата в зависимостиот содержания расширения и от обстоятельств, в которых происходит обработка (например,когда текущие значения обработки пути изменяются).Некоторые расширения могут быть отмечены только как критические. В таких случаях,процедура подтверждения, которая понимает расширение, обрабатывает его ипризнает/отклоняет сертификат, зависит от содержания расширения. Процедураподтверждения, которая не понимает расширение, отклоняет сертификат.Некоторые расширения могут быть только отмечены как некритические. В такихслучаях, процедура подтверждения, которая понимает расширение, обрабатывает его ипризнает/отклоняет сертификат, зависит от содержания расширения. Процессподтверждения, который не понимает расширение, признает сертификат (пока другиефакторы не повлияют на отклонение).Некоторые расширения могут быть отмечены как критические или некритические. Втаких случаях, процедура подтверждения, которая понимает расширение и обрабатывает егопризнает/отклоняет сертификат, зависит от содержания расширения, несмотря на наличиефлага в сертификате. Процесс подтверждения не понимающий расширение, принимаетсертификат, если расширение отмечено как некритическое (пока другие факторы неповлияют на отклонение) и отклоняет сертификат, если расширение отмечено каккритическое.Когда ЦР рассматривает состав расширения в сертификате, он считает, что егосодержание будет поддерживаться при любых обстоятельствах. Если необходимо, чтобысодержание расширения было рассмотрено, прежде чем будут рассмотрены другие данные всертификате, ЦР должен установить расширение критическим. Это производится, приреализации, чтобы любой процесс подтверждения, который не обрабатывает расширение,был отклонен (возможен, ограничивающий набор приложений, который может подтвердитьсертификат). ЦР может отметить некоторые расширения как некритические для достиженияполной совместимости с предыдущими версиями подтверждающих приложений, которые немогут обработать расширения. Там, где необходимость совместимости расширения с болеепоздними версиями и взаимодействие с подтверждающими приложениями, неспособнымиобработать расширения, более существеннее, чем возможность ЦР вводить в действиерасширение, эти необязательно критические расширения должны быть отмечены какнекритические. Это означает то, что ЦР должны установить необязательные критическиерасширения как некритические в течение переходного периода пока улучшаютсяверификаторы приложений обработки сертификата.Для определения специфических расширений используется следующий класс объекта.EXTENSION ::= CLASS {&id OBJECT IDENTIFIER UNIQUE,&ExtnType }WITH SYNTAX {SYNTAX&ExtnType10

O′z DSt 1108:2006IDENTIFIED BY &id }Существуют два основных типа сертификатов открытого ключа: сертификатыконечного объекта и сертификаты ЦР.Сертификат конечного объекта выдается со стороны ЦР субъекту, который не издаетдругие сертификаты открытых ключей.Сертификат ЦР, сертификат, выданный со стороны ЦР субъекту, который сам являетсяЦР и поэтому способен издавать сертификаты открытого ключа. Сертификаты ЦР могутбыть классифицированы по следующим типам:- сертификат, изданный самому себе. Это сертификат, где издатель и субъект один и тотже ЦР. ЦР может использовать сертификаты, изданные самому себе, например, в течениеоперации продления действия ключа для обеспечения достоверности при переходе отстарого ключа к новому;- сертификат, подписанный самим ЦР. Это частный случай сертификата, выданногосамому себе, где закрытый ключ используется ЦР для подписания сертификатасоответствующего открытому ключу, который сертифицирован посредством сертификата;- кросс сертификат. Это сертификат, где выдающая сторона и субъект - это разные ЦР.ЦР выдают сертификаты другим ЦР или как механизм для авторизации наличия субъектногоЦР (например, в точно определённой иерархии) или для признания действительностисубъектного ЦР (например, в распределенной модели доверия). Структура кросссертификата используется в обоих случаях.Элемент директории (реестра) всех пользователей, которые принимают участие вжесткой аутентификации, содержит сертификат(ы) пользователя А. Такой сертификатгенерируется центром регистрации пользователя А, который является объектом винформационном дереве директории (DIT). Центр регистрации пользователя А, которыйможет быть не уникальным, обозначается как ЦР(А) или просто центр регистрации, еслиподразумевается пользователь А. Открытый ключ пользователя А может быть найденлюбым пользователем, знающим открытый ключ центра регистрации. Нахождениеоткрытого ключа называется рекурсией.Если пользователь А пытается приобрести открытый ключ пользователя В, он такжедостает открытый ключ ЦР(В). Чтобы у пользователя А была возможность достать открытыйключ ЦР(В), элемент директории каждого ЦР содержит некоторое количество сертификатов.Сертификаты бывают двух типов. Первые - готовые сертификаты X, сгенерированныедругими сертифицирующими органами. Вторые – сертификаты, сгенерированные самим X,которые сертифицированы закрытым ключом других сертифицирующих органов. Наличиеэтих сертификатов дает пользователям возможность создания пути от одной точки к другой.Список сертификатов, известный как путь сертификации, необходим дляпредоставления отдельному пользователю возможности получения открытого ключа другогопользователя. Каждый элемент в списке, это сертификат, сертифицирующего органаследующего элемента в списке. Путь сертификации от A к B (обозначен как A→ B):- начинается с сертификата выданного ЦР(А), т.е. ЦР(А) «X1» для некоторого объектаX1;- далее идут следующие сертификаты Xi«Xi+1»;- заканчивается сертификатом пользователя B.Путь сертификации логическая форма неразрывной (непрерывной) цепи доверенныхпунктов в информационном дереве директории (DIT) между пользователями, желающимипроизвести аутентификацию. Определенные методы употребляемые пользователями А и Вдля получения путей сертификации А → В и В → А могут отличаться. Один из путейсогласования - это систематизация иерархий ЦР в самой иерархии, которые могут или немогут совпадать со всей или с частью иерархии DIT.Пользователь может получить один или более одного сертификата от одного или болееодного сертифицирующего органа. Каждый сертификат носит (поддерживает) название11

O′z DSt 1108:2006Сертифицирующего Органа, который выдал его. Для представления сертификата или путисертификации могут использоваться следующие типы данных ASN.1:Certificates ::= SEQUENCE {userCertificate Certificate,certificationPath CertPath OPTIONAL }12CertificationPath ::= SEQUENCE {userCertificate Certificate,theCACertificates SEQUENCE OF CertificatePair OPTIONAL }Кроме этого, для представления начального пути сертификации может бытьиспользован следующий тип данных ASN.1. Эта компонента содержит путь сертификации,который может быть точкой возврата для инициатора.CertPath::= SEQUENCE OF CrossCertificatesCrossCertificates ::= SET OF CertificateКаждый сертификат в пути сертификации должен быть уникальным. Не может бытьсертификата, который появляется более чем один раз в значении theCACertificatesкомпоненты CertificationPath или в значении Certificate в CrossCertificates компонентыCertPath.Сертификат открытого ключа связан с открытым ключом и уникальнымразличительным именем пользователя, которое описывает его. Таким образом:a) сертифицирующий орган должен выполнять идентичность пользователя передсозданием сертификата для него;b) сертифицирующий орган не должен выдавать сертификаты с одинаковымиименами двум пользователям.Важно, что передача информации сертифицирующему органу не должна бытьскомпрометирована и должны быть приняты соответствующие критерии физическойбезопасности. В связи с этим:a) будет серьезным нарушением безопасности, если ЦР выдаст сертификат дляпользователя несмотря на то, что открытый ключ был подделан;b) если применен метод генерации ключей описанный в 5.1 b) и с), то закрытый ключпользователя будет передан пользователю безопасным методом;c) если применен метод генерации ключей описанный в 5.1 а) и b), пользователь можетиспользовать различные методы (on-line или off-line) для передачи открытого ключа ЦРбезопасным методом. Метод on-line может обеспечивать некоторую гибкость для удаленныхопераций, выполняемых между пользователем и ЦР.Сертификат открытого ключа публично доступен и нет определенных уровнейбезопасности, необходимых для их транспортировки в директорию.5.3 Действительность сертификатаОрган, который выдаёт сертификаты (открытого ключа и атрибута) также ответствененза индикацию действительности сертификатов, выданных им. Сертификаты это субъекты,которые позднее должны быть аннулированы. Эти аннулирования и уведомления обаннулировании могут быть сделаны непосредственно одним органом, который выдалсертификат или косвенно другим органом, который авторизован органом, выдающимсертификат.Орган, производящий аннулирование сертификатов, может использовать механизм(ы)доверяющей стороны для получения информации о статусе аннулирования, о сертификатахвыданных органом. В данном стандарте определен механизм списка аннулированныхсертификатов (CRL), но не исключается использование других механизмов. Доверяющиестороны проверяют информацию о статусе аннулирования для утверждения сертификата,как присуще для всех сертификатов рассматриваемых в процессе процедуры обработки пути

O′z DSt 1108:2006сертификации описанной в разделе 7, и в процессе обработки передачи привилегий,описанного в разделе 13.Сертификаты, включающие сертификаты открытого ключа, так же как сертификатыатрибута должны иметь время жизни, связанное с ними, в конце которого оно истекает. Длятого чтобы обеспечить непрерывность услуг, орган должен гарантировать регулярноеобновление работоспособности сертификатов, чтобы заменять сертификаты, срок которыхистек/истекает. Дата извещения об аннулировании это дата/время, когда извещение обаннулировании сертификата впервые появилось в CRL, вне зависимости от того, оно вбазовом или в дельта CRL. В CRL, дата извещения об аннулировании сертификатасодержится в поле thisUpdate. Дата аннулирования - это дата/время фактическогоаннулирования сертификата со стороны ЦР. В CRL дата аннулирования содержится вкомпоненте revocationDate.Может быть, что:- действие сертификатов может быть рассчитано так, что каждый становитсядействительным ко времени, когда истекает срок предыдущего, или может быть допущенонекоторое наложение их даты;- сертификаты, сроки которых истекли, удаляются из директории.Сертификаты могут быть аннулированы до их времени аннулирования, например, еслизакрытый ключ пользователя скомпрометирован или если был скомпрометировансертификат ЦР. Аннулирование сертификата пользователя или сертификата органа должнобыть произведено при соответствующем оповещении и новый выданный сертификат долженбыть действительным. Орган может затем информировать владельца сертификата о егоаннулировании с помощью некоторых off-line методов.Орган, выдающий и аннулирующий сертификаты:a) может нуждаться в поддержке аудита записей его событий, аннулирования для всехтипов сертификатов, выданных органом (например, сертификаты открытого ключа,сертификаты атрибута, выданные конечным объектам также как другим органам);b) должен предоставлять информацию о статусе аннулирования надёжным сторонам,используя CRL, протокол получения в on-line статуса сертификата или другимимеханизмами для публикации информации о статусе аннулирования;c) если используются CRL, должен поддерживать и публиковать CRL, даже если списоканнулированных сертификатов пуст.Доверяющие стороны могут использовать несколько механизмов для определенияместа расположения информации о статусе аннулирования. Например, в сертификате можетбыть указатель, который направляет доверяющую сторону к месту, где находитсяинформация об аннулировании. Это может быть указатель в списке аннулирования, которыйперенаправляет доверяющую сторону в различные места. Доверяющая сторона может найтиинформацию об аннулировании в архиве (например, в директории).Поддержание директории затрагивает списки аннулированных органов ответственныхза директорию и его пользователей выполняющих обязанности в согласованности сполитикой безопасности. Например, пользователь может модифицировать элемент объекта,поменяв его старый сертификат на новый.Если списки аннулирования опубликованы в директории, они держатся в списке какатрибуты следующих типов:- список аннулированных сертификатов;- список аннулированных органов;- дельта список аннулирования;- список аннулированных сертификатов атрибутов;- список аннулированных органов по присвоению атрибутов.Действительность сертификата определяется следующими типами данных:CertificateList ::= SIGNED { SEQUENCE {versionVersion OPTIONAL,--если представлено то версия будет v213

O′z DSt 1108:2006signatureAlgorithmIdentifier,issuerName,thisUpdateTime,nextUpdateTime OPTIONAL,revokedCertificates SEQUENCE OF SEQUENCE {serialNumberCertificateSerialNumber,revocationDateTime,crlEntryExtensionsExtensions OPTIONAL } OPTIONAL,crlExtensions [0] Extensions OPTIONAL }}Ниже приведены описания каждых типов данных:version версия зашифрованного списка аннулирования. Если компонента extensionsотмечена как критическое, то она представляется в списке аннулирования, и версиясертификата должна быть v2. Если нет компоненты extensions отмеченной как критическое,то оно представляется в списке аннулирования и версия может отсутствовать или можетпредставляться как v2.signature содержит идентификатор алгоритма, для алгоритма использованного органомдля подписания списка аннулирования.issuer указывает на объект, который подписал и издал список аннулирования.thisUpdate это дата/время, когда этот список аннулирования был издан.nextUpdate, если указано, то указывает на дату/время, согласно которому будет изданследующий список аннулирования в этой серии.revokedCertificates указывает на сертификаты, которые аннулированы.Аннулированные сертификаты идентифицируются серийным номером. Если ни один изсертификатов неаннулирован согласно CRL, строго рекомендуется чтобы параметрrevokedCertificates не был включен в CRL, лучше, если он не будет включен с пустымпараметром SEQUENCE.Если представлено crlExtension, оно содержит один или более расширений CRL.146 Расширение сертификата открытого ключа и расширение CRL6.1 Обработка политики6.1.1 Политика сертификатаРасширения сертификатов определенные в этом разделе, предназначены дляиспользования с сертификатом открытого ключа. Расширения, используемые ссертификатами атрибутов, определены в разделе 12. Расширения CRL, определенные в этомразделе, могут быть использованы в CRL, CARL, а также для ACRL и AARL, определенныхв разделе 14 и 15.Этот раздел определяет расширения в следующих областях:a) в информации о ключе и политике: Эти расширения сертификата и расширения CRLдают дополнительную информацию о ключах, включающих идентификатор ключей длясубъекта и издателя, указатели предназначения или ограничения использования ключа иуказатель политики безопасности;b) в атрибутах субъекта и издателя: Эти расширения сертификата и CRLподдерживают альтернативные названия различных форм имен для субъекта сертификата,для стороны, выдающей сертификат, или для стороны, выдающей CRL. Эти расширениятакже могут давать добавочную атрибут - информацию о субъекте сертификата, длясодействия пользователю сертификата в удостоверении, что субъект сертификата -определенная личность или объект;c) в ограничениях пути сертификации: Эти расширения сертификата позволяютограничить детали для включения в сертификаты ЦР или в сертификаты ЦР, выданныедругими ЦР, для облегчения автоматизации процесса обработки путей сертификации, когдавовлечена различная политика сертификата. Различная политика сертификата появляется,

O′z DSt 1108:2006когда политика различна для различных приложений в среде или когда происходят операциис внешней средой. Ограничения могут ограничивать типы сертификатов, которые могут бытьизданы субъектному ЦР или могут впоследствии появляться на пути сертификации;d) в основных расширениях CRL: Эти расширения CRL позволяют включить в CRLуказатель причины аннулирования для обеспечения временного приостановлениясертификата и для включения последовательности номеров выдачи CRL для возможностиобнаружить пользователем сертификата отсутствующий CRL в последовательностиисходящего от одного органа издающего CRL;e) в пунктах распределения CRL и дельта CRL: Эти расширения сертификата и CRLпредоставляют полный набор информации об аннулировании исходящего от одного ЦР,чтобы быть разделенными на отдельные CRL и предоставляют информацию обаннулировании исходящих от различных ЦР для комбинирования в одном CRL. Этирасширения также поддерживают использование не полных CRL, указывающих только наизменения с начала выдачи CRL;Включение какого-либо расширения в сертификат или CRL производится поусмотрению органа, издающего этот сертификат или CRL.В сертификате или в CRL расширение устанавливается как критическое илинекритическое. Если расширение обозначено как критическое и система, использующаясертификат не признает тип поля расширения сертификата или не выполняет семантикурасширения, тогда такая система будет рассматривать сертификат как неправильный. Еслирасширение обозначено как некритическое система, использующая сертификат, признаетсертификат и обрабатывает расширение. Типы расширения в этом стандарте указывают, чтокритичность, или некритичность может быть решена органом, выдающим сертификат илиCRL.Для всех расширений сертификатов, расширений CRL и расширений элементов CRL,определенных в этом стандарте, не должно быть более одного образца каждого типарасширения в любом сертификате, CRL или элементе CRL соответственно.Данный стандарт содержит в себе три типа объектов: пользователь сертификата,сертифицирующий орган, субъект сертификата (или конечный объект). Каждый объектработает под обязательством двух других объектов, но пользуется ограниченнымигарантиями предложенными ими. Эти обязательства и гарантии определены в политикесертификата.Политика сертификата это документ (обычно на простом и понятном языке). Он можетбыть ссылкой на уникальный идентификатор, который может быть включен в расширениеполитики сертификата, выданного сертифицирующим органом конечному объекту икоторому пользователь сертификата доверяет. Сертификат может быть выдан всогласованности с более чем несколькими политиками. Определение политики и назначениеидентификатора выполняется органом по ведению политики. Набор политик, управляемыхорганом по ведению политики, называется доменом политики. Данный стандарт неназначает политику безопасности.Пользователь сертификата может быть обязанным, согласно с политикой сертификата,использовать открытый ключ органа как надежный указатель или полагаться на сертификат,который включает идентификатор объединенной политики. Сертифицирующий орган можетбыть ограничен в его обязательствах, согласно акту издания сертификата, который включаетидентификатор объединенной политики. Конечный объект может быть ограничен в егообязательствах, согласно акту запроса и принятия сертификата, который включаетидентификатор объединенной политики, и согласно использованию соответствующегозакрытого ключа. Реализации, которые не используют расширения политики сертификата,должны выполнять требуемые ограничения некоторыми другими методами.Для объекта простое объявление соответствия политике, в целом, не удовлетворяеттребованиям доверия других пользователей в структуре. Они требуют некоторых оснований,чтобы доверять, что другие стороны выполняют надежную реализацию политики.15

O′z DSt 1108:2006Сертифицирующий орган может установить ограничения на использование егосертификата, чтобы управлять угрозами, которые появляются в результате выдачисертификата. Например, он может ограничить круг пользователей сертификата, цели длякоторых они могут использовать, его сертификаты и/или типы и размер ущерба, чтобы онвыполнил возмещение в случае ущерба в результате провала на его стороне. Эти вопросыдолжны быть определены в политике сертификата. Добавочная информация для понятияобъектами условия политики может быть включена в расширение политики сертификата вформе спецификатора политики.6.1.2 Кросс сертификацияСертифицирующий орган может быть субъектом сертификата, выданного другим ЦР.В этом случае сертификат называется кросс сертификатом. Сертифицирующий орган,который является субъектом, называется субъектным ЦР. Сертифицирующий орган,который выдает кросс - сертификат, называется промежуточным ЦР (см. рисунок 1). Обасертификата, и кросс - сертификат, и сертификат конечного объекта, могут содержатьрасширение политики сертификата.Гарантии и обязательства распределяются субъектным сертифицирующим органом.Промежуточный Сертифицирующий орган и пользователь сертификата определяютсяполитикой сертификата установленной в кросс - сертификате, согласно которой субъектныйсертифицирующий орган может действовать, и от имени конечного объекта. И гарантии иобязательства, распределенные субъекту сертификата, субъектному ЦР и промежуточномуЦР определяются политикой сертификата, указанной в сертификате конечного объекта,согласно которой промежуточный ЦР может действовать как пользователь сертификата и отимени пользователя сертификата.ПромежуточныйЦРКросс сертификатСубъектный ЦРКонечныйобъектПользовательсертификатаКонечныйобъектПромежуточный ЦР может в свою очередь быть субъектом сертификата, выданногодругим ЦР, поэтому создается путь сертификации длиною больше чем в два сертификата. Засчёт этого при увеличении длины путей сертификации уменьшается достоверность.Требуется контроль обеспечения того, что сертификаты конечного объекта с неприемлемымнизким ассоциированным уровнем достоверности будут отклонены пользователемсертификата. Это часть функции процедуры обработки пути сертификации.В дополнение к ситуации, описанной выше, существуют два случая, которыерассмотрены ниже:а) сертифицирующий орган не использует расширение политики сертификата длясообщения его требований политики пользователю сертификата;b) пользователь сертификата или промежуточный сертифицирующий орган делегируетпривилегии контроля политики следующему органу в пути.В первом случае сертификат вообще не должен содержать расширение политикисертификата. Результатом является набор политик, согласно которым путь имеет16Рисунок 1 - Кросс - сертификация

O′z DSt 1108:2006незначительную силу. В этом случае путь может быть действительным. Пользователисертификата должны быть уверены, что они используют сертификат в соответствии сполитикой органов указанных в пути.Во втором случае пользователь сертификата или промежуточный ЦР должен включатьспециальное значение any-policy в initial policy set или в кросс сертификат. В случае, когдасертификат включает в себя значение any-policy он не должен включать любой другойидентификатор политики сертификата. Идентификатор any-policy не должен иметьассоциированный спецификатор политики.Пользователь сертификата может быть уверенным, что все его обязанностивыражаются в соответствии со стандартом, устанавливаемым индикатором initial-explicitpolicy.Таким образом, только органы, которые используют стандартное расширениеполитики сертификата как их метод успешного выполнения ограничений, признаются в путисертификации и пользователи сертификата не имеют дополнительных обязанностей. Так какорганы также влекут за собой обязанности, когда они действуют, как пользовательсертификата или от имени пользователя сертификата, они могут гарантировать, что все ихобязанности передаются согласно стандартно устанавливаемому значениюrequireExplicitPolicy в кросс сертификате.6.1.3 Преобразование политикиНекоторые пути сертификации могут пересекаться между границами доменовполитики. Гарантия и обязательства, согласно которым выдан кросс сертификат, могут бытьэквивалентными некоторым или всем гарантиям и обязательствам, согласно которымсубъектный сертифицирующий орган выдает сертификаты конечным объектам, несмотря нато, что политика органов, согласно которыми работают два ЦР, может иметь выделенныеразличные уникальные идентификаторы для этих эквивалентных политик. В этом случаепромежуточный сертифицирующий орган может включать расширение преобразованияполитики в кросс сертификат. В расширении схемы политики промежуточныйсертифицирующий орган удостоверяет пользователя сертификата о том, что он будетпродолжать обладать схожими обязательствами, а также он должен продолжать выполнятьсхожие обязательства, несмотря на то, что последующие объекты в пути сертификацииработают в другом домене политики. Промежуточный сертифицирующий орган долженвключать один или несколько преобразований для каждого подмножества политик, согласнокоторым он издает кросс сертификат и он не должен включать в себя преобразования какихлибодругих политик. Если один или несколько политик сертификата, согласно которымработает субъектный сертифицирующий орган, идентичны тем политикам, согласнокоторым работает промежуточный сертифицирующий орган (т.е. он имеет одинаковыйуникальный идентификатор), тогда эти идентификаторы должны быть исключены израсширения преобразования политики, кроме тех, которые включены в расширениеполитики сертификата.Преобразование политики имеет свойство преобразования всех идентификаторовполитики в сертификате на эквивалентную политику идентификатора пути сертификациитакже, как признает пользователя сертификата.Политика не должна быть преобразована в специальное значение или из специальногозначения any-policy.Пользователи сертификата, которые могут определить, что сертификаты выданы вдомене политики, отличающемся от их собственных, не должны быть уверенными, дажеесли что доверенный промежуточный ЦР может установить его политику, чтобы она былаэквивалентной политике пользователей. Промежуточный ЦР может сделать это,установлением initial-policy-mapping-inhibit в процедуре установления пути. Кроме того,промежуточный сертифицирующий орган может сделать похожее определение от имени егопользователя сертификата. Для того чтобы гарантировать, что пользователи сертификатаправильно выполняют это требование, он может установить inhibitPolicyMapping врасширении ограничений политики.17

O′z DSt 1108:20066.1.4 Обработка пути сертификацииПользователь сертификата имеет возможность выбора одной из следующих стратегий:а) он может требовать, что путь сертификации будет удовлетворять как минимумодному из заранее установленных наборов политики; илиb) он может просить сообщение у модуля подтверждения пути о наборе политик, длякоторых действителен путь сертификации.Первая стратегия может быть самой подходящей, когда пользователь сертификатазаранее знает набор политики, которая доступна для использования им.Вторая стратегия может быть самой подходящей, когда пользователь сертификата незнает заранее набора политик, которые доступны для его использования.В первом случае процедура утверждения пути сертификации указывает на путь,который действителен, только если он имеют силу согласно одной или более политик,определенных в initial-policy-set, и он возвращает поднабор initial-policy-set, согласнокоторому путь имеет силу.Во втором случае процедура утверждения пути сертификации может указывать, чтопуть не имеет силу согласно initial-policy-set, но имеет силу согласно расчлененному набору:authorities-constrained-policy-set. Тогда пользователь сертификата должен определить егонамерения использовать сертификат согласно с одной или более политиками сертификата,согласно которым путь имеет силу. Но, устанавливая значение initial-policy-set на any-policy,пользователь сертификата может использовать процедуру для получения действительногорезультата, если путь имеет силу согласно любой политике.6.1.5 Сертификаты выданные самому себеСуществует три обстоятельства, при которых сертифицирующий орган может издаватьсертификат самому себе:а) в качестве удобного метода шифрования его открытого ключа для связи спользователями сертификата и хранения пользователями сертификата;b) для удостоверения использования ключа для подписания сертификата и CRL;c) для замены своих собственных сертификатов, срок которых истек.Эти типы сертификатов называются сертификатами выданными самому себе, и онимогут быть признаны действительными согласно тому факту, что имя издателя и субъекта,представленные в них, являются идентичными. Для утверждения действительности путисертификации сертификаты типа а), выданные самому себе, проверяются открытым ключом,содержащимся в нем, и если они встречаются в пути сертификации, они должны бытьигнорированы.Сертификат типа b), выданный самому себе, может использоваться только какконечный сертификат в пути и должен быть обработан как последний сертификат.Сертификат типа c), выданный самому себе, (также известный как промежуточныйсертификат, выданный самому себе) может использоваться в пути как промежуточныйсертификат. Если сертификаты, выданные самому себе, встречаются в пути, они должныбыть обработаны как промежуточные сертификаты, но со следующим исключением: они недействуют на длину пути во время обработки расширения basicConstraints компонентыpathLenConstraint и значений skip-certificates, связанных с индикаторами policy-mappinginhibit-pendingи explicit-policy-pending.6.2 Расширения информации о ключе и о политике6.2.1 Необходимые условияУстановлены следующие условия, связанные с информацией о ключе и о политике:a) ключевая пара ЦР может обновляться в одинаковые интервалы или при специальныхобстоятельствах. В сертификате необходимо поле для выражения идентификатора открытогоключа, чтобы использовать его для верификации подписи сертификата. Система,18

O′z DSt 1108:2006использующая сертификат, может использовать такие идентификаторы при обнаруженииправильного сертификата ЦР для проверки открытого ключа издателя сертификата;b) вообще, субъект сертификата имеет различные открытые ключи и соответственноразличные сертификаты для разных целей, например для цифровой подписи и длясогласования ключей шифрования. Поле сертификата необходимо для способствованияпользователю сертификата при выборе правильного сертификата для данного субъекта дляособых целей или чтобы позволить ЦР ставить условие, что сертифицированный ключможно использовать только в особых целях;c) обновление ключевой пары субъекта производится регулярно или при специальныхобстоятельствах. Необходимо поле в сертификате для сообщения идентификатора, дляопределения различия между открытыми ключами для одинаковых субъектов,используемых в различные моменты времени. Система, использующая сертификат, можетиспользовать такие идентификаторы при обнаружении правильного сертификата;d) закрытый ключ, соответствующий сертифицированному открытому ключу, типичноиспользуется в различных периодах времени, исходя из действительности открытого ключа.Период использования для подписывающего закрытого ключа короче, чем дляпроверяющего открытого ключа. Период действительности сертификата указывает напериод, в течение которого может быть использован открытый ключ, для которого необязательно соответствовать периоду использования закрытого ключа. В случае, когдазакрытый ключ скомпрометирован, период использования может быть ограничен, еслисторона, верифицирующая подпись, знает легитимный период использования закрытогоключа. Поэтому существуют условия, дающие возможность указания в сертификате периодаиспользования закрытого ключа;e) из-за того, что сертификат может быть использован в среде, где применяетсямножество политик сертификата, необходимо включить в сертификат информацию ополитике сертификата;f) при кросс-сертификации одной организации со стороны другой иногда могут бытьсоглашения о том, что определенные политики двух организаций могут бытьэквивалентными. Сертификат ЦР должен позволить издателю сертификата указать, что однаиз его собственных политик сертификата эквивалентна политике сертификата другогосубъектного ЦР. Это называется преобразованием политики;g) пользователь системы шифрования или цифровой подписи, который используетсертификаты, определенные в этом стандарте, должен иметь возможность заранееопределить алгоритмы, поддерживаемые другими пользователями.6.2.2 Поля расширения сертификата открытого ключа и расширения CRL6.2.2.1 Расширение идентификатора ключа органаОпределены следующие поля расширения:a) идентификатора ключа органа;b) идентификатора ключа субъекта;c) использования ключа;d) расширенного использования ключа;e) периода использования закрытого ключа;f) политики сертификата;j) преобразования политики.Эти поля расширения используются только как расширения сертификата, заисключением идентификатора ключа органа, который может быть также использован какрасширение CRL. Расширения могут быть использованы и в сертификатах ЦР и всертификатах объекта.Расширение идентификатора ключа органа может быть использовано и как расширениесертификата и как расширение CRL. Оно идентифицирует открытый ключ, используемыйдля проверки подписи на данном сертификате или CRL. Оно даёт возможность отличать19

O′z DSt 1108:2006различные ключи, используемые одним и тем же ЦР. Это поле определяется следующимобразом:authorityKeyIdentifier EXTENSION ::= {SYNTAX AuthorityKeyIdentifierIDENTIFIED BY id-ce-authorityKeyIdentifier }AuthorityKeyIdentifier ::= SEQUENCE {keyIdentifier[0] KeyIdentifier OPTIONAL,authorityCertIssuer[1] GeneralNames OPTIONAL,authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }( WITH COMPONENTS {..., authorityCertIssuer PRESENT,authorityCertSerialNumber PRESENT} |WITH COMPONENTS{..., authorityCertIssuer ABSENT,authorityCertSerialNumber ABSENT} )KeyIdentifier::= OCTET STRINGКлюч может быть установлен определением идентификатора ключа в компонентеkeyIdentifier идентифицированием сертификата для ключа (указанием издателя сертификатав компоненте authorityCertIssuer и серийном номере сертификата в компоненте), илиопределением и идентификатора ключа идентификацией сертификата для ключа. Еслииспользуются обе формы идентификации, тогда издатель сертификата или CRL долженгарантировать, что они совместимы. Идентификатор ключа должен быть уникальным поотношению всех идентификаторов ключей для издающего органа для сертификата или CRL,содержащих расширение. Реализация обработки сертификата, которая поддерживает эторасширение, должна иметь возможность обработать все формы имен в компонентеauthorityCertIssuer.Сертифицирующие органы должны назначать серийные номера сертификата, так чтокаждая пара (издатель, серийный номер сертификата) уникально идентифицировала одинсертификат.Форма keyIdentifier может быть использована для выбора сертификатовсертифицирующего органа при построении пути. Пара authorityCertIssuer иauthoritySerialNumber может быть использована для предоставления преимущественногоправа над другими сертификатами в пути. Это расширение всегда имеет некритическоезначение.6.2.2.2 Расширение идентификатора ключа субъектаЭто поле идентифицирует сертифицируемый открытый ключ. Оно дает возможностьразличать различные ключи, используемые одним субъектом. Это поле определяетсяследующим образом:subjectKeyIdentifier EXTENSION ::= {SYNTAXSubjectKeyIdentifierIDENTIFIED BY id-ce-subjectKeyIdentifier }SubjectKeyIdentifier ::= KeyIdentifierИдентификатор ключа должен быть уникальным по отношению всех идентификаторовключа для субъекта, вместе с которыми он используется. Это расширение всегда имеетнекритическое значение.6.2.2.3 Расширение использования ключаЭто поле, указывает цели, для которых используется сертифицированный открытыйключ. Это поле определяется следующим образом:keyUsage EXTENSION ::= {SYNTAXKeyUsageIDENTIFIED BY id-ce-keyUsage }KeyUsage ::= BIT STRING {digitalSignature (0),20

O′z DSt 1108:2006nonRepudiation (1),keyEncipherment (2),dataEncipherment (3),keyAgreement (4),keyCertSign (5),cRLSign (6),encipherOnly (7),decipherOnly (8) }Это расширение может быть выбрано издателем сертификата, и оно может бытькритическим или некритическим.6.2.2.4 Расширение расширенного использования ключаЭто поле указывает на цели, для которых может быть использован сертификатоткрытого ключа, в дополнение к (или вместо) основным целям, указанным в полерасширения использования ключа. Это поле определяется следующим образом:extKeyUsage EXTENSION ::= {SYNTAXSEQUENCE SIZE (1..MAX) OF KeyPurposeIdIDENTIFIED BY id-ce-extKeyUsage }KeyPurposeId ::= OBJECT IDENTIFIERЦели использования ключа могут быть определены любой организацией принеобходимости.Это расширение по выбору издателя сертификата может быть критическим илинекритическим.Если это расширение отмечено как критическое, тогда этот сертификат будетиспользован только для одной из указанных целей.Если расширение отмечено как некритическое, тогда это означает цель или целииспользования ключа и может быть использовано для нахождения правильногоключа/сертификата объекта, который имеет множество ключей/ сертификатов. Если эторасширение представлено и система, использующая сертификат, распознает и обрабатываетрасширение типа keyUsage, тогда эта система будет гарантировать, что сертификат будетиспользован только для одной из установленных целей.Если сертификат содержит и критическое поле использования ключа, и критическоеполе расширенного использования ключа, тогда оба поля должны быть обработанынезависимо и сертификат должен быть использован в целях, соответствующих этим полям.Если в сертификате нет цели, соответствующей этим полям, тогда сертификат не долженбыть использован ни в каких целях.6.2.2.5 Расширение периода использования закрытого ключаЭто поле указывает на период использования закрытого ключа, соответствующегосертифицированному открытому ключу. Оно применимо только для ключей ЭЦП. Это полеопределяется следующим образом:privateKeyUsagePeriod EXTENSION ::= {SYNTAXPrivateKeyUsagePeriodIDENTIFIED BY id-ce-privateKeyUsagePeriod }PrivateKeyUsagePeriod ::= SEQUENCE {notBefore [0] GeneralizedTime OPTIONAL,notAfter [1] GeneralizedTime OPTIONAL }( WITH COMPONENTS {..., notBefore PRESENT} |WITH COMPONENTS {..., notAfter PRESENT} )Компонента notBefore указывает дату и время, начиная с которого закрытый ключможет быть использован для подписания. Если компонента notBefore не существует, тогдане существует информации о начале действительного периода использования закрытогоключа.21

O′z DSt 1108:2006Компонента notAfter указывает на дату и время окончания использования закрытогоключа для подписания. Если компонента notAfter не существует, то не имеется информацияоб окончании периода использования закрытого ключа.Это расширение всегда некритическое.6.2.2.6 Расширение политик сертификатаЭто поле перечисляет политики сертификата, признанные издающим ЦР, которыеприменяются к сертификату вместе с дополнительным (необязательным) спецификатороминформации, соответствующим политикам сертификата, приведенным в этом поле. Списокполитик сертификата применяется для определения действительности пути сертификации,как описано в разделе 7. Дополнительный спецификатор информации не используется впроцедуре обработки пути сертификации, но релевантные спецификаторы представляютсякак результат (выходной параметр) этого процесса для приложения, использующегосертификат, для содействия при определении действительно ли путь соответствует дляданной транзакции. Различные политики сертификата могут иметь отношение к различнымприложениям, которые могут использовать сертифицированный ключ. Наличие этогорасширения в сертификате конечного объекта указывает на политику сертификата, длякоторой этот сертификат является действительным. Наличие этого расширения всертификате, изданном одним ЦР для другого ЦР указывает политики сертификата, длякоторых могут быть действительными пути сертификации, содержащие этот сертификат.Это поле определяется следующим образом:certificatePolicies EXTENSION ::= {SYNTAX CertificatePoliciesSyntaxIDENTIFIED BY id-ce-certificatePolicies }CertificatePoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformationPolicyInformation ::= SEQUENCE {policyIdentifierCertPolicyId,policyQualifiersSEQUENCE SIZE (1..MAX) OFPolicyQualifierInfo OPTIONAL }CertPolicyId ::= OBJECT IDENTIFIERPolicyQualifierInfo ::= SEQUENCE {policyQualifierId CERT-POLICY-QUALIFIER.&id({SupportedPolicyQualifiers}),qualifier CERT-POLICY-QUALIFIER.&Qualifier({SupportedPolicyQualifiers}{@policyQualifierId})OPTIONAL }SupportedPolicyQualifiers CERT-POLICY-QUALIFIER ::= { ... }Значение типа PolicyInformation указывает и сообщает о спецификаторе информациидля одной политики сертификата. Компонента policyIdentifier содержит идентификаторполитики сертификата, а компонента policyQualifiers содержит значения спецификатораполитики для данного элемента.Это расширение может быть, по выбору издателя сертификата, критическим илинекритическим.Если расширение отмечено как критическое, то это означает, что сертификат долженбыть использован только в целях и согласно с правилами, подразумеваемыми в одной изустановленных политик сертификата. Правила отдельной политики могут требовать усистемы, использующей сертификат, обработки значения спецификатора отдельнымиметодами.Если расширение отмечено как некритическое, то не обязательно ограничиватьиспользование сертификата в рамках перечисленных политик. Однако, пользовательсертификата может потребовать определенную политику для того, чтобы использоватьсертификат (см. раздел 7). Спецификатор политики по выбору пользователя сертификатаможет быть обработанным или игнорироваться.22

O′z DSt 1108:2006Политики сертификата и типы спецификаторов политики сертификата могут бытьопределены какими-либо организациями по необходимости. ЦР может утверждать любуюполитику, используя идентификатор anyPolicy для того, чтобы можно было использоватьсертификат для всех возможных политик. Из-за необходимости идентификации этогоспециального значения, чтобы применять его, не обращая внимания на приложение илисреду, этот идентификатор объекта определен в этом стандарте. Этот стандарт неустанавливает идентификатор объекта для конкретной политики сертификата. Установлениеидентификатора объекта является обязанностью объекта, который определяет политикусертификата.anyPolicy OBJECT IDENTIFIER ::= { 2 5 29 32 0 }Идентификатор anyPolicy не должен иметь никаких связанных спецификаторовполитики.Следующий класс объекта ASN.1 используется для определения типов спецификаторовполитики сертификата:CERT-POLICY-QUALIFIER ::= CLASS {&id OBJECT IDENTIFIER UNIQUE,&Qualifier OPTIONAL }WITH SYNTAX {POLICY-QUALIFIER-ID &id[QUALIFIER-TYPE &Qualifier] }Определение типа спецификатора политики должно включать:- формулировку семантики возможных значений;- знак идентификатора спецификатора, который может появиться в расширенииполитики сертификата без сопровождающего значения.6.2.2.7 Расширение преобразования политикиЭто поле, которое должно быть использовано только в сертификате ЦР, позволяетиздателю указать, что для целей пользователя пути сертификации, содержащего этотсертификат, одна из политик сертификата издателя может рассматриваться эквивалентнойдругой политике сертификата, используемой в домене субъектного ЦР. Это полеопределяется следующим образом:policyMappings EXTENSION ::= {SYNTAXPolicyMappingsSyntaxIDENTIFIED BY id-ce-policyMappings }PolicyMappingsSyntax::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {issuerDomainPolicy CertPolicyId,subjectDomainPolicy CertPolicyId }Компонента issuerDomainPolicy указывает политику сертификата, которая признаетсяв домене издающего ЦР и может приниматься эквивалентной политике сертификата,указанной в компоненте subjectDomainPolicy, которая представлена в домене субъектногоЦР.Политика не должна преобразовываться к специальному значению anyPolicy.Это расширение может быть по выбору издателя сертификата или критическим илинекритическим. Рекомендуется, чтобы оно было критическим, иначе пользовательсертификата может некорректно интерпретировать условия издающего ЦР.6.3 Расширения информации о субъекте и издателе сертификата6.3.1 Необходимые условияСледующие условия относятся к субъектам сертификата и атрибутам издателясертификата:a) сертификаты должны быть пригодны для использования приложениями, которыеиспользуют различные формы названий, включающие названия электронной почты,23

O′z DSt 1108:2006название домена Интернет, адреса источника/получателя X.400 и названия сторонэлектронного документооборота. Это необходимо чтобы была возможность безопасносвязывать множество названий различных форм названий с субъектом сертификата или сиздателем сертификата или CRL;b) пользователь сертификата может нуждаться в том, чтобы безопасно узнать,надёжную идентифицирующую информацию о субъекте, чтобы быть уверенным, чтосубъект действительно подразумеваемая личность или объект. Например, может бытьнеобходима такая информация как почтовый адрес, положение в корпорации, илифотография. Такая информация может быть легко представлена как атрибуты директории, ноэти атрибуты не обязательная часть различительного имени.6.3.2 Поля сертификата и расширения CRL6.3.2.1 Расширение альтернативного имени субъектаОпределены следующие поля расширений:a) альтернативное имя субъекта;b) альтернативное имя издателя;c) директория атрибутов субъекта.Эти поля должны быть использованы только как расширения сертификата, кромеальтернативного имени издателя, которое также может быть использовано как расширениеCRL. Также как расширение сертификата они могут быть представлены в сертификатесертифицирующего органа или в сертификате конечного объекта.Расширение альтернативного имени субъекта содержит одно или несколькоальтернативных имен, использующих несколько разных форм имен для объекта, которыйограничивается сертифицирующим органом посредством сертифицированного открытогоключа. Это поле определяется следующим образом:subjectAltName EXTENSION ::= {SYNTAX GeneralNamesIDENTIFIED BY id-ce-subjectAltName }GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralNameGeneralName ::= CHOICE {otherName [0] INSTANCE OF OTHER-NAME,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 }OTHER-NAME ::= TYPE-IDENTIFIEREDIPartyName ::= SEQUENCE {nameAssigner [0] DirectoryString {ub-name} OPTIONAL,partyName [1] DirectoryString {ub-name} }Значения в альтернативах типа GeneralName это названия различных форм, которыеопределяются следующим образом:- otherName это название любой формы, определенной как образец OTHER-NAMEкласса информационного объекта;- rfc822Name это адрес электронной почты в Интернете;- dNSName это имя домена в Интернете;- x400Address это адрес источника/получателя;- directoryName это название директории;24

O′z DSt 1108:2006- ediPartyName это название формы, согласованное между связанными партнерамиэлектронного документооборота; компонента nameAssigner идентифицирует орган, которыйназначает уникальное значение имени в компоненте partyName;- uniformResourceIdentifier уникальный идентификатор ресурсов для всемирной сети(WWW);- iPAddress адрес Интернет-протокола, определяемый как двоичнаяпоследовательность;- registeredID идентификатор какого либо зарегистрированного объекта.Для каждой формы имени, использованной в типе GeneralName, будет существоватьсистема регистрации имен, которая будет гарантировать, что любое использованное имяоднозначно идентифицирует один объект и для издателя сертификата, и для пользователясертификата.Это расширение по выбору издателя сертификата может быть либо критическим, либонекритическим. Системе, использующей сертификат, которая поддерживает это расширение,не обязательно иметь возможность обрабатывать все формы имен. Если расширениеотмечено как критическое, то хотя бы одна из существующих форм имени должна бытьопознана и обработана, иначе сертификат будет определен как недействительный. Кромевышеперечисленных ограничений системе, использующей сертификат, позволеноигнорировать любое название с нераспознанной или неподдерживаемой формой имени.Рекомендуется, чтобы предоставленное поле субъекта сертификата, содержащее названиедиректории, которое однозначно идентифицирует субъект, было установлено какнекритическое.Если это расширение представлено и установлено как критическое, поле subject можетсодержать нулевое название (например, последовательность нулей соответствующихопределенному названию), если субъект идентифицирован в этом расширении тольконазванием или названиями.6.3.2.2. Расширение альтернативного имени издателя и расширение директорииатрибутов субъектаЭто поле содержит одно или несколько альтернативных имен, использующихнесколько разных форм имен, для издателя сертификата и CRL. Это поле определяетсяследующим образом:issuerAltName EXTENSION ::= {SYNTAXGeneralNamesIDENTIFIED BY id-ce-issuerAltName }Это расширение по выбору издателя сертификата или CRL может быть критическимили некритическим. Системам, использующим сертификат, которые поддерживают эторасширение, не обязательно иметь возможность обработки всех форм имени. Еслирасширение отмечено как критическое, хотя бы одна из существующих форм имен должнабыть опознана и обработана, иначе сертификат должен быть определен какнедействительный. Кроме вышеперечисленных ограничений системе, использующейсертификат, позволено игнорировать любое имя с нераспознанной или неподдерживаемойформой имени. Рекомендуется, чтобы предоставленное поле издателя сертификата,содержащее название директории, которое однозначно идентифицирует издающий орган,было установлено как некритическое.Расширение директории атрибутов субъекта сообщает любое необходимое значениеатрибута директории для субъекта сертификата. Это поле определяется следующим образом:subjectDirectoryAttributes EXTENSION ::= {SYNTAXAttributesSyntaxIDENTIFIED BY id-ce-subjectDirectoryAttributes }AttributesSyntax ::= SEQUENCE SIZE (1..MAX) OF Attribute25

O′z DSt 1108:2006Это расширение всегда некритическое.В этом расширении представляется открытый ключ, могут также быть представленынекоторые другие расширения.6.4 Расширения ограничения пути сертификации6.4.1 Необходимые условияДля обработки пути сертификации:a) сертификаты конечного объекта должны быть отличны от сертификатов ЦР дляпредотвращения того, чтобы конечные объекты не могли без авторизации объявить себя какЦР. Это также необходимо, чтобы была возможность для ЦР установить лимит на длинупоследующей цепи сертификатов, получаемой из сертифицированных субъектных ЦР;b) для ЦР должна иметься возможность указать ограничения, которые позволяютпользователю сертификата проверять то, что менее доверенные ЦР в пути сертификации (т.е.самые отдаленные ЦР от ЦР, с которого начинается сертификат открытого ключапользователя) не нарушают их доверия, выдавая сертификаты субъектам в несоответствующем пространстве имен. Строгое соблюдение этих ограничений необходимо,чтобы иметь возможность автоматической проверки пользователем сертификата;c) обработка пути сертификации должна быть реализуема в автоматизированном,автономном модуле. Это необходимо, чтобы допустить применение достоверныхпрограммных или аппаратных модулей при выполнении функций обработки путисертификации;d) должна быть возможность реализации обработки пути сертификации независимо отвзаимодействия с локальным пользователем в реальном масштабе времени;e) должна иметься возможность реализации обработки пути сертификации независимоот использования достоверной локальной базы данных информации об описании политики.Необходима некоторая достоверная локальная информация, такая как исходный открытыйключ, для обработки пути сертификации, но количество такой информации должно бытьминимизировано;f) пути сертификации должны действовать в средах, где признаются многочисленныеполитики сертификата. ЦР должен иметь возможность ставить условия ЦР в других доменах,которым он доверяет. Должно поддерживаться формирование цепочки посредствоммногочисленных доменов политик;g) требуется полная гибкость в моделях доверия. Для отдельной организациидостаточна строгая иерархическая модель, но не достаточна, когда учитываются нуждымногочисленных связанных предприятий. Гибкость необходима при выборе первогодоверенного ЦР в пути сертификации. В частности, должна быть возможность требовать,чтобы путь сертификации начинался в локальном домене безопасности в системе открытогоключа пользователя;h) структура присвоения имен не должна быть ограничена необходимостьюиспользования имен в сертификате, т.е. структуры имен директории, учтенных дляорганизаций или географических областей, и имена не должны устанавливаться дляприспособления к требованиям сертифицирующего органа;i) сертифицирующий орган должен иметь возможность запрещать использоватьпреобразование политики и требовать определенных идентификаторов политикисертификата, чтобы представлять в последующих сертификатах в пути сертификации.В любой системе, использующей сертификат, обработка пути сертификации требуетвыбора соответствующего уровня доверия. Этот стандарт определяет функции, которыемогут быть использованы при реализациях, которые требуют приспосабливаемости кспецифическим требованиям доверия. Уровень доверия должен быть соизмерим скоммерческими угрозами. Функции обработки пути сертификации должны быть реализуемыв аппаратном криптографическом модуле или в криптографических средствах, как одна изопций;26

O′z DSt 1108:2006k) ЦР должен иметь возможность предотвращать (приостанавливать) особые значениякакой-либо политики, полученной из обоснованной действительной политики, впоследующих сертификатах пути сертификации.6.4.2 Поля расширения сертификата6.4.2.1 Расширение основных ограниченийОпределены следующие поля расширения:a) основные ограничения;b) ограничение названия;c) ограничения политики;d) запрет какой-либо политики.Эти расширения должны быть использованы только как расширения сертификата.Ограничения в названиях и ограничения политики должны быть использованы только всертификатах ЦР; простые ограничения могут быть также использованы в сертификатахконечного объекта.Поле расширения основных ограничений указывает, что субъект работает как ЦР ссертифицированным открытым ключом, используемым для проверки подписей сертификата.Если это так, то также может быть определено ограничение длины пути сертификации. Этополе определяется следующим образом:basicConstraints EXTENSION ::= {SYNTAXBasicConstraintsSyntaxIDENTIFIED BY id-ce-basicConstraints }BasicConstraintsSyntax ::= SEQUENCE {cABOOLEAN DEFAULT FALSE,pathLenConstraint INTEGER (0..MAX) OPTIONAL }Компонента cA указывает, что сертифицированный открытый ключ может бытьиспользован для проверки подписи сертификата.Компонента pathLenConstraint должна быть представлена, только если cA установленна значении true. Оно показывает максимальное количество сертификатов ЦР, которые могутследовать за этим сертификатом в пути сертификации. Значение 0 означает, что субъектданного сертификата может издавать сертификаты только для конечных объектов, но не дляпоследующих ЦР. Если ни в одном из сертификатов, находящихся в пути сертификации нетполя pathLenConstraint, то в этом случае не существует лимита, ограничивающего длинупути сертификации.Это расширение может быть по выбору издателя сертификата критическим илинекритическим. Рекомендуется, чтобы он был установлен как критический, иначе объект,который не уполномочен быть ЦР, может выдавать сертификаты и система, использующаясертификат, может случайно использовать такой сертификат.Если это расширение представлено и установлено как критическое или установлено какнекритическое, но признано системой использующей сертификат, тогда:- если значение cA не установлено на true, то сертификат открытого ключа не долженбыть использован для проверки подписи сертификата;- если значение cA установлено на true и представлено pathLenConstraint, тогдасистема, использующая сертификат должна проверить, что обрабатываемый путьсертификации согласован со значением pathLenConstraint.Если это расширение не представлено или установлено как некритическое и признаётсясистемой, использующей сертификат, тогда сертификат будет рассматриваться, каксертификат конечного объекта, и не может быть использован для проверки подписисертификата.Для ограничения субъекта сертификата, чтобы он был только конечным объектом, т.е.не ЦР, издатель может включить это поле расширения, содержащее только пустое значениеSEQUENCE.27

O′z DSt 1108:20066.4.2.2. Расширение ограничения названияЭто поле, которое будет использовано только в сертификате ЦР, указывает напространство имен, в которые должны быть помещены все имена субъекта в последующихсертификатах в пути сертификации. Это поле определяется следующим образом:nameConstraints EXTENSION ::= {SYNTAXNameConstraintsSyntaxIDENTIFIED BY id-ce-nameConstraints }NameConstraintsSyntax::= SEQUENCE {permittedSubtrees [0] GeneralSubtrees OPTIONAL,excludedSubtrees [1] GeneralSubtrees OPTIONAL }GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtreeGeneralSubtree ::= SEQUENCE {baseGeneralName,minimum [0] BaseDistance DEFAULT 0,maximum [1] BaseDistance OPTIONAL }BaseDistance ::= INTEGER (0..MAX)Если существуют компоненты permittedSubtrees и excludedSubtrees, то каждая из нихопределяет одно или несколько поддеревьев названий, каждое из которых определяетсяименем корневого поддерева и в пределах того поддерева, область которого ограничиваетсяверхним и/или нижним уровнями. Если представлена компонента permittedSubtrees, из всехсертификатов, изданных субъектным ЦР и последующими ЦР, указанными в путисертификации, допустимыми являются только те сертификаты, которые имеют именасубъекта в пределах этих поддеревьев. Если представлена компонента excludedSubtrees, толюбой сертификат, изданный субъектным ЦР или последующими в пути сертификации ЦР,не допустим, если он имеет имя субъекта в пределах этих поддеревьев. Если обе компонентысуществуют, и пространства имен частично совпадают, то выбирается та часть поддерева,которая имеет преимущество.Формы имен доступны благодаря типу GeneralName, в этом поле могут бытьиспользованы только те формы имен, которые имеют хорошо определенную иерархическуюструктуру. Форма имени directoryName удовлетворяет этому требованию, когда поддеревоимен, использующее эту форму имен, соответствует поддереву DIT. Если расширениеустановлено как критическое и система, использующая сертификат не признает форму имен,использованную в какой либо компоненте base, сертификат должен быть обработан как вслучае появления непризнанного критического расширения. Если расширение установленокак некритическое и система, использующая сертификат, не признает форму имени,использованную в какой либо компоненте base, тогда спецификация этого поддерева можетбыть игнорирована.Когда проверяются имена субъекта сертификата на соответствие с ограничениемимени, некритические расширения альтернативного имени субъекта должны бытьобработаны, а не игнорированы.Поле minimum определяет верхнюю границу области в пределах поддерева. Все имена,чьи конечные компоненты имени выше определенного уровня, не входят в пределы области.Значение minimum равное нулю (значению по умолчанию) соответствует базовому, т.е.наивысшему узлу поддерева. Например, если minimum установлено на 1, тогда поддеревоимен исключает начальный узел, но включает все подчиненные узлы.Поле maximum определяет нижнюю границу области в пределах поддерева. Все имена,чьи конечные компоненты имени ниже определенного уровня, не входят в пределы области.Значение maximum равное нулю соответствует начальному, т.е. верхушке поддерева.Отсутствие компоненты maximum указывает, что не должно быть нижней границы,накладываемой на область в пределах поддерева. Например, если значение maximum равно1 тогда поддерево имен исключает все узлы кроме базового поддерева и егонепосредственных подчиненных.28

O′z DSt 1108:2006Это расширение по выбору издателя может быть критическим или некритическим.Рекомендуется, чтобы оно устанавливалось как критическое, иначе пользовательсертификата может не проверять, что последующий сертификат в пути сертификациирасположен в пространстве имен, сокращенного органом сертификации.Если это расширение представлено и установлено как критическое или какнекритическое, но признано системой, использующей сертификат, тогда система,использующая сертификат, будет проверять обрабатываемый путь сертификации насогласованность со значением в этом расширении.6.4.2.3 Расширение ограничений политикиЭто поле определяет ограничения, которые могут требовать идентификации политикисертификата или запрет политики преобразования для остатка пути сертификации. Это полеопределяется следующим образом:policyConstraints EXTENSION ::= {SYNTAX PolicyConstraintsSyntaxIDENTIFIED BY id-ce-policyConstraints }PolicyConstraintsSyntax ::= SEQUENCE {requireExplicitPolicy [0] SkipCerts OPTIONAL,inhibitPolicyMapping [1] SkipCerts OPTIONAL }SkipCerts ::= INTEGER (0..MAX)Если представлена компонента requireExplicitPolicy и путь сертификации включает всебя сертификат, изданный назначенным ЦР, то необходимо для всех сертификатов в пути врасширении политики сертификата содержать идентификатор допустимой политики.Идентификатор допустимой политики это идентификатор политики сертификата, требуемыйпользователем пути сертификации, идентификатор политики, которого объявленэквивалентным одной из этих политик посредством преобразования политики или any policy.Назначенный ЦР это или ЦР, издающий сертификат, содержащий это расширение (еслизначение requireExplicitPolicy равно 0) или ЦР, который является субъектом последующегосертификата в пути сертификации.Если существует компонента inhibitPolicyMapping, это означает, что во всехсертификатах, начиная от назначенного ЦР в пути сертификации до конца путисертификации, не разрешается преобразование политики. Назначенный ЦР это илисубъектный ЦР сертификата, содержащего это расширение (если значениеinhibitPolicyMapping равно 0), или ЦР, который является субъектом последующегосертификата в пути сертификации.Значение типа SkipCerts указывает количество сертификатов в пути сертификации,которые должны быть пропущены, перед тем как ограничения станут действительными.Это расширение может быть по выбору издателя сертификата критическим илинекритическим. Рекомендуется, чтобы оно устанавливалось, как критическое, в противномслучае пользователь сертификата может некорректно интерпретировать условия соглашенияиздающего ЦР.6.4.2.4 Расширение запрета, какой либо политикиЭто поле определяет ограничение, которое указывает any policy, не рассматриваемоекак точное совпадение для других политик сертификата сертификатов в пути сертификации,начиная с назначенного ЦР. Назначенный ЦР это или субъектный ЦР сертификата,содержащего это расширение (если значение inhibitAnyPolicy равно 0), или ЦР, которыйявляется субъектом последующего сертификата в пути сертификации.inhibitAnyPolicy EXTENSION ::= {SYNTAX SkipCertsIDENTIFIED BY id-ce-inhibitAnyPolicy29

O′z DSt 1108:2006Это расширение может быть по выбору издателя сертификата либо критическим, либонекритическим. Рекомендуется, чтобы оно устанавливалось, как критическое, в противномслучае пользователь сертификата может некорректно интерпретировать условия соглашенияиздающего ЦР.6.5 Расширение базового CRL6.5.1 Необходимые условияСледующие условия относятся к CRL:a) пользователь сертификата должен иметь возможность составить путь CRL, изданныхиздателем CRL или пунктом распределения CRL (см. 5.6), и должен иметь возможностьопределить отсутствующий CRL в последовательности. Поэтому необходимо указыватьпорядковый номер CRL;b) некоторые пользователи CRL могут реагировать на аннулирование, в зависимости отпричины аннулирования. Поэтому существует требование к элементам CRL, чтобы ониуказывали причину аннулирования;c) существует требование к органу, чтобы он имел возможность временноприостановить действительность сертификата и в дальнейшем либо аннулировать, либовосстановить его. Возможные причины для таких действий могут быть:- желание уменьшить обязательства ошибочного аннулирования, когда запрос нааннулирование не аутентифицирован и существует неадекватная информация дляопределения его действительности;- другие правовые необходимости, такие как временное приостановление сертификатаобъекта, ожидающего аудит или расследование;d) для каждого аннулированного сертификата CRL содержит дату, когда былообъявлено аннулирование. Дата аннулирования не достаточна для разрешения некоторыхспоров, так как в худшем случае подписи выданные в течении периода действительностисертификата должны быть рассмотрены как недействительные. Однако, для пользователяможет быть важным, что подписанный документ будет признан как действительный даже,несмотря на то, что ключ, использованный для подписания документа, былскомпрометирован после того как была поставлена подпись. Для облегчения разрешенияэтой проблемы элемент CRL может включать в себя вторую дату, указывающую на то, когдастало известно или подозревалось, что закрытый ключ был скомпрометирован;e) пользователи сертификата должны иметь возможность определить из своих CRLдобавочную информацию, включающую область применения сертификатов, охватываемыхэтим списком (выпиской из извещения об аннулировании);f) издатели должны иметь возможность динамически изменять разбиение CRL иотсылать сертификаты пользователя в новое место для релевантных CRL, если измененоразделение;g) дельта CRL могут быть также доступны для обновления базовой CRL,соответствующей данной дельта CRL. Пользователи сертификата должны иметьвозможность определить из данного CRL доступны ли данные дельта CRL, где онирасположены или когда будет издан следующий дельта CRL.306.5.2 Поля расширения CRL и элементы CRL6.5.2.1 Расширение номера CRLОпределены следующие поля расширения:a) номер CRL;b) код причины;c) код содержащий инструкции;d) область применения CRL;e) ссылка на состояние;f) идентификатор группы CRL;g) упорядоченный список;

O′z DSt 1108:2006h) дельта информация.Номер CRL, область применения CRL, ссылка на состояние, идентификатор потокаCRL, упорядоченный список, дельта информация должны быть использованы только какполе расширения CRL, а другие поля должны быть использованы только как полярасширения элемента CRL.Расширение номера CRL дает монотонно возрастающее последовательное число длякаждого CRL изданного издателем данного CRL посредством директории атрибута органаили, посредством пункта распределения CRL. Оно позволяет пользователю CRL определить,издавались ли раньше эти CRL. Это поле определяется следующим образом:cRLNumber EXTENSION ::= {SYNTAX CRLNumberIDENTIFIED BY id-ce-cRLNumber }CRLNumber ::= INTEGER (0..MAX)Это расширение всегда имеет некритическое значение.6.5.2.2 Расширение кода причиныЭто поле расширения элемента CRL указывает причины аннулирования сертификата.Код причины может быть использован приложениями для принятия решения, основываясьна локальной политике, как реагировать на отложенное аннулирование. Это полеопределяется следующим образом:reasonCode EXTENSION ::= {SYNTAXCRLReasonIDENTIFIED BY id-ce-reasonCode }CRLReason ::= ENUMERATED {unspecified (0),keyCompromise (1),cACompromise (2),affiliationChanged (3),superseded (4),cessationOfOperation (5),certificateHold (6),removeFromCRL (8),privilegeWithdrawn (9),aaCompromise (10) }Следующие значения кода причины указывают на то, почему сертификат быланнулирован:- keyCompromise используется для аннулирования сертификата конечногопользователя; оно указывает на то, что известно, или подозревается, что закрытый ключсубъекта или другие аспекты субъекта, утвержденные в сертификате, скомпрометированы;- cACompromise используется для аннулирования сертификата ЦР; оно указывает нато, что известно, или подозревается, что закрытый ключ субъекта или другие аспектысубъекта, утвержденные в сертификате, скомпрометированы;- affiliationChanged указывает, что название субъекта или другая информация всертификате модифицирована, но нет основания для подозрения, что закрытый ключ былскомпрометирован;- superseded указывает на то, что сертификат подменен, но нет основания дляподозрения, что закрытый ключ был скомпрометирован;- cessationOfOperation указывает на то, что сертификат больше не подлежитприменению в целях, для которых он был издан, но нет основания для подозрения, чтозакрытый ключ был скомпрометирован;31

O′z DSt 1108:2006- privilegeWithdrawn указывает на то, что сертификат (открытый ключ или сертификататрибута) был аннулирован потому, что привилегия, содержащаяся в этом сертификате,отменена;- aaCompromise указывает на то, что известно или подозревается, что аспекты атрибутаоргана по присвоению атрибутов, утвержденные в сертификате атрибута,скомпрометированы.Сертификат может быть помещен на хранение, изданием элемента CRL с кодомпричины certificateHold. Извещение о хранении сертификата может включать необязательный код инструкции хранения для сообщения о добавочной информациипользователю сертификата (см. 6.5.2.3).Код причины removeFromCRL предназначен только для использования в дельта- CRLи указывает, что существующий элемент CRL должен быть удален из-за окончания срокадействия сертификата или из-за выхода из хранения.6.5.2.3 Расширение кода содержащего инструкцииЭто поле расширения элемента CRL предусматривает включение зарегистрированногоидентификатора инструкций для указания действия, предпринимаемого при обнаружениисертификата, находящегося на хранении. Оно применимо только в элементах, имеющих кодпричины certificateHold. Это поле определяется следующим образом:holdInstructionCode EXTENSION ::= {SYNTAXHoldInstructionIDENTIFIED BY id-ce-instructionCode }HoldInstruction ::= OBJECT IDENTIFIERЭто расширение всегда является некритическим. В данном стандарте не определяютсястандартные коды, содержащие инструкции.Примерами инструкций могут быть сообщения со следующим содержанием«пожалуйста, свяжитесь с ЦР» или «восстановить признак пользователя».6.5.2.4 Расширение области применения CRLОбласть применения CRL указывается в этом расширении. Если представляется полерасширения, то оно должно быть критическим чтобы предотвратить подмену CRLприложением, которое не поддерживает поле расширения.Это расширение может быть использовано для предоставления сообщения об областиприменения различных типов CRL, включающих:- простые CRL, которые предоставляют информацию об аннулировании сертификатов,выданных одним органом;- косвенные CRL, которые предоставляют информацию об аннулированиисертификатов выданных различными органами;- дельта CRL, которые обновляют прежде изданную информацию об аннулировании;- косвенные дельта CRL, которые предоставляют информацию об аннулировании,которая обновляет несколько базовых CRL, выданных одним или несколькими органами.crlScope EXTENSION ::= {SYNTAX CRLScopeSyntaxIDENTIFIED BY id-ce-cRLScope }CRLScopeSyntax ::= SEQUENCE SIZE (1..MAX) OF PerAuthorityScopePerAuthorityScope ::= SEQUENCE {authorityName [0] GeneralName OPTIONAL,distributionPoint [1] DistributionPointName OPTIONAL,onlyContains [2] OnlyCertificateTypes OPTIONAL,onlySomeReasons [4] ReasonFlags OPTIONAL,serialNumberRange [5] NumberRange OPTIONAL,subjectKeyIdRange [6] NumberRange OPTIONAL,nameSubtrees [7] GeneralNames OPTIONAL,32

O′z DSt 1108:2006baseRevocationInfo [9] BaseRevocationInfo OPTIONAL}OnlyCertificateTypes ::= BIT STRING {user (0),authority (1),attribute (2) }NumberRange ::= SEQUENCE {startingNumber [0] INTEGER OPTIONAL,endingNumber [1] INTEGER OPTIONAL,modulus INTEGER OPTIONAL }BaseRevocationInfo ::= SEQUENCE {cRLStreamIdentifier [0] CRLStreamIdentifier OPTIONAL,cRLNumber [1] CRLNumber,baseThisUpdate [2] GeneralizedTime }Если CRL это косвенный CRL, который предоставляет информацию о статусеаннулирования для нескольких органов, то расширение будет включать несколькоконструкций PerAuthorityScope, один или несколько для каждого органа, для которыхвключена информация об аннулировании. Каждый экземпляр PerAuthorityScope, которыйсвязан с органом, отличающимся от того, который издает CRL, должен содержатькомпоненту authorityName.Если CRL является dCRL, который предоставляет информацию о статусе дельтааннулирования для множества базовых CRL, выданных одним органом, то расширениевключает множество конструкций PerAuthorityScope, одну для каждых базовых CRL, длякоторых dCRL обеспечивает обновления. Если представлено значение компонентыauthorityName, несмотря на то, что существует множество экземпляров конструкцийPerAuthorityScope, оно будет одинаковым для всех случаев.Если CRL это косвенный dCRL, который предоставляет информацию о статусе дельтааннулирования для множества базовых CRL изданных разными органами, то расширениевключает множество конструкций PerAuthorityScope, один для каждых базовых CRL, длякоторых dCRL обеспечивает обновления. Каждый экземпляр PerAuthorityScope, которыйсвязан с другим органом, не выдающим этот dCRL, должен включать компонентуauthorityName.Для каждого экземпляра PerAuthorityScope, представляемого в расширении, поляиспользуются следующим образом. В случае косвенных dCRL и косвенных CRL каждыйэкземпляр PerAuthorityScope может содержать различные комбинации этих полей иразличных значений.Если представлено поле authorityName оно указывает на орган, который издалсертификаты, для которых представлена информация об аннулировании. Если это поле невключено, оно по умолчанию указывается в названии издателя CRL.Если представлено поле distributionPoint, оно используется так, как описано врасширении issuingDistributionPoint.Если представлено поле onlyContains оно указывает какой тип(ы) сертификатов CRLсодержит информацию, касающуюся статуса аннулирования. Если это поле отсутствует,CRL содержит информацию о всех типах сертификатов.Если представлено поле onlySomeReasons оно используется, как описано в расширенииissuingDistributionPoint.Если представлен элемент serialNumberRange, то он используется следующимобразом. Когда представлено значение модуля, серийный номер, перед проверкой дляпредставления в области уменьшается по модулю данного значения. Затем сертификат суменьшенным серийным номером рассматривается в пределах CRL если он:- эквивалентен или больше чем startingNumber и меньше чем endingNumber, где ониоба представлены;33

O′z DSt 1108:2006- эквивалентен или больше чем startingNumber, когда представляетсяendingNumber;- меньше чем endingNumber, когда не представлен startingNumber.Если представлен элемент subjectKeyIdRange, то он интерпретируется одинаково сserialNumberRange за исключением того, что использованный номер это значение врасширении subjectKeyIdentifier сертификата. Кодирование по DER (Distinguished EncodingRiles - поднабор правил кодирования) BIT STRING (пропускающие тег, отрезок и неиспользуемые биты октета) будет рассматриваться как значение кодирования по DERINTEGER. Если в BIT STRING установлен на 0, тогда добавочный нулевой октет долженбыть представлен так, чтобы обеспечить положительный результат шифрования INTEGER,например:03 02 01 f7преобразуются в02 02 00 f7Если представлено поле nameSubtrees, оно использует одинаковые соглашения дляформ имен как определено в расширении nameConstraints.Если представлено поле baseRevocationInfo, оно указывает, что CRL это dCRL,касающийся сертификатов предусмотренных конструкцией PerAuthorityScope.Использование расширения crlScope для определения CRL как dCRL отличается отиспользования расширения deltaCRLIdentifier следующим. В случае crlScope информация вкомпоненте baseRevocationInfo указывает на время, начиная с которого CRL, содержащийэто расширение обеспечивает обновления. Хотя это выполняется посредством ссылки к CRL,сосланный CRL может быть полным для области применения или не может быть, в то времякак расширение deltaCRLIdentifier ссылается на изданный CRL, который полный дляобласти применения. Однако, обновленная, содержащая расширение crlScope, информацияпредставленная в dCRL это обновления для информации об аннулировании. Этот механизмболее гибкий, чем расширение deltaCRLIndicator, поскольку пользователи могут создаватьполные CRL локально, и они (CRL) будут сконструированы, основываясь на времени, а не наиздании базовых CRL, которые полные для применимой области. В обоих случаях, dCRLвсегда предоставляет обновления для статуса аннулирования для сертификатов в даннойобласти, начиная с определенного момента.В зависимости от политики ответственного органа, перед тем как будет опубликованновый базовый CRL, могут быть опубликованы несколько dCRL. Если dCRL содержатрасширение crlScope, указывающее их точку основания, тогда не обязательно указыватьcRLNumber в поле BaseRevocationInfo самого последнего изданного базового CRL.Однако, cRLNumber, указанный в поле BaseRevocationInfo dCRL, будет меньше или равноcRLNumber самого последнего изданного CRL, который полный для области применения.Заметим, что расширение issuingDistributionPoint и crlScope могут противоречить другдругу и не предназначаться для использования вместе. Однако, если CRL содержит оба этирасширения, тогда сертификат находится в области CRL, только если он соответствуеткритерию обоих расширений. Если CRL не содержит ни расширенияissuingDistributionPoint, ни расширения crlScope, тогда областью является вся областьоргана и CRL может быть использован для любого сертификата, исходящего из этого органа.Когда система, использующая сертификат, использует CRL, который содержитрасширение crlScope для проверки статуса сертификата, то он должен проверять сертификати интересующий код причины на то, что попадают ли они в пределы области CRL как этоопределено расширением crlScope, следующим образом:a) система, использующая сертификат, должна проверять, что сертификат попадает вобласть, получаемую в результате пересечения областей serialNumberRange,subjectKeyIdRange и nameSubtrees, и, если представлены distributionPoint и onlyContains,то они должны быть совместимы с соответствующей конструкцией PerAuthorityScope;b) если CRL содержит компоненту onlySomeReasons в расширении crlScope, тогдасистема, использующая сертификат, должна проверять, что коды причины, охватываемые34

O′z DSt 1108:2006этим CRL, соответствуют целям приложения. Если нет, то могут быть востребованыдополнительные CRL. Заметим, что если CRL содержит оба расширения crlScope иissuingDistributionPoint, и оба содержат компоненту onlySomeReasons, тогда только этикоды причины, включенные в компоненту onlySomeReasons обоих расширений,охватываются этим CRL.6.5.2.5 Расширение ссылки на состояниеЭто расширение CRL предназначено для использования в структуре CRL в качествеспособа сообщения информации об уведомлении аннулирования пользователямсертификата. Оно должно быть представлено в структуре CRL, которая сама не содержитуведомления об аннулировании сертификата. Структура CRL, содержащая это расширение,не должна быть использована пользователями сертификата или доверяющими сторонами какисточник уведомления об аннулировании, она должна использоваться скорее как инструментдля обеспечения гарантии того, что используется соответствующая информация обаннулировании.Это расширение служит для обеспечения двух первичных функций:- это расширение представляет механизм для публикации доверенного «списка CRL»,включая всю информацию, относящуюся к ней, для того, чтобы помочь доверяющимсторонам определить имеют ли они достаточно информации об аннулировании. Например,орган может периодически издавать новый достоверный CRL, с относительно высокойчастотой переиздания. Список должен включать время/дату последнего обновления длякаждого ссылаемого CRL. Пользователь сертификата при получении этого списка можетбыстро определить, не устарели ли кэшированные копии CRL. Этим можно устранить многоненужных исправлений CRL. Кроме этого, используя этот механизм, пользователисертификата могут узнать о CRL изданных органом, в течении обычного периодаобновления, таким образом улучшается своевременность системы CRL;- это расширение также предоставляет механизм для переадресации доверяющейстороны от предварительных мест (например, на место указывающее на расширение пунктараспределения CRL или элемент директории издающего органа) в различные места дляполучения информации об аннулировании. Это свойство позволяет органам изменять схемуразделения CRL, которую они используют без конфликтов с существующими сертификатамиили пользователями сертификата. Для достижения этого орган должен включать каждоеновое местонахождение и область CRL, который должен быть найден на этом месте.Доверяющая сторона должна сравнить интересующий сертификат с формулировкамиобласти и следовать по указателю на соответствующее новое местонахождение дляполучения информации об аннулировании, касающейся этого сертификата.Это расширение само по себе является растяжимым и в дальнейшем другие non-CRL,базируемые на схемах аннулирования, могут также указываться, используя это расширение.statusReferrals EXTENSION ::= {SYNTAXStatusReferralsIDENTIFIED BY id-ce-statusReferrals }StatusReferrals ::= SEQUENCE SIZE (1..MAX) OF StatusReferralStatusReferral ::= CHOICE {cRLReferral [0] CRLReferral,otherReferral [1] INSTANCE OF OTHER-REFERRAL}CRLReferral ::= SEQUENCE {issuer [0] GeneralName OPTIONAL,location [1] GeneralName OPTIONAL,deltaRefInfo [2] DeltaRefInfo OPTIONAL,cRLScopeCRLScopeSyntax,lastUpdate [3] GeneralizedTime OPTIONAL,lastChangedCRL [4] GeneralizedTime OPTIONAL}DeltaRefInfo ::= SEQUENCE {35

O′z DSt 1108:2006deltaLocation GeneralName,lastDelta GeneralizedTime OPTIONAL }OTHER-REFERRAL ::= TYPE-IDENTIFIERПоле issuer указывает на объект, который подписывает CRL; по умолчанию это имяиздателя, охватывающего CRL.Поле location представляет информацию о местонахождении, на которое нужноперенаправиться и по умолчанию имеет такое же значение как имя issuer.Поле deltaRefInfo предоставляет необязательное альтернативное местонахождение, изкоторого будет получен dCRL, и необязательное дату предыдущей дельты.Поле cRLScope представляет область применения CRL, которую можно найти всосланном месте.Поле lastUpdate является значением thisUpdate в самом последнем изданномсосланном CRL.Поле lastChangedCRL является значением поля thisUpdate в самом последнемизданном CRL, который имеет изменения в содержании.OTHER-REFERRAL обеспечивает возможность растяжимости других non-CRL,основанных на схемах аннулирования, чтобы в дальнейшем была возможностьприспособления.Это поле всегда установлено как критическое для обеспечения гарантии того, что CRL,содержащий это расширение, преднамеренно установлен системой, использующейсертификат, как источник информации о статусе аннулирования сертификата.Если это расширение представляется и признается системой, использующейсертификат, то эта система не будет использовать CRL как источник информации о статусеаннулирования. Система должна использовать или информацию, содержащуюся в этомрасширении, или другие методы, выходящие за пределы данного стандарта, чтобыопределить место соответствующей информации о статусе аннулирования.Если это расширение представляется и не признано системой, использующейсертификат, то система не будет использовать CRL как источник информации о статусеаннулирования. Система не должна использовать другие методы, выходящие за пределыэтого стандарта.6.5.2.6 Расширение идентификатора группы CRLПоле идентификатор группы CRL используется для идентификации контекста, вкотором номер CRL является уникальным.cRLStreamIdentifier EXTENSION ::= {SYNTAXCRLStreamIdentifierIDENTIFIED BY id-ce-cRLStreamIdentifier }CRLStreamIdentifier ::= INTEGER (0..MAX)Это расширение всегда является некритическим.Каждое значение этого расширения для каждого органа уникально. Идентификаторгруппы CRL объединен с номером CRL, который служит уникальным идентификатором длякаждого CRL, выданного каким либо органом, несмотря на тип CRL.6.5.2.7 Расширение упорядоченного спискаЭто расширение указывает, что последовательность аннулированных сертификатов вполе revokedCertificates CRL расположено либо в возрастающем порядке по серийномуномеру сертификата либо по дате аннулирования. Это поле определяется следующимобразом:orderedList EXTENSION ::= {SYNTAXOrderedListSyntaxIDENTIFIED BY id-ce-orderedList }36

O′z DSt 1108:2006OrderedListSyntax ::= ENUMERATED {ascSerialNum (0),ascRevDate (1) }Это расширение всегда некритическое. Поля расширения выполняют следующиефункции:- ascSerialNum указывает, что последовательность аннулированных сертификатов вCRL в возрастающем порядке серийного номера сертификата, основанного на значениикомпоненты serialNumber каждого элемента в списке;- ascRevDate указывает, что последовательность аннулированных сертификатов вCRL в возрастающем порядке даты аннулирования, основанного на значении компонентыrevocationDate каждого элемента в списке.Если не представлен orderedList, то не существует информации, обеспечивающейупорядочение списка аннулированных сертификатов в CRL.6.5.2.8 Расширение дельта информацииЭто расширение предназначено для использования в CRL, который не является dCRL, ионо используется для указания доверяющим сторонам того dCRL, который такжедействителен для CRL, содержащего это расширение. Это расширение предоставляетместонахождение, на котором могут быть найдены связанные dCRL и время, в которомбудет издан следующий dCRL.deltaInfo EXTENSION ::= {SYNTAXDeltaInformationIDENTIFIED BY id-ce-deltaInfo }DeltaInformation ::= SEQUENCE {deltaLocation GeneralName,nextDeltaGeneralizedTime OPTIONALЭто расширение всегда некритическое.6.6 Расширения пункта распределения CRL и дельта-CRL6.6.1 Необходимые условияТак как списки аннулирования могут быть большими и громоздкими, то необходимопредставлять CRL в частичном (неполном) формате. Необходимы различные решения дляреализаций двух различных типов, которые обрабатывают CRL.Первый тип реализации это реализация на индивидуальной рабочей станции, возможнов прикрепленном криптографическом жетоне. Эти реализации, вероятно, будут иметь,ограниченную способность достоверного хранения. Поэтому необходимо проверить весьCRL для того, чтобы определить его действительность, и после этого смотреть является лисертификат действительным. Если CRL является длинным, то обработка тоже может бытьочень длинной. Расчленение CRL необходимо для того, чтобы устранить эту проблему.Второй тип реализации осуществляется на серверах с высокой производительностью,где осуществляется обработка сообщений больших объемов, например сервер обработкитранзакций. В таких средах CRL обрабатываются в фоновом режиме, где послеудостоверения CRL содержание CRL сохраняется локально в том представлении, в которомускоряется их проверка. Это представление хранится в достоверных хранилищах. Серверутакого типа необходима самая последняя обновленная версия CRL для большого количестваорганов. Так как он уже имеет список прежде аннулированных сертификатов, ему тольконеобходимо извлечь список новых (недавно) аннулированных сертификатов. Этот список,который называется dCRL, будет меньше и требует малых ресурсов для его извлечения иобработки, чем полный список CRL. Поэтому следующие требования относятся и к пунктамраспределения CRL и dCRL:37

O′z DSt 1108:2006a) для того чтобы контролировать размеры CRL, необходимо иметь возможностьназначать подмножества набора всех сертификатов, изданных одним органом для различныхCRL. Это может быть выполнено посредством привязывания каждого сертификата спунктом распределения CRL, который является либо:- элементом директории, чей атрибут CRL будет содержать элемент аннулирования дляэтого сертификата, если он аннулирован;- местонахождение, такое как адрес электронной почты или единый идентификаторресурса Интернета (Internet URI), из которого можно получить соответствующий CRL;b) в целях увеличения производительности, при утверждении действительностисложных сертификатов желательно уменьшить количество CRL, которые необходимопроверить. Например, это может быть выполнено при наличии одной подписи издателя CRLи выделением CRL, содержащих аннулирования со стороны многих органов;c) существует требование для разделения CRL, охватывающих аннулированныесертификаты органа и аннулированные сертификаты конечного объекта. Это способствуетобработке путей сертификации и они могут предполагаться очень короткими (обычнопустыми) так же как CRL для аннулированных сертификатов органа. Для этой целиопределены атрибуты authorityRevocationList и certificateRevocationList. Однако, чтобыобеспечить безопасность посредством этого разделения необходимо иметь индикатор,который является списком при идентификации CRL. Иначе незаконная подмена одногосписка другим может быть не обнаружена;d) необходимо предостережение для неполных CRL (известных как dCRL), которыесодержат только элементы для сертификатов, которые аннулированы с момента изданиябазового CRL;e) для dCRL также необходимо указание даты/времени, после которой список будетсодержать обновления;f) существует требование об указании в сертификате мест, где можно найти самыйновый CRL (например, дельта CRL).6.6.2 Расширения пункта распределения CRL и дельта-CRL6.6.2.1 Расширение пункта распределения CRLОпределены следующие поля расширений:a) пункты распределения CRL;b) издающий пункт распределения;c) издатель сертификата;d) индикатор дельта CRL;e) обновление базы;f) самый новый CRL.Расширения пункта распределения CRL и самого нового CRL должны бытьиспользованы только как расширения сертификата. Расширения, издающего пунктараспределения, индикатора дельта CRL и обновления базы, должны быть использованытолько как расширение CRL. Расширение издателя сертификата должно использоватьсятолько как расширение элемента CRL.Расширение пункта распределения CRL должно использоваться только, какрасширение сертификата, и может быть использовано в сертификатах органа, сертификатахоткрытого ключа конечного объекта и в сертификатах атрибута. Это поле указывает напункты распределения CRL или точки, к которым должен обращаться пользовательсертификата, чтобы убедиться аннулирован ли сертификат. Пользователь сертификата можетдостать CRL из подходящего пункта распределения или у него может быть возможностьдостать текущий полный CRL из элемента директории органа.Это поле определяется следующим образом:cRLDistributionPoints EXTENSION ::= {SYNTAXCRLDistPointsSyntaxIDENTIFIED BY id-ce-cRLDistributionPoints }38

CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPointDistributionPoint ::= 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) }O′z DSt 1108:2006Компонента distributionPoint указывает на место, из которого может быть взят CRL.Если компонента отсутствует, пункт распределения имеет по умолчанию имя издателя CRL.Когда используется альтернатива fullName или когда применяется по умолчанию, имяпункта распределения может иметь множественную форму имен. Одинаковое имя будетпредставлено, по крайней мере, в одной форме имен, в поле distributionPoint расширения,издающего пункта распределения CRL. Системе, использующей сертификат не обязательноиметь возможность обработки всех форм имен. Она может использовать пунктраспределения при условии, если может быть обработана хотя бы одна форма имен. Если неодна из форм имен для пункта распределения не может быть обработана, то система,использующая сертификат, и в этом случае может использовать сертификат, при условии,что реквизиты информации об аннулировании могут быть извлечены из другого источника,например другого пункта распределения или элемента директории органа.Компонента nameRelativeToCRLIssuer может быть использована, только если пунктраспределения CRL назначается названием директории, т.е. непосредственно зависит отназвания директории издателя CRL. В этом случае компонента nameRelativeToCRLIssuerвыражает взаимосвязанные различительные имена, касающиеся имени директории издателяCRL.Компонента reasons указывает причины аннулирования охваченные этим CRL. Еслиэта компонента отсутствует, соответствующий пункт распределения CRL распределяет CRL,который будет содержать элемент для сертификата, если этот сертификат аннулирован несмотря на причины аннулирования. В противном случае значение reasons указывает, какиепричины аннулирования охватываются соответствующим пунктом распределения CRL.Компонента cRLIssuer указывает орган, который издает и подписывает CRL. Если этакомпонента отсутствует, то имя издателя сертификата подразумевает имя издателя CRL.Это расширение может быть по выбору издателя сертификата либо критическим, либонекритическим. В целях совместимости рекомендуется, чтобы это расширение былоотмечено как некритическое.Если это расширение отмечено как критическое, то система, использующая сертификат,не должна использовать сертификат без извлечения и проверки CRL из одного изназначенных пунктов распределения, покрывающего интересующий код причины. Там, гдеиспользуются пункты распространения, для того чтобы распространять информацию о CRLдля всех кодов причины аннулирования и всех сертификатов, изданных ЦР, включаютрасширение cRLDistributionPoints как критическое расширение и ЦР не обязательно такжепубликовать полный CRL в элементах ЦР.39

O′z DSt 1108:2006Если это расширение отмечено как некритическое и система, использующаясертификат не распознает тип поля расширения, то эта система должна использоватьсертификат только если:- она может получить и проверить полный CRL у органа;- проверка аннулирования не требуется согласно с локальной политикой;- проверка аннулирования завершена другими способами.Возможно, что будет иметься несколько CRL для одного сертификата, которые былиизданы более чем одним издателем CRL. Координация этих издателей CRL и издающихорганов решается аспектами политики органа.Значение (смысл) каждого кода причины является таким, как это определено в полекода причины в подразделе 6.5.2.2 данного стандарта.6.6.2.2 Расширение издающего пункта распределенияЭто поле расширения CRL указывает на пункт распределения CRL для отдельного CRLи указывает на то, что CRL ограничен для аннулирования только сертификатов конечныхобъектов, только сертификатов органов или только для ограниченного набора причин. CRLподписывается только ключом издателя CRL – сами пункты распределения не имеют своихпар ключей. Однако, для CRL, которые были распространены через директорию, CRLхранится в элементе пункта распределения CRL, который в свою очередь может и не бытьэлементом директории издателя CRL.Это поле определяется следующим образом:issuingDistributionPoint EXTENSION ::= {SYNTAXIssuingDistPointSyntaxIDENTIFIED BY id-ce-issuingDistributionPoint }IssuingDistPointSyntax ::= SEQUENCE {distributionPoint [0] DistributionPointName OPTIONAL,onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,onlyContainsAuthorityCerts [2] BOOLEAN DEFAULT FALSE,onlySomeReasons [3] ReasonFlags OPTIONAL,indirectCRL [4] BOOLEAN DEFAULT FALSE,onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }Компонента distributionPoint содержит название пункта распределения в одной илиболее чем в одной форме имен. Если это поле отсутствует, CRL будет содержать элементыдля всех аннулированных сертификатов, изданных издателем CRL. После появлениясертификата в CRL, он, может быть, вычеркнут из последующего CRL после истечениясрока сертификата.Если onlyContainsUserCerts имеет значение «true», то CRL содержит толькоаннулирования для сертификатов конечного объекта. Если onlyContainsAuthorityCertsимеет значение «true», то CRL содержит только аннулирования для сертификатов органа.Если представлено onlySomeReasons CRL содержит только установленную причину илипричины, иначе CRL содержит аннулирования для всех причин.Если indirectCRL имеет значение «true», то CRL может содержать извещения обаннулировании от другого издателя CRL.Если onlyContainsAttributeCerts имеет значение «true», то CRL содержитаннулирования для сертификатов атрибута.Следующие правила касаются использования атрибутов для CRL, распределенныхчерез директорию. CRL, который имеет набор onlyContainsAuthorityCerts, будетраспределен посредством атрибута authorityRevocationList взаимодействующего пунктараспределения, или если нет установленного пункта распределения посредством атрибутаauthorityRevocationList элемента издателя CRL. Иначе CRL будет распределен черезатрибут certificateRevocationList взаимодействующего пункта распределения или, если40

O′z DSt 1108:2006пункт распределения не установлен, через атрибут certificateRevocationList элементаиздателя CRL.Это расширение всегда критическое. Пользователь сертификата, который не можетпонять это расширение не может предположить, что сертификат содержит полный списоканнулированных сертификатов идентифицированных органом. CRL, не содержащиекритическое расширение содержат все текущие элементы CRL для издающего органа,включая элементы для всех сертификатов пользователя и органа.6.6.2.3 Расширение издателя сертификатаЭто расширение элемента CRL указывает издателя сертификата, связанного сэлементом в косвенном CRL, т.е. CRL который имеет индикатор indirectCRL,установленный в его расширении издающего пункта распределения. Если это расширение непредставлено в первом элементе косвенного CRL, то издателем сертификата по умолчаниюстановиться издатель CRL. Если это расширение не представлено, то относительнопоследующего элемента в косвенном CRL издатель сертификата для элемента такой же, какдля предшествующего элемента.Это поле определяется следующим образом:certificateIssuer EXTENSION ::= {SYNTAX GeneralNamesIDENTIFIED BY id-ce-certificateIssuer }Это поле всегда критическое. Если система игнорирует это расширение, она не можетправильно определить элементы CRL в сертификатах.6.6.2.4 Расширения указателя дельта CRLПоле индикатора дельта CRL устанавливает CRL, являющийся дельта CRL (dCRL),который обеспечивает обновление для сосланных базовых CRL. Сосланный базовый CRLэто CRL, который точно был издан как CRL, который полный для данной области. CRL,содержащей в себе расширение указателя дельта CRL, содержит обновления к статусуаннулирования сертификата для той же области.Это поле определяется следующим образом:deltaCRLIndicator EXTENSION ::= {SYNTAXBaseCRLNumberIDENTIFIED BY id-ce-deltaCRLIndicator }BaseCRLNumber ::= CRLNumberЗначение типа BaseCRLNumber устанавливает номер CRL базового CRL, который былиспользован как базовый при генерации данного dCRL. Сосланным CRL будет CRL,который является полным для области применения.Это расширение всегда критическое. Пользователь сертификата, который не понимаетиспользование dCRL, не должен использовать CRL содержащий это расширение, в видутого, что CRL может быть не таким полным, как ожидает пользователь.6.6.2.5 Расширение базового обновленияПоле базового обновления существует для использования в dCRL и для установлениядаты/времени, после которой эта дельта обеспечивает обновление для статусааннулирования. Это расширение должно быть использовано только в dCRL, которыйсодержит расширение deltaCRLIndicator. dCRL, который вместо этого расширениясодержит расширение crlScope, не требует этого расширения в качестве поляbaseThisUpdate расширения crlScope, которое может быть использовано в одинаковыхцелях:baseUpdateTime EXTENSION ::= {SYNTAXGeneralizedTimeIDENTIFIED BY id-ce-baseUpdateTime }41

O′z DSt 1108:2006Это расширение всегда некритическое.6.6.2.6 Расширение самого нового CRLЭто расширение используется только, как расширение сертификата и может бытьиспользовано в сертификатах, изданных органу, также как в сертификатах, изданныхпользователю. Это поле указывает CRL, на который пользователь сертификата долженссылаться для получения последней информации об аннулировании (например, dCRL).Это поле определяется следующим образом:freshestCRL EXTENSION ::= {SYNTAXCRLDistPointsSyntaxIDENTIFIED BY id-ce-freshestCRL }Это поле по выбору издателя сертификата может быть либо критическим, либонекритическим. Если это расширение установлено как критическое, система, использующаясертификат, будет использовать сертификат без начального извлечения и проверкипоследнего CRL. Если расширение установлено как некритическое система, использующаясертификат может использовать локальные устройства для определения, требуется липроверка последнего CRL.427 Дельта CRL, имеющий связь с базойДельта CRL (dCRL) содержит в себе или расширение deltaCRLIndicator или crlScopeдля указания базовой информации об аннулировании, т.е. обновляемый этим dCRL.Если в dCRL представлено расширение deltaCRLIndicator, обновляемая базоваяинформация об аннулировании является базовым CRL, сосланным в этом расширении.Базовый CRL, сосланный посредством расширения deltaCRLIndicator, будет являться CRL,который издан как полный для этой области (т.е. это не dCRL изданный самому себе).Если представлено расширение crlScope и оно содержит компонентуbaseRevocationInfo для ссылки на базовую информацию об аннулировании, котораяобновляется, то это ссылка на точный момент времени, начиная с которого dCRLобеспечивает обновление. Компонента baseRevocationInfo, ссылается на CRL, которыйможет или не может быть издан как тот, который является полным для этой области (т.е.сосланный CRL может быть издан только как dCRL). Однако, dCRL, содержащийкомпоненту baseRevocationInfo, обновляет эту информацию об аннулировании, котораяполная для области сосланного CRL к моменту времени, к которому был издан сосланныйCRL. Пользователь сертификата может применить dCRL к CRL, который полный для даннойобласти и который был издан, как только или после ссылки на CRL в dCRL, содержащемкомпоненту baseRevocationInfo.Из-за возможности появления конфликтной информации CRL не содержитодновременно и расширение deltaCRLIndicator и расширение crlScope с компонентойbaseRevocationInfo. CRL может содержать оба расширения и deltaCRLIndicator ирасширения crlScope только если компонента baseRevocationInfo не представлена врасширении crlScope.dCRL также может быть косвенным CRL, в котором он может содержать обновленнуюинформацию об аннулировании, связанную с базовыми CRL, изданными одним или болеечем одним органом. Расширение crlScope должно быть использовано как средствоустановления CRL как косвенного CRL. Расширение crlScope содержит один экземпляркомпоненты PerAuthorityScope для каждого базового CRL, для которого dCRLпредоставляет обновленную информацию.dCRL для сосланной базовой информации об аннулировании точно отражает текущийстатус аннулирования.Извещение об аннулировании сертификата с причиной аннулирования certificateHold,может появиться или в dCRL или в CRL, который полный для данной области. Этот кодпричины предназначен для указания временного аннулирования сертификата, ожидающего

O′z DSt 1108:2006дальнейшее решение о перманентном аннулировании сертификата или восстановления егокак неаннулированного.Извещение об аннулировании сертификата может сначала появиться в dCRL ивозможно, что период действительности сертификата может истечь до того как будет изданследующий CRL, который полный для применимой области. В этом случае, это извещениеоб аннулировании будет включаться во все дальнейшие dCRL до тех пор пока этоизвещение об аннулировании не будет включено, по крайней мере, в один изданный CRL,который полный для данной области.CRL, который в текущее время полон для данной области, может быть создан локальноодним из следующих путей:- извлечением текущего dCRL для данной области и объединением его с изданнымCRL, который полный для данной области, и который имеет cRLNumber больше чем илиравный cRLNumber базового CRL, сосланного в dCRL;- извлечением текущего dCRL для данной области и объединением его с локальносозданным CRL, который полный для данной области, и который был создан с dCRL,который имеет cRLNumber больше чем или равный cRLNumber базового CRL, сосланногов dCRL.8 Процедура обработки пути сертификации8.1 Входные данные обработки пути сертификацииОбработка пути сертификации выполняется в системе, которая должна использоватьоткрытый ключ удаленного конечного объекта, например система, которая проверяетцифровую подпись сгенерированную удаленным объектом. Политики сертификата, базовыеограничения, ограничения имени и расширения ограничений политики предназначены дляспособствования автоматизированию, автономной реализации логики обработки путисертификации.Ниже описана схема процедуры проверки действительности путей сертификации.Реализация будет функционально эквивалентна внешней характеристике, вытекающей изэтой процедуры.Входными данными процедуры обработки пути сертификации являются:a) набор сертификатов, входящих в путь сертификации. Каждый сертификат в путисертификации является уникальным. Путь сертификации, содержащий две или болееодинаковых сертификатов, не является действительным путем сертификации;b) достоверное значение открытого ключа или идентификатора ключа (если ключхранится внутри модуля обработки пути сертификации), предназначенное дляподтверждения первого сертификата в пути сертификации;c) значение initial-policy-set, включающее в себя один или более идентификаторовполитик, указывающих, что любая из этих политик должна быть допустимой дляпользователя сертификата в целях обработки пути сертификации; также этот входнойпараметр может принимать специальное значение any-policy;d) значение индикатора initial-explicit-policy, которое указывает, необходимо лидопустимому идентификатору политики точно показываться в поле расширения политиксертификата во всех сертификатах в пути сертификации;e) значение индикатора initial-policy-mapping-inhibit, которое показывает, является лизапрещенным преобразование политик в пути сертификации;f) значение индикатора initial-inhibit-policy, которое показывает, что если специальноезначение anyPolicy указано в расширении политик сертификата, оно принимаетсяравносильным для какого либо специфического значения политики сертификата вограниченном наборе;g) текущая дата/время.43

O′z DSt 1108:2006Следует заметить, что из-за того, что все, перечисленные выше, входные параметрыявляются индивидуальными входными параметрами для обработки достоверности путисертификации, пользователь сертификата может ограничить доверие (которое быловозложено) к любому данному доверенному открытому ключу для данного набора политиксертификата. Это может быть достигнуто посредством гарантирования того, что данныйоткрытый ключ является входным параметром для обработки только тогда, когда входнойпараметр initial-policy-set включает политику, на основе которой пользователь сертификатадоверяет этому открытому ключу.8.2 Выходные данные обработки пути сертификацииВыходными параметрами обработки являются:a) успешное или неудачное утверждение пути сертификации;b) если утверждение завершено не успешно, код диагностики указывает на причинунеудачной обработки;c) набор политик, ограничивающих привилегии органов и их связанныхспецификаторов, в соответствии с которыми утверждается путь сертификации, илиспециальное значение any-policy;d) набор политик, ограничивающих привилегии пользователей образованных изпересечения authorities-constrained-policy-set и initial-policy-set;e) explicit-policy-indicator, указывающий на пользователя сертификата или орган в путии требующий, что допустимая политика в каждом сертификате в пути будетидентифицирована;f) детали какого-либо преобразования политики, которые происходят в процессеобработки пути сертификации.8.3 Переменные величины обработки пути сертификацииПроцедура использует следующий набор переменных состояний:a) authorities-constrained-policy-set: Таблица идентификаторов и спецификаторовполитики из пути сертификации (ряды представляют политики, их спецификаторы иисторию преобразования, а столбцы, представляют сертификаты в пути сертификации);b) permitted-subtrees: Набор спецификаций поддерева определяющих поддеревья, вкоторых все названия субъектов в последующих сертификатах в пути сертификации должныбыть опущены или могут принимать специальное значение unbounded;c) excluded-subtrees: Набор (возможно пустой) спецификаций поддерева, определяющихподдеревья, в которых нет названия субъекта, который может быть опущен в последующемсертификате в пути сертификации;d) explicit-policy-indicator: Указывает на то, что должна ли быть допустимая политикаидентифицированной в каждом сертификате в пути;e) path depth: Целое число эквивалентное более чем одному экземпляру сертификата впути сертификации, для которого обработка была завершена;f) policy-mapping-inhibit-indicator: Указывает на то, что преобразование политикизапрещено.g) inhibit-any-policy-indicator: Указывает на то, что соответствует ли рассматриваемоезначение anyPolicy любой особой политике сертификата.h) pending-constraints: Элементы точной политики ограничения запрет преобразованияполитики и/или запрета какой-либо политики, которые были оговорены, но ещё имеют силу.8.4 Этап инициализацииПроцедура обработки пути сертификации включает в себя этап инициализации,следующий за серией шагов обработки сертификата. Этап инициализации включает:a) запись any-policy в нулевой или первый столбец нулевого ряда таблицы authoritiesconstrained-policyset;b) инициализацию переменной permitted-subtrees на unbounded;44

O′z DSt 1108:2006c) инициализацию переменной excluded-subtrees на пустое множество;d) инициализацию переменной explicit-policy-indicator на значение initial-explicit-policy;e) инициализацию path-depth на path-depth;f) инициализацию policy-mapping-inhibit-indicator на значение initial-policy-mappinginhibit;g) инициализацию inhibit-any-policy-indicator на значение initial-inhibit-policy;h) инициализацию трех индикаторов pending-constraints на исходное положение.8.5 Обработка сертификата8.5.1 Базовая проверка сертификатаКаждый сертификат обрабатывается по очереди, начиная с сертификата, подписанного,используя исходный доверенный открытый ключ. Последний сертификат рассматриваетсякак конечный сертификат; любые другие сертификаты рассматриваются как промежуточные.В сертификате применяются следующие виды проверки:a) проверка того, что подпись подтверждает, что дата действительна, что цепь названийсубъекта сертификата и издателя сертификата правильны и что сертификат неаннулирован;b) если поле расширения базовых ограничений представлено в промежуточномсертификате, проверяется, что представлена компонента cA и установлена на значение«true». Если представлена компонента pathLenConstraint, то проверяется, что текущий путьсертификации не нарушил это ограничение (игнорируя промежуточный сертификатизданный самому себе);c) если расширение политики сертификата не представлено, тогда таблица authoritiesconstrained-policy-setустанавливается на нуль удалением всех рядов из таблицы;d) если расширение политики сертификата представлено, тогда к каждой политике врасширении, отличающемся от anyPolicy, накладываются спецификаторы, связанные с P длякаждого ряда в таблице authorities-constrainedpolicy-set, чей элемент столбца [path-depth]содержит значение P. Если в таблице authorities-constrained-policy-set нет ряда, содержащегозначение P в его элементе столбца [path-depth], но значение в authoritiesconstrained-policyset[0,path-depth] установлено на any-policy, тогда добавляется новый ряд в таблицудублицированием нулевых рядов и записью идентификатора политики P вместе с егоспецификаторами в элементе столбца [path-depth] нового ряда;e) если расширение политики сертификата представлено и не включает значениеanyPolicy или если установлен inhibitany-policy-indicator, тогда удаляется любой ряд, длякоторого входной столбец [path-depth] содержит значение any-policy вместе с любым рядом,для которого элемент столбца [path-depth] не содержит одно из значений в расширенииполитики сертификата;f) если расширение политики сертификата представлено и включает значение anyPolicyи не установлен inhibit-any-policy-indicator, тогда оно стыкует спецификатор политики,связанный с anyPolicy в каждом ряду в таблице authorities-constrained-policy-set, во входномстолбце [path-depth] которого содержится значение any-policy или содержится значениекоторое не появляется в расширении политики сертификата;g) если сертификат не промежуточный сертификат, выданный самому себе, проверяетсято, что название субъекта в пределах пространства названий, установленного значениемpermitted-subtrees, и не в пределах пространства названий установленного значениемexcluded-subtrees.8.5.2 Обработка промежуточного сертификатаСледующие ограничения регистрируют действия для промежуточного сертификата,выполняемые, чтобы правильно установить переменные состояния для обработкипоследующего сертификата:a) если в сертификате представлено расширение nameConstraints с компонентойpermittedSubtrees, то переменная состояния permitted-subtrees устанавливается на45

O′z DSt 1108:2006пересечении с его предыдущем значением и значением, установленным в расширениисертификата;b) если в сертификате представлено расширение nameConstraints с компонентойexcludedSubtrees, то переменная состояния excluded-subtrees устанавливается вместе с егопредыдущим значением и значением, установленным в расширении сертификата;c) если policy-mapping-inhibit-indicator установлен, то:- обработка расширения преобразования политики для каждого преобразования,установленного в расширении, выполняется определением всех рядов в таблице authoritiesconstrained-policy-set,элементы столбца [path-depth] которого эквивалентны значениюдоменной политики издателя в расширении;d) если policy-mapping-inhibit-indicator не установлен, то процесс преобразованиярасширения политик для каждого преобразования, установленного в расширении,выполняется определением всех рядов в таблице authorities-constrained-policy-set, чейэлемент столбца [path-depth], эквивалентный значению доменной политики издателя врасширении. Элемент столбца [path-depth] записывает значение доменной политикисубъекта из расширения в элемент столбца [path-depth+1] того же ряда. Если расширениеотображает доменную политику издателя на более чем одну политику домена субъекта,тогда поврежденный ряд копируется и в каждый ряд добавляется новый элемент. Еслизначение в authorities-constrained-policy-set[0, path-depth] установлено на any-policy, тогдакаждый идентификатор доменной политики издателя записывается из расширенияпреобразования политики в столбец [path-depth] и записывает значение доменной политикисубъекта из расширения в элемент столбца [path-depth+1] того же ряда.Если индикатор policy-mapping-inhibit-pending установлен и сертификат не выдансамому себе уменьшается значение соответствующего skip-certificates и, если это значениеобнуляется, устанавливается индикатор policy-mapping-inhibit-indicator.Если в сертификате представлено ограничение inhibitPolicyMapping, то выполняетсяследующее. Для значения SkipCerts равного 0, устанавливается policy-mapping-inhibitindicator.Для любых других значений устанавливается индикатор policy-mapping-inhibitpendingи устанавливается соответствующее значение, меньшее значения SkipCerts ипредыдущего значения skip-certificates (если индикатор policy-mapping-inhibit-pending ужебыл установлен);e) для любого ряда, измененного одним из двух шагов, либо c) или d) приведенныхвыше (и каждый ряд в случае, когда в сертификате представлено расширенияпреобразования), идентификатор политики записывается из столбца [path-depth] в столбец[pathdepth+1] этого ряда;f) если не установлен inhibit-any-policy-indicator, то:- если индикатор inhibit-any-policy-pending установлен и сертификат не выдан самомусебе, уменьшается значение соответствующего skip-certificates и если это значениеобнуляется, то устанавливается индикатор policy-mapping-inhibit-indicator;- если в сертификате представлено ограничение inhibitAnyPolicy, то выполняетсяследующее. Для значения SkipCerts равного 0 устанавливается inhibit-any-policy-indicator.Для любых других значений SkipCerts устанавливается индикатор policy-mapping-inhibitpendingи устанавливается соответствующее значение skip-certificates меньшее значенияSkipCerts и предыдущего значения skip-certificates (если индикатор inhibit-any-policy-pendingуже был установлен);g) увеличивается [path-depth].8.5.3 Обработка индикатора точной политикиДля всех сертификатов выполняются следующие действия:а) если не установлен explicit-policy-indicator:- если установлен индикатор explicit-policy-indicator и сертификат не являетсяпромежуточным сертификатом, выданным самому себе, то увеличивается соответствующее46

O′z DSt 1108:2006значение skip-certificates и если это значение обнуляется, то устанавливается индикаторexplicit-policy-indicator;- если в сертификате представлено ограничение requireExplicitPolicy товыполняется следующее. Для значения SkipCerts равного 0 устанавливается индикаторexplicit-policy-indicator. Для любых других значений SkipCerts устанавливается индикаторexplicit-policy-pending и устанавливается соответствующее значение skip-certificates, меньшеезначения SkipCerts и предыдущее значение skip-certificates (если индикатор explicit-policypendingуже был установлен);- если представлена компонента requireExplicitPolicy и путь сертификациивключает сертификат, изданный назначенным ЦР, то необходимо, чтобы все сертификаты впути содержали в расширении политик сертификата идентификатор допустимой политики.Идентификатор допустимой политики это: идентификатор политики сертификата,требуемый пользователем пути сертификации, идентификатор политики, который объявленэквивалентным благодаря политике преобразования или any-policy. Назначенныйсертифицирующий орган это либо издатель сертификата ЦР, содержащий это расширение(если значение requireExplicitPolicy равно 0), либо ЦР, который является субъектомпоследующего сертификата в пути сертификации.8.5.4 Завершающая обработкаДля конечного сертификата выполняются следующие действия:Если установлен explicit-policy-indicator проверяется, что таблица authoritiesconstrained-policy-setне пуста. Если какие-либо из вышеупомянутых видов проверки были неудачными, тогда процедура завершается, возвращая сигнал неисправностисоответствующего кода причины explicit-policy-indicator и нулевые значения в userconstrained-policy-setи таблицу authorities-constrained-policy-set.Если не одна из вышеуказанных проверок не была неудачной в конечном сертификате,тогда user-constrained-policy-set будет рассчитан образованием пересечения authoritiesconstrained-policy-setи initial-policy-set. Если authorities-constrained-policy-set [0, path-depth]является any-policy, тогда authorities-constrained-policy-set является any-policy. Иначе,authorities-constrained-policy-set является для каждого ряда в таблице значением самой левойячейки, которая не содержит идентификатор any-policy. Затем процедура завершаетсявозвращением сигнала об успешном завершении вместе с таблицей explicit-policy-indicator,authorities-constrained-policy-set и user-constrained-policy-set. Если пересечение authorityconstrained и user constrained set равно нулю, путь действителен согласно ограничивающейполитике органа, но не совсем подходит для пользователя.9 Схема директории PKI9.1 Классы объекта директории PKI и формы названияЭтот подраздел определяет элементы схемы директории, использованные дляпредставления информации об PKI в директории. Этот подраздел включает определениесоответствующих классов объекта, атрибуты и правила согласования значения атрибута.Классы объекта директории PKI и формы названия используются для представленияобъектов PKI в директории.9.1.1 Класс объекта-пользователя PKIКласс объекта-пользователя PKI используется для определения элементов дляобъектов, которые могут быть субъектом сертификата открытого ключа.pkiUser OBJECT-CLASS ::= {SUBCLASS OF {top}KINDauxiliaryMAY CONTAIN {userCertificate}ID id-oc-pkiUser }47

O′z DSt 1108:20069.1.2 Класс объекта ЦР PKIКласс объекта ЦР PKI используется для определения элементов для объектов, которыедействуют как ЦР.pkiCA OBJECT-CLASS ::= {SUBCLASS OF {top}KINDauxiliaryMAY CONTAIN {cACertificate |certificateRevocationList |authorityRevocationList |crossCertificatePair }IDid-oc-pkiCA}9.1.3 Класс объекта пункта распределения CRL и форма именКласс объекта пункта распределения CRL используется для определения элементов дляобъектов, которые действуют как пункт распределения CRL.cRLDistributionPoint OBJECT-CLASS ::= {SUBCLASS OF { top }KINDstructuralMUST CONTAIN { commonName }MAY CONTAIN { certificateRevocationList |authorityRevocationList |deltaRevocationList }IDid-oc-cRLDistributionPointФорма названия пункта распределения CRL показывает, как могут быть названыэлементы класса объекта cRLDistributionPoint.cRLDistPtNameForm NAME-FORM ::= {NAMEScRLDistributionPointWITH ATTRIBUTES { commonName}IDid-nf-cRLDistPtNameForm9.1.4 Класс объекта дельта CRLКласс объекта дельта CRL используется в определении элементов для объектов,которые владеют списками дельта аннулирования (например, ЦР, Орган по присвоениюатрибутов и т.д.).deltaCRL OBJECT-CLASS ::= {SUBCLASS OF{top}KINDauxiliaryMAY CONTAIN{deltaRevocationList}ID id-oc-deltaCRL }9.1.5 Политики сертификата и класс объекта CPSКласс объекта CPS политики сертификата используется в определении элементов дляобъектов, которые содержат политику сертификата и/или информацию о применениисертификата.cpCps OBJECT-CLASS ::= {SUBCLASS OF{top}KINDauxiliaryMAY CONTAIN {certificatePolicy |certificationPracticeStmt}IDid-oc-cpCps48

O′z DSt 1108:20069.1.6 Класс объекта пути сертификации PKIКласс объекта пути сертификации PKI используется в определении элементов дляобъектов, которые содержат пути PKI. В целом оно используются для связи с элементамиструктурного класса объекта pkiCA.pkiCertPath OBJECT-CLASS ::= {SUBCLASS OF {top}KINDauxiliaryMAY CONTAIN { pkiPath }ID id-oc-pkiCertPath }9.2 Атрибуты директории PKI9.2.1 Пользователь сертификата атрибутаЭтот подраздел содержит определение атрибутов директории, используемых дляхранения информации об элементах PKI в этой директории.Пользователь может получить один или более одного сертификата атрибута от одногоили более одного ЦР. Пользователь должен получить у одного или более одного ЦР типатрибута userCertificate, содержащий сертификаты открытого ключа.userCertificate ATTRIBUTE ::= {WITH SYNTAXCertificateEQUALITY MATCHING RULE certificateExactMatchIDid-at-userCertificate}9.2.2 Сертификат атрибута сертифицирующего органаАтрибут cACertificate элемента директории ЦР используется для хранениясертификатов, изданных самому себе, и сертификатов, изданных этому ЦР другим ЦР,находящимся в той же области, что и данный ЦР. В случае сертификата версии 3 этотсертификат включает в себя расширение basicConstraints со значением cA, установленнымна true. Определение этой области исключительно вопрос локальной политики.cACertificate ATTRIBUTE ::= {WITH SYNTAXCertificateEQUALITY MATCHING RULE certificateExactMatchID id-at-cAcertificate }9.2.3 Атрибут парного кросс сертификатаЭлементы issuedToThisCA атрибута crossCertificatePair элемента директории ЦРдолжны быть использованы для хранения всех видов сертификатов, за исключениемсертификата выданного самому себе, для данного ЦР. Элементы issuedByThisCA атрибутаcrossCertificatePair элементов директории ЦР могут содержать подмножествосертификатов, изданных данным ЦР другим ЦР, но это не обязательно. Если ЦР издаетсертификат другим ЦР и субъектный ЦР не подчиняется издающему ЦР в иерархии, тогдаиздающий ЦР поместит этот сертификат в элемент issuedByThisCA атрибутаcrossCertificatePair его собственных элементов директории. Когда оба элементаissuedToThisCA и issuedByThisCA представлены в одном значении атрибута, названиеиздателя в одном сертификате соответствует названию субъекта в другом и наоборот,открытый ключ в одном сертификате должен допускать проверку цифровой подписи надругих сертификатах и наоборот.Когда представлен элемент issuedByThisCA, значение элемента issuedToThisCA иэлемента issuedByThisCA не должны храниться в одинаковых значениях атрибута; другимисловами, они могут храниться либо в отдельном значении атрибута, либо в двух значенияхатрибута.В случае сертификата версии v.3, они должны содержать расширение basicConstraintsсо значением cA, установленным на true.crossCertificatePair ATTRIBUTE ::= {49

O′z DSt 1108:2006WITH SYNTAXCertificatePairEQUALITY MATCHING RULE certificatePairExactMatchID id-at-crossCertificatePair }CertificatePair ::= SEQUENCE {issuedToThisCA [0] Certificate OPTIONAL,issuedByThisCA [1] Certificate OPTIONAL}(WITH COMPONENTS {…, issuedToThisCA PRESENT} |WITH COMPONENTS {…, issuedByThisCA PRESENT})9.2.4 Атрибут списка аннулированных сертификатовСледующий атрибут содержит список аннулированных сертификатов:certificateRevocationList ATTRIBUTE ::= {WITH SYNTAXCertificateListEQUALITY MATCHING RULE certificateListExactMatchIDid-at-certificateRevocationList9.2.5 Атрибут списка аннулированных сертификатов органаСледующий атрибут содержит список аннулированных сертификатов органа:authorityRevocationList ATTRIBUTE ::= {WITH SYNTAXCertificateListEQUALITY MATCHING RULEcertificateListExactMatchIDid-at-authorityRevocationList9.2.6 Атрибут списка дельта аннулированияСледующий тип атрибута определен для содержания dCRL в элементе директории:deltaRevocationList ATTRIBUTE ::= {WITH SYNTAXCertificateListEQUALITY MATCHING RULE certificateListExactMatchIDid-at-deltaRevocationList9.2.7 Атрибут поддерживаемых алгоритмовАтрибут директории определён для поддержки выбора алгоритма для использованияпри связи с удаленным конечным объектом, используя сертификат, как определено в этомстандарте. Следующий ASN.1 определяет этот (многозначный) атрибут:supportedAlgorithms ATTRIBUTE ::= {WITH SYNTAXSupportedAlgorithmEQUALITY MATCHING RULEalgorithmIdentifierMatchID id-at-supportedAlgorithms }SupportedAlgorithm ::= SEQUENCE {algorithmIdentifierAlgorithmIdentifier,intendedUsage [0] KeyUsage OPTIONAL,intendedCertificatePolicies [1] CertificatePoliciesSyntaxOPTIONAL }Каждое значение многозначного атрибута должно иметь отличие от значенияalgorithmIdentifier. Значение компоненты intendedUsage обеспечивает индикациюпредназначения алгоритма (см. 5.2.2.3). Значение компоненты intendedCertificatePoliciesуказывает политику сертификата, с которым может быть использован идентифицированныйалгоритм.50

O′z DSt 1108:20069.2.8 Атрибут сообщения о применении сертификатаАтрибут certificationPracticeStmt используется для хранения сообщения о применениисертификата органа.certificationPracticeStmt ATTRIBUTE ::= {WITH SYNTAXInfoSyntaxID id-at-certificationPracticeStmt }InfoSyntax ::= CHOICE {content DirectoryString {ub-content},pointer SEQUENCE {nameGeneralNames,hash HASH { HashedPolicyInfo } OPTIONAL } }POLICY ::= TYPE-IDENTIFIERHashedPolicyInfo ::= POLICY.&Type( {Policies} )Policies POLICY ::= {...} – Определяется разработчиками –Если представлен content, то включается полное содержание сообщения о применениисертификата органа.Если представлен pointer, компонента name ссылается на одно или более мест, гдемогут быть расположены копии сообщения о применении сертификата органа. Еслипредставлена компонента hash, то она содержит HASH-содержание сообщения оприменении сертификата, которое должно быть найдено по ссылке. Этот хэш может бытьиспользован для полной проверки сосланного документа.9.2.9 Атрибут политики сертификатаАтрибут certificatePolicy используется для хранения информации о политикесертификата.certificatePolicy ATTRIBUTE ::= {WITH SYNTAXPolicySyntaxID id-at-certificatePolicy }PolicySyntax ::= SEQUENCE {policyIdentifierPolicyID,policySyntaxInfoSyntax}PolicyID ::= CertPolicyIdКомпонента policyIdentifier включает идентификатор объекта, зарегистрированный наоснове отдельной политики сертификата.Если представлена компонента content, то включается полное содержание политикисертификата.Если представлена компонента pointer, то компонента name ссылается на одно илиболее мест, где могут быть расположены копии политики сертификата. Если представленакомпонента hash, она содержит HASH-содержание политики сертификата, которая должнабыть найдена по ссылке. Этот хэш может быть использован для полной проверки сосланногодокумента.9.2.10 Атрибут пути PKIАтрибут пути PKI используется для хранения путей сертификации, каждый из которыхсостоит из кросс-сертификатов.pkiPath ATTRIBUTE ::= {WITH SYNTAX PkiPathID id-at-pkiPath }PkiPath ::= SEQUENCE OF CrossCertificates51

O′z DSt 1108:2006Этот атрибут может быть сохранен в элементе директории ЦР и включает некоторыепути сертификации от данного ЦР к другому ЦР. Если этот атрибут используется, он даетвозможность более эффективно восстанавливать кросс-сертификаты, форма, которых частоиспользуется путями сертификации. По существу, нет точно определенных требований дляиспользования этого атрибута и набора значений, которые хранятся в атрибуте и вероятно непредставляют полный набор последующих путей сертификации для какого-либо данного ЦР.9.3 Правила соответствия директории PKIДанный подраздел стандарта определяет правила соответствия атрибутов типаCertificate, CertificatePair, CertificateList, CertificatePolicy и SupportedAlgorithm,соответственно. Данный подраздел также определяет правила соответствия для облегчениявыбора сертификатов или CRL со специфическими характеристиками по многозначныматрибутам, хранящим множество сертификатов или CRL.9.3.1 Точное соответствие сертификатаПравило точного соответствия сертификата сравнивает на равенство представленногозначения со значением атрибута типа Certificate. Оно уникально выбирает один сертификат.certificateExactMatch MATCHING-RULE ::= {SYNTAXCertificateExactAssertionID id-mr-certificateExactMatch }CertificateExactAssertion ::= SEQUENCE {serialNumber CertificateSerialNumber,issuer Name }Это правило согласования возвращает true, если компоненты в значении атрибутасоответствуют представленному значению.9.3.2 Соответствие сертификатаПравило соответствия сертификата сравнивает представленное значение со значениематрибута типа Certificate. Оно выбирает один или более сертификатов на основе различныххарактеристик.certificateMatch MATCHING-RULE ::= {SYNTAX CertificateAssertionID id-mr-certificateMatch }CertificateAssertion ::= SEQUENCE {serialNumber [0] CertificateSerialNumber OPTIONAL,issuer [1] Name OPTIONAL,subjectKeyIdentifier [2] SubjectKeyIdentifier OPTIONAL,authorityKeyIdentifier [3] AuthorityKeyIdentifier OPTIONAL,certificateValid [4] Time OPTIONAL,privateKeyValid [5] GeneralizedTime OPTIONAL,subjectPublicKeyAlgID [6] OBJECT IDENTIFIER OPTIONAL,keyUsage [7] KeyUsage OPTIONAL,subjectAltName [8] AltNameType OPTIONAL,policy [9] CertPolicySet OPTIONAL,pathToName [10] Name OPTIONAL,subject [11] Name OPTIONAL,nameConstraints [12] NameConstraintsSyntax OPTIONAL}AltNameType ::= CHOICE {builtinNameForm ENUMERATED {rfc822Name (1),dNSName (2),52

O′z DSt 1108:2006x400Address (3),directoryName (4),ediPartyName (5),uniformResourceIdentifier (6),iPAddress (7),registeredId (8) },otherNameForm OBJECT IDENTIFIER }CertPolicySet ::= SEQUENCE SIZE (1..MAX) OF CertPolicyIdЭто правило соответствия возвращает true, если все компоненты, представляемые вданных, соответствуют аналогичным компонентам значения атрибута как приведено ниже:serialNumber соответствует, если значение этой компоненты в значении атрибутаэквивалентно тому, которое приведено в представленном значении;issuer соответствует, если значение этой компоненты в значении атрибутаэквивалентно тому, которое приведено в представленном значении;subjectKeyIdentifier соответствует, если значение этой компоненты в хранимомзначении атрибута эквивалентно тому, которое приведено в представленном значении;соответствия не будет, если хранимое значение атрибута не содержит расширениеидентификатора ключа субъекта;authorityKeyIdentifier соответствует, если значение этой компоненты в хранимомзначении атрибута эквивалентно тому, которое приведено в представленном значении;соответствия не будет, если хранимое значение атрибута не содержит расширениеидентификатора ключа органа или если не все компоненты в представленном значениипредставлены в хранимом значении атрибута;certificateValid соответствует, если представленное значение потеряло силу в течениипериода действительности хранимого значения атрибута;privateKeyValid соответствует, если представленное значение потеряло силу в течениипериода указанного расширением периода использования открытого ключа хранимогозначения атрибута или если нет расширения периода использования открытого ключахранимого значения атрибута;subjectPublicKeyAlgID соответствует, если он эквивалентен компоненте algorithmalgorithmIdentifier компоненты subjectPublicKeyInformation хранимого значения атрибута;keyUsage соответствует, если набор битов в представленном значении такой же, как врасширении использования ключа в хранимом значении атрибута, или если нет расширенияиспользования ключа в хранимом значении атрибута;subjectAltName соответствует, если хранимое значение атрибута содержит расширениеальтернативного имени субъекта с компонентой одинакового типа названия как указано впредставленном значении;policy соответствует, если хотя бы один из представленных элементов CertPolicySetпоявляется в расширении политики сертификата в хранимом значении атрибута или еслипредставленный или хранимый сертификат содержит специальное значение anyPolicy вкомпоненте policy. Соответствия не будет, если в хранимом значении атрибута нетрасширения политики сертификата;pathToName соответствует за исключением сертификата, имеющего расширениеограничивающего название, которое запрещает построение пути сертификации в значениипредставленного названия;subject соответствует, если значение этого компонента в значении атрибутаэквивалентно тому, которое приведено в представленном значении;nameConstraints соответствует, если название субъекта в хранимом значении атрибутав пределах области названия данного значением компоненты permitted-subtreesпредставленных данных и за пределами области названия данного значением компонентыexcluded-subtrees представленных данных.53

O′z DSt 1108:20069.3.3 Точное соответствие пары сертификатовПравило точного соответствия пары сертификатов сравнивает равенствопредставленного значения со значением типа CertificatePair. Оно уникально выбирает однупару кросс-сертификатов.certificatePairExactMatch MATCHING-RULE ::= {SYNTAX CertificatePairExactAssertionID id-mr-certificatePairExactMatch }CertificatePairExactAssertion ::= SEQUENCE {issuedToThisCAAssertion [0] CertificateExactAssertion OPTIONAL,issuedByThisCAAssertion [1] CertificateExactAssertion OPTIONAL }( WITH COMPONENTS {..., issuedToThisCAAssertion PRESENT} |WITH COMPONENTS {..., issuedByThisCAAssertion PRESENT} )Это правило согласования возвращает значение true, если компоненты, которыепредставлены в компонентах issuedToThisCAAssertion и issuedByThisCAAssertionпредставленного значения соответствуют аналогичным компонентам соответствующихкомпонент issuedToThisCA и issuedByThisCA в хранимом значении атрибута.9.3.4 Соответствие пары сертификатовПравило согласования пары сертификатов сравнивает представленное значение созначением типа CertificatePair. Оно выбирает одну или более одной пары кросссертификатовна основе различных характеристик либо пары сертификатов issuedToThisCAлибо issuedByThisCA.certificatePairMatch MATCHING-RULE ::= {SYNTAXCertificatePairAssertionID id-mr-certificatePairMatch }CertificatePairAssertion ::= SEQUENCE {issuedToThisCAAssertion [0] CertificateAssertion OPTIONAL,issuedByThisCAAssertion [1] CertificateAssertion OPTIONAL }( WITH COMPONENTS {..., issuedToThisCAAssertion PRESENT} |WITH COMPONENTS {..., issuedByThisCAAssertion PRESENT} )Это правило согласования возвращает true, если все компоненты, которыепредставлены в компонентах issuedToThisCAAssertion и issuedByThisCAAssertionпредставленного значения, соответствуют аналогичным компонентам соответствующихкомпонент issuedToThisCA и issuedByThisCA в хранимом значении атрибута.9.3.5 Точное соответствие списка сертификатовПравило точного соответствия списка сертификатов сравнивает эквивалентностьпредставленного значения со значением атрибута типа CertificateList. Оно уникальновыбирает один CRL.certificateListExactMatch MATCHING-RULE ::= {SYNTAX CertificateListExactAssertionID id-mr-certificateListExactMatch }CertificateListExactAssertion ::= SEQUENCE {issuerName,thisUpdate Time,distributionPoint DistributionPointName OPTIONAL }Это правило возвращает true, если компоненты в хранимом значении атрибутасоответствуют тем, которое приведены в представленном значении. Если компонентаdistributionPoint представлена, то она совпадает как минимум в одной форме имен.54

O′z DSt 1108:20069.3.6 Соответствие списка сертификатаПравило соответствия списка сертификата сравнивает представленное значение созначением атрибута типа CertificateList. Оно выбирает один или более CRL на основеразличных характеристик.certificateListMatch MATCHING-RULE ::= {SYNTAX CertificateListAssertionID id-mr-certificateListMatch }CertificateListAssertion ::= SEQUENCE {issuer Name OPTIONAL,minCRLNumber [0] CRLNumber OPTIONAL,maxCRLNumber [1] CRLNumber OPTIONAL,reasonFlags ReasonFlags OPTIONAL,dateAndTime Time OPTIONAL,distributionPoint [2] DistributionPointName OPTIONAL,authorityKeyIdentifier [3] AuthorityKeyIdentifier OPTIONAL }Правило согласования возвращает true, если все компоненты, которые представлены впредставленном значении, соответствуют аналогичным компонентам хранимого значенияатрибута:issuer соответствует, если значение этой компоненты в значении атрибутаэквивалентно тому, которое дано в представленном значении;minCRLNumber соответствует, если его значение меньше или эквивалентно значениюв расширении номера CRL хранимого значения атрибута; соответствия не будет, еслихранимое значение атрибута не содержит расширение номера CRL;maxCRLNumber соответствует, если его значение больше чем или эквивалентнозначению в расширении номера CRL хранимого значения атрибута; соответствия не будет,если хранимое значение атрибута не содержит расширение номера CRL;reasonFlags соответствует, если какие либо биты, которые установлены впредставленном значении, также установлены в компонентах расширения издающего пунктараспределения хранимого значения атрибута; соответствие также будет, если хранимоезначение атрибута не содержит reasonFlags в расширении издающего пункта распределенияили если хранимое значение атрибута не содержит расширение издающего пунктараспределения;dateAndTime соответствует, если значение эквивалентно значению или позднеезначения в компоненте thisUpdate хранимого значения атрибута и раньше значениякомпоненты nextUpdate хранимого значения атрибута; соответствия не будет, еслихранимое значение атрибута не содержит компоненты nextUpdate;distributionPoint соответствует, если хранимое значение атрибута содержитрасширение издающего пункта распределения и значение этой компоненты впредставленном значении эквивалентно соответствующему значению, как минимум, в однойформе названия в этом расширении;authorityKeyIdentifier соответствует, если значение этой компоненты в хранимомзначении атрибута эквивалентно тому, которое дано в представленном значении;соответствия не будет, если хранимое значение атрибута не содержит расширениеидентификатора ключа органа или если не все компоненты в представленном значениипредставлены в хранимом значении атрибута.9.3.7 Соответствие идентификатора алгоритмаПравило соответствия идентификатора алгоритма сравнивает равенствопредставленного значения со значением атрибута типа SupportedAlgorithms.algorithmIdentifierMatch MATCHING-RULE ::= {SYNTAX AlgorithmIdentifierID id-mr-algorithmIdentifierMatch }55

O′z DSt 1108:2006Правило соответствия возвращает значение true, если представленное значениеэквивалентно компоненте algorithmIdentifier хранимого значения атрибута.9.3.8 Соответствие политикиПравило соответствия политики сравнивает эквивалентность представленного значениясо значением атрибута типа CertificatePolicy или со значением атрибута типа privPolicy.policyMatch MATCHING-RULE ::= {SYNTAX PolicyIDID id-mr-policyMatch }Это правило соответствия возвращает значение true, если представленное значениеэквивалентно компоненте policyIdentifier хранимого значения атрибута.9.3.9 Соответствие пути PKIПравило соответствия pkiPathMatch сравнивает эквивалентность представленногозначения со значением атрибута типа pkiPath. Система, использующая сертификат, можетиспользовать это правило соответствия для выбора пути, начинающегося с сертификата,выданного со стороны ЦР, который он удостоверяет и заканчивающегося сертификатом,выданным для ЦР, который выдал конечному объекту утвержденный сертификат.pkiPathMatch MATCHING-RULE ::= {SYNTAX PkiPathMatchSyntaxID id-mr-pkiPathMatch }PkiPathMatchSyntax ::= SEQUENCE {firstIssuerName,lastSubject Name }Это правило соответствия возвращает значение true, если значение в компонентеfirstIssuer соответствует аналогичным элементам поля issuer первого сертификата вSEQUENCE в хранимом значении и представленное значение в компоненте lastSubjectсоответствует аналогичным элементам поля subject последнего сертификата в SEQUENCE вхранимом значении. Это правило соответствия возвращает значение FALSE, если оба случаяне удачны.5610 Сертификаты атрибута10.1 Структура сертификата атрибутаСтруктура сертификата атрибута, определенная в данном стандарте, предоставляетоснову, на которой могут быть построены инфрастуктуры управления привилегиями (PMI).Эти инфраструктуры могут поддерживать приложения, такие как управление доступом.Ограничение привилегии для объекта обеспечивается органом посредством структурыцифровых подписанных данных, называемых сертификатом атрибута или посредствомсертификата открытого ключа, содержащего расширение, определенное точно для этой цели.Формат сертификата атрибута, определенный в данном стандарте, включает расширяющийсямеханизм и набор специфических расширений сертификата.Если, по какой-либо причине, орган аннулирует прежде выданный сертификат,пользователи должны знать, что произошло аннулирование, чтобы они не использовали ненадежный сертификат. Списки аннулирования это схема, которая может быть использованадля уведомления пользователей об аннулировании.Система, использующая сертификат атрибута, должна утвердить сертификат доиспользования этого сертификата для приложения. Процедуры выполнения этогоутверждения также определенны в данном стандарте и включают проверку целостностисамого сертификата, его статус аннулирования и его действительность, касающуюся егоиспользования по назначению.

O′z DSt 1108:2006Эта структура включает большое количество необязательных элементов, которыесвойственны только в некоторых средах. Также эта структура может быть использована всредах, где используются не все компоненты определенных моделей, хотя моделиопределяются как полные. Например, существуют среды, где не требуется аннулированиесертификатов атрибута. Делегирование привилегий и использование ролей, которые неуниверсально-применимы, также аспекты данного стандарта.Директория использует сертификаты атрибута для управления доступом к информациидиректории на основе правил.В данном стандарте предоставлены два механизма для ограничения полномочийвладельца атрибута.Сертификаты открытого ключа, используемые в сочетании с услугой аутентификацииобъекта, могут непосредственно предоставить услугу предоставления прав доступа(авторизации), если привилегии ассоциированы с субъектом посредством инструкцийиздающего ЦР. Сертификаты открытого ключа могут содержать расширениеsubjectDirectoryAttirbutes, которое содержит привилегии, ассоциированные с субъектомсертификата открытого ключа. Этот механизм, подходит для ситуаций, где орган, издающийсертификат открытого ключа, также является органом для передачи привилегий, и периоддействительности привилегий соответствует периоду действительности сертификатаоткрытого ключа. Конечные объекты не могут действовать как орган по передачепривилегий. Если какие-нибудь из расширений, определенных в разделе 12 данногостандарта, включены в сертификат открытого ключа, эти расширения применяютсяодинаково для всех привилегий, назначенных в расширении subjectDirectoryAttributesданного сертификата открытого ключа.В общих случаях, привилегии объекта будут иметь жизненный цикл, который несоответствует периоду действительности сертификата открытого ключа. Привилегииобычно имеют меньший жизненный цикл. Орган для назначения привилегий, кроме этого,часто является органом, выдающим сертификат открытого ключа одному и тому же объекту.Использование сертификатов атрибута изданных органом по присвоению атрибутовпредоставляет гибкую инфраструктуру управления привилегиями, которая может бытьустановлена и управляться независимо от PKI. В то же время, существует взаимосвязь междуэтими двумя инфраструктурами, на основе которой PKI используется для установленияподлинности издателей и владельцев в сертификате атрибута.Сертификат атрибута является отдельной структурой, в отличие от сертификатаоткрытого ключа субъекта. Субъект может иметь множество сертификатов атрибута, каждыйиз которых связан со своим сертификатом открытого ключа. Нет такого требования, чтобыодин и тот же орган создавал оба сертификата и сертификат открытого ключа, и сертификататрибута для пользователя. В средах, где различные органы ответственны за изданиесертификата открытого ключа и сертификата атрибута, сертификаты открытого ключа,изданные ЦР, и сертификаты атрибута, изданные органом по присвоению атрибутов (AA)должны быть подписаны, используя различные подписывающие закрытые ключи. В средах,где один объект является и ЦР, издающим сертификат открытого ключа, и органом поприсвоению атрибутов, издающим сертификат атрибута, строго рекомендуется, чтобыиспользовались различные ключи для подписания сертификата атрибута и для подписаниясертификата открытого ключа. Обмен между издающим органом и объектом, получающимсертификат, находится за пределами рассмотрения данного стандарта.Сертификат атрибута определяется следующим образом:AttributeCertificate ::= SIGNED {AttributeCertificateInfo}AttributeCertificateInfo ::= SEQUENCE{versionAttCertVersion, --версия v2holderHolder,issuerAttCertIssuer,signatureAlgorithmIdentifier,57

O′z DSt 1108:2006serialNumberCertificateSerialNumber,attrCertValidityPeriodAttCertValidityPeriod,attributesSEQUENCE OF Attribute,issuerUniqueIDUniqueIdentifier OPTIONAL,extensionsExtensions OPTIONAL}AttCertVersion ::= INTEGER { v2(1) }Holder ::= SEQUENCE{baseCertificateID[0] IssuerSerial OPTIONAL,entityName[1] GeneralNames OPTIONAL,objectDigestInfo[2] ObjectDigestInfo OPTIONAL}ObjectDigestInfo ::= SEQUENCE {digestedObjectType ENUMERATED {publicKey (0),publicKeyCert (1),otherObjectTypes (2) },otherObjectTypeIDOBJECT IDENTIFIER OPTIONAL,digestAlgorithmAlgorithmIdentifier,objectDigest BIT STRING }58AttCertIssuer ::= [0] SEQUENCE {issuerNameGeneralNames OPTIONAL,baseCertificateID [0] IssuerSerial OPTIONAL,objectDigestInfo [1] ObjectDigestInfo OPTIONAL }( WITH COMPONENTS { ..., issuerName PRESENT } |WITH COMPONENTS { ..., baseCertificateID PRESENT } |WITH COMPONENTS { ..., objectDigestInfo PRESENT } )IssuerSerial ::= SEQUENCE {issuer GeneralNames,serial CertificateSerialNumber,issuerUID UniqueIdentifier OPTIONAL }AttCertValidityPeriod ::= SEQUENCE {notBeforeTimeGeneralizedTime,notAfterTime GeneralizedTime }Поле version используется для различия версий сертификатов атрибута. Версиясертификата атрибута, изданного, согласно с синтаксисом, приведенным в этом стандарте,будет v.2.Поле holder сообщает об идентичности владельца сертификата атрибута.Компонента baseCertificateID, если она представлена, то она устанавливаетспецифический сертификат открытого ключа, который необходимо использовать дляустановления идентичности личности этого владельца при утверждении полномочий этимсертификатом атрибута.Компонента entityName, если она представлена, то она устанавливает один илинесколько имен владельца. Если entityName является единственной компонентой, котораясуществует в holder, любой сертификат открытого ключа, который имеет один из этихназваний в качестве субъекта, может быть использован для установления идентичностиличности этого владельца, когда утверждаются привилегии этим сертификатом атрибута.Если существуют обе компоненты и baseCertificateID и entityName, то может бытьиспользован только тот сертификат, который определен с помощью baseCertificateID. Вэтом случае, компонента entityName включается только в качестве инструмента, который

O′z DSt 1108:2006помогает верификатору привилегий определить местонахождение сертификата открытогоключа.Существует риск при использовании одного только GeneralNames для идентификациивладельца, так как оно указывает только на имя владельца. Это не является достаточным,чтобы идентифицировать личность владельца, чтобы выдать привилегии для этоговладельца. Однако, использование имени издателя и серийного номера специфическогосертификата открытого ключа позволяет издателю сертификатов атрибута доверять процессуаутентификации, выполняемому ЦР при издании определенного сертификата открытогоключа. Также некоторые опции в GeneralNames (например, IPAddress) не подходят дляиспользования их при определении названия владельца сертификата атрибута, особеннокогда владелец является ролевым, а не индивидуальным объектом.Компонента objectDigestInfo, если она представлена, то она используетсянепосредственно для установления подлинности владельца. Владелец аутентифицируетсяпосредством сравнения дайджеста соответствующей информации, созданной верификаторомпривилегий с помощью алгоритма, установленным в objectDigestInfo с содержимымobjectDigest. Если они оба одинаковы, пользователь аутентифицируется для утвержденияпривилегий этим сертификатом атрибута.Компонента publicKey будет указываться, когда включается хэш открытого ключаобъекта. Хэширование открытого ключа может не уникально идентифицировать одинсертификат (т.е. идентичное значение ключа может появляться во многих сертификатах).Чтобы связать сертификат атрибута с открытым ключом, хэш вычисляется посредствомобраза этого открытого ключа, который должен быть представлен в сертификате открытогоключа. Точнее, входным параметром хэш алгоритма будет DER кодирование образаSubjectPublicKeyInfo ключа. Следует заметить, что если значение открытого ключа,используемое как входной параметр хэш функции, извлечено из сертификата открытогоключа, тогда возможно в этом случае может быть не достаточным входным параметром дляHASH. Правильный входной параметр для хэширования в этой ситуации включает значениеунаследованных параметров, и поэтому может отличаться от представленного в сертификатеоткрытого ключа SubjectPublicKeyInfo.Компонента publicKeyCert указывается, когда хэширутся сертификат открытогоключа, хэширование считается законченным, когда сертификат открытого ключа полностьюкодируется с помощью DER, включая биты подписи.Компонента otherObjectTypes указывается, когда кроме объектов открытых ключей исертификатов открытых ключей хэшируются и другие объекты (например, объектыпрограммного обеспечения). Идентичность типа объекта может поддерживаться по выбору.Поле issuer сообщает подлинность органа по присвоению атрибутов, который выдалсертификат.- если представлена компонента issuerName, то она указывает на одно или несколькоимен издателя;- если представлена компонента baseCertificateID, то она указывает издателя согласноссылке на определенный сертификат открытого ключа, для которого этот издатель являетсясубъектом;- если приведена компонента objectDigestInfo, то она указывает на издателяпредставлением хэша идентифицируемой информации;Signature указывает на криптографический алгоритм, используемый для вставки ЭЦПсертификата атрибута.serialNumber серийный номер, который уникально идентифицирует сертификататрибута в контексте его издателя.Поле attrCertValidityPeriod сообщает о промежутке времени, в течении которогосертификат атрибута рассматривается как действительный. Оно выражается в форматеGeneralizedTime.59

O′z DSt 1108:2006Поле attributes содержит атрибуты, связанные с владельцем который сертифицируется.В случае дескриптора атрибута сертификатов атрибута эта последовательность атрибутаможет быть пустой.issuerUniqueID может использоваться для идентификации издателя сертификатаатрибута в случае, когда компонента issuer не достаточна.Поле extensions позволяет добавлять новые поля в сертификате атрибута.Структура сертификата атрибута, описанная в этом подразделе, главным образомсосредоточена на модели, в которой привилегии помещаются в сертификаты атрибута.Однако, как упомянуто ранее, расширения сертификата, определенные в данном подразделе,могут быть также помещены в сертификате открытого ключа, используя расширениеsubjectDirectoryAttributes.10.2 Пути сертификата атрибутаСертификаты открытого ключа могут быть необходимы для сообщения путисертификата атрибута (например, для утверждения привилегий внутри протоколаприкладной программы). Следующий тип данных ASN.1 может использоваться дляпредставления пути сертификата атрибута:AttributeCertificationPath ::= SEQUENCE {attributeCertificate AttributeCertificate,acPath SEQUENCE OF ACPathData OPTIONAL }ACPathData ::= SEQUENCE {certificate [0] Certificate OPTIONAL,attributeCertificate [1] AttributeCertificate OPTIONAL }6011 Взаимоотношения органа по присвоению атрибутов, источникаполномочий и сертифицирующего органа11.1 Привилегия в сертификатах атрибутаОрган по присвоению атрибутов и сертифицирующий орган логически (во многихслучаях физически) совершенно независимы. Создание и поддержание идентичности можетбыть (часто должно быть) разделено от PMI. Таким образом, полная PKI, включающая ЦР,может существовать и действовать до установления PMI. Хотя ЦР является источникомполномочий для идентификации в его домене, он не может автоматически являтьсяисточником полномочий для привилегий. Поэтому ЦР не обязательно самому быть органомпо присвоению атрибутов, т.е. ему не обязательно быть ответственным за решение того,какие объекты будут иметь возможность функционирования как органы по присвоениюатрибутов.Источник полномочий это объект, который доверен верификатором полномочий, какобъект с наибольшей ответственностью для назначения набора привилегий. Источникполномочий, когда издает сертификаты другим объектам, является органом по присвоениюатрибутов, в которых устанавливаются привилегии для этих объектов. В некоторых средахнужны ЦР, чтобы обеспечить жесткий контроль над объектами, которые могут действоватькак источник полномочий. Эта структура обеспечивает механизм для поддержания этихтребований. В других средах этот контроль не нужен и механизм для определения объектов,которые могут действовать как источник полномочий, выходит за пределы рассмотренияданного стандарта.Эта структура гибкая и может удовлетворять требования многих типов сред:a) во многих средах привилегии могут быть назначены индивидуальным объектамнепосредственно одним органом по присвоению атрибутов, а именно источникомполномочий;b) другие среды могут требовать поддержания необязательных характеристик ролей,при помощи которых личности получают сертификаты, которые назначают различные роли.Привилегии, связанные с ролями косвенно, назначаются для таких личностей;

O′z DSt 1108:2006c) другая необязательная характеристика данной структуры это поддержаниеделегирования привилегий. Если делегирование выполнено, источник полномочий назначаетпривилегии объекту, которому разрешается также действовать как орган по присвоениюатрибутов и в дальнейшем делегировать привилегии. Делегирование может проходить черезпромежуточные органы по присвоению атрибутов и продолжается до тех пор, поканазначается конечный объект, который не может делегировать эти привилегии.Промежуточные органы по присвоению атрибутов могут или не могут действовать какназначитель привилегий для привилегий, которые они делегируют;d) в некоторых средах некоторые физические объекты могут действовать и как орган поприсвоению атрибутов и как ЦР. Эта двойная логическая роль для одного и того жефизического объекта всегда является случаем, когда привилегия сообщается в расширенииsubjectDirectoryAttributes сертификата открытого ключа. В некоторых средахиндивидуальные физические объекты действуют как ЦР и орган по присвоению атрибутов. Впоследнем случае привилегия назначается, используя сертификаты атрибута вместосертификатов открытого ключа.В то время как сертификаты атрибута указывают на сертификаты открытого ключа дляих издателей и владельцев, PKI используется для установления подлинности владельца(назначителя привилегий) и проверки ЭЦП издателя.Объекты могут получать привилегию в двух случаях:- орган по присвоению атрибутов может односторонне присвоить привилегию объектупосредством создания сертификата атрибута. Этот сертификат может храниться в открытомхранилище и может последовательно быть обработан одним или несколькимиверификаторами привилегий для того, чтобы принять решение об авторизации. Все этоможет произойти без уведомления об этом объекта или без специального действия;- в качестве альтернативы, объект сам может запросить привилегии какого-нибудьОРГАНА ПО ПРИСВОЕНИЮ АТРИБУТОВ. Созданный сертификат может быть возвращен(только) запрашивающему объекту, который точно поддерживает его, когда запрашиваетсядоступ к некоторому защищенному ресурсу.11.2 Привилегия в сертификатах открытого ключаВ некоторых средах привилегии связываются с субъектом посредством применения ЦР.Такие привилегии могут быть помещены непосредственно в сертификаты открытого ключа,а не в издаваемые сертификаты атрибута. В таких случаях привилегии включаются врасширение subjectDirectoryAttributes сертификата открытого ключа.Этот механизм пригоден в тех средах, где одно или несколько из следующих действийявляется действительным:- один и тот же физический объект действует и как ЦР и как орган по присвоениюатрибутов;- продолжительность времени действия привилегии приравнивается кпродолжительности времени действия открытого ключа, включенного в сертификат;- делегирование привилегий не разрешено;- делегирование разрешено, но для одного делегирования, все привилегии всертификате (в расширении subjectDirectoryAttributes) имеют одинаковые параметрыделегирования и все расширения, относящиеся к делегированию, применяются одинаково ковсем привилегиям в сертификате.12 Модели PMI12.1 Общая модель12.1.1 PMI в контексте управления доступомОбщая модель управления привилегиями состоит их трех частей: объект, назначительпривилегий и верификатор привилегий.61

O′z DSt 1108:2006Объект может быть защищаемым ресурсом. К ресурсу, который защищается,обращаются как к объекту. Этот тип объекта имеет методы, которые могут бытьактивизированы (например, объектом может быть межсетевой экран, который имеетобъектный метод “Allow Entry”, или объектом может быть файл в файловой системе,который имеет объектные методы чтения, записи и выполнения).Назначитель привилегий это объект, который владеет определенной привилегией иназначает свои привилегии для применения в определенной ситуации.Верификатор привилегий это объект, который определяет, являются ли достаточныминазначенные привилегии для использования в данной ситуации.Определение успешного/неудачного установления привилегий, выполненноеверификатором привилегий, зависит от следующих четырех аспектов:- привилегий назначителя привилегий;- местной политики привилегий;- текущих переменных сред;- критичности объектного метода.Привилегия владельца привилегий отражает уровень доверия, установленный для него,определяемый издателем сертификата. Эта привилегия инкапсулирована в сертификатахатрибута владельца привилегий (или в расширении subjectDirectoryAttrubute в егосертификате открытого ключа), которые могут быть представлены верификатору привилегийво время запроса, или могут быть распространены другими способами, например черездиректорию. Шифрование выполняется с помощью использования конструкции Attribute,содержащей значения AttributeType и SET OF AttributeValue.Политика привилегий определяет уровень привилегии, который считается достаточнымдля критичности данного объектного метода или контекста использования. Политикапривилегий должна быть защищена в целях целостности и подлинности. Существуетнесколько вариантов для передачи политики. Сущность идеи в том что, политика вдействительности не сообщается вообще, а просто определяется и всегда хранится локальнов среде верификатора привилегий. Другая сущность идеи в том, что некоторые политикиявляются «универсальными» и должны быть переданы и быть известными каждому объектув системе. Схема компоненты для хранения информации политики привилегий в директорииопределена в данном стандарте.Политика привилегий определяет порог на одобрение для данного набора привилегий.То есть, она указывает в точности, когда верификатор привилегий должен выводитьзаключение о том, что представленный набор привилегий является «достаточным» для того,чтобы он мог дать доступ (к запрашиваемому объекту, ресурсу, приложению и т.д.) кназначителю привилегий.Синтаксис определения политики привилегий не стандартизируется даннымстандартом. Для этой цели может быть использован любой синтаксис, включающий чистыйтекст. Независимо от использования синтаксиса для определения политики привилегий,каждый пример политики привилегий должен быть уникально идентифицирован.Идентификаторы объектов используются для этих целей.PrivilegePolicy ::= OBJECT IDENTIFIERКритичность объектного метода, если это предусмотрено, может отражать атрибутыдокумента или запроса, которые необходимо обработать, и эта обработка имеет в качествецели авторизацию или конфиденциальность содержания документа. Критичность объектногометода может быть точно зашифрована в ассоциированной метке безопасности или всертификате атрибута, хранящегося объектным методом, или может быть косвенноинкапсулирована в структуре и содержании ассоциированного объекта данных. Она можетбыть зашифрована одним из многочисленных методов. Альтернативно, это может бытьвыполнено внутри PMI, в сертификате атрибута, ассоциированного с объектным методом.Нет никакой необходимости в связывающих взаимоотношениях между верификаторомпривилегий и каким либо отдельным органом по присвоению атрибутов. В то время, как62

O′z DSt 1108:2006владельцы привилегий могут иметь сертификаты атрибута, изданные большинствомразличных органов по присвоению атрибутов, верификаторы привилегий могут признаватьсертификаты, изданные многочисленными органами по присвоению атрибутов, которые недолжны быть иерархически связанными между собой, для того, чтобы дать доступ копределенному ресурсу.Структура сертификата атрибута может быть использована для управленияпривилегиями различных типов и для множества различных целей.Существует стандартная структура для управления доступом, которая определяетсоответствующий набор соглашений, которые характерны для приложения управлениядоступом.Назначитель привилегий в данном стандарте предполагается в роли «инициатора» вструктуре управления доступом.Верификатор привилегий в данном стандарте предполагается в роли «исполнителяфункции управления доступом».Объектный метод, для которого утверждена привилегия, в данном стандартепредполагает «цель», определенную в структуре управления доступом.Переменные среды в данном стандарте предполагают «информацию, вытекающую изконтекста» в структуре управления доступом.Политика привилегий, рассмотренная в данном стандарте, должна включать «политикууправления доступом» и «правила политики управления доступом», как определено вструктуре управления доступом.Эта модель позволяет PMI быть достаточно равномерно защищенной в существующейсети ресурсов. Верификатор привилегий экранирует все запросы и только те, которыеавторизованы правильно, пропускаются к соответствующему объектному методу.12.1.2 PMI в контексте безотказности от авторстваСуществует стандартная структура для безотказности, которая определяетсоответствующий набор соглашений, которые характерны для безотказности от авторства.Назначитель привилегий в этом стандарте предполагается в роли «признака субъекта»или «автора» в структуре безотказности от авторства.Верификатор привилегий в этом стандарте предполагается в роли «признакапользователя» или «получателя» в структуре безотказности от авторства.Объектный метод, для которого в этом стандарте утверждена привилегия, предполагает«цели» в структуре безотказности от авторства.Переменные среды в этом стандарте предполагают «признак генерированной ипроверенной даты или времени» в структуре безотказности от авторства.Политика привилегий, рассматриваемая в этом стандарте, может включать «политикубезопасности безотказности от авторства» в структуре безотказности от авторства.12.2 Модель управления PMIМодель управления иллюстрирует, как управление влияет на доступ к критичномуобъектному методу. Модель имеет пять компонентов: назначитель привилегий, верификаторпривилегий, объектный метод, политика привилегий и переменные среды (см. рисунок 2).Назначитель привилегий имеет привилегию; объектный метод имеет критичность.Методы, описанные в данном стандарте, дают возможность назначителю привилегийуправлять доступом к объектному методу, в соответствии с политикой привилегий. Ипривилегии и критичность могут быть многозначными параметрами.63

O′z DSt 1108:2006ПеременныесредыПолитикапривилегийВерификаторпривилегийОбъектныйметод(критичность)НазначительпривилегияЗапрос наобслуживаниеРисунок 2 - Модель управления PMIНазначитель привилегий может быть объектом, установленным сертификатомоткрытого ключа.12.3 Модель делегированияВ некоторых средах может быть необходимо делегирование привилегий, однако этонеобязательный аспект структуры и не требуется во всех средах. Модель делегированияимеет четыре компоненты: верификатор привилегий, источник полномочий, другие органыпо присвоению атрибутов и назначитель привилегий (см. рисунок 3).ПрисваиваетпривилегииИсточникполномочийДоверяетОрган по присвоениюатрибутовНазначает привилегии(если авторизован)ВерификаторпривилегийДелегируетпривилегииПредъявляетпривилегииВладелец привилегийконечного объектаРисунок 3 - Модель делегированияТакже как в средах, где делегирование не используется, источник полномочий являетсяисходным издателем сертификатов, который назначает привилегии уполномоченнымвладельцам. Несмотря на это, в этом случае источник полномочий разрешает владельцупривилегий, чтобы тот действовал как орган по присвоению атрибутов и в дальнейшемделегировал эти привилегии другим объектам посредством выдачи сертификатов, которыесодержат такие же привилегии (или их подмножества). Источник полномочий можетналагать ограничения на делегирование. Каждый из этих промежуточных органов поприсвоению атрибутов может разрешать дальнейшее делегирование в сертификатах,которые он издает для более отдаленных владельцев привилегии, чтобы делегированиедальше выполнялось этими владельцами, и эти владельцы также действовали как орган по64

O′z DSt 1108:2006присвоению атрибутов. Делегатор также может ограничивать нижестоящие органы поприсвоению атрибутов.Когда используется делегирование, верификатор привилегий доверяет источникуполномочий делегирование некоторых или всех привилегий владельцу привилегий,некоторые из которых могут в дальнейшем делегировать некоторые или все из этихпривилегий другим владельцам.Верификатор привилегий доверяет источнику полномочий, как органу для данногонабора привилегий, для ресурса. Если сертификат утвердителя привилегий не выдан этимисточником полномочий, тогда верификатор привилегий устанавливает путь делегированиясертификатов с этого утвердителя привилегий к тому источнику полномочий, который выдалсертификат. Утверждение пути делегирования включает проверку того, имеет ли орган поприсвоению атрибутов достаточно привилегий, и был ли правильно уполномочен дляделегирования этих привилегий.Для случая, в котором привилегии сообщаются посредством сертификатов атрибута,путь делегирования отличается от пути утверждения сертификата и используется дляутверждения сертификатов открытого ключа объектов, включенных в процессделегирования. Однако, качество подлинности, предложенное процессом утверждениясертификата открытого ключа, будет соответствовать критичности объектного метода, т.е.будет защищаться.12.4 Модель ролей12.4.1 Атрибут ролиРоли предоставляют средства для косвенного назначения привилегий пользователям.Личности получают сертификаты назначения роли, которые назначают один или более ролейдля них посредством атрибута ролей, входящих в состав сертификата. Определенныепривилегии назначаются названиям ролей посредством сертификатов определения роли, а неиндивидуальным владельцам привилегий посредством сертификата атрибута. Сертификатыназначения роли могут быть сертификатом атрибута или сертификатом открытого ключа.Сертификаты определения роли могут быть сертификатом атрибута, но не сертификатомоткрытого ключа. Если сертификаты определения роли не используются, назначениепривилегии для роли может быть произведено посредством других способов.Возможны все нижеследующие случаи:- любым органом по присвоению атрибутов может быть определено любое количестворолей;- сами роли и участники роли могут быть определены и управляться раздельно,различными органами по присвоению атрибутов;- членство ролей может быть делегированы также, как любые другие привилегии;- ролям могут быть назначены любые подходящие продолжительности жизни.Если сертификат назначения роли это сертификат атрибута, то атрибут role содержитсяв компоненте attributes сертификата атрибута. Если сертификат назначения роли этосертификат открытого ключа, то атрибут role содержится в расширенииsubjectDirectoryAttributes. В последнем случае, любые добавочные привилегии,содержащиеся в сертификате открытого ключа, это привилегии, которые непосредственноназначены субъекту сертификата, а не для роли.Таким образом, назначитель привилегий может предоставить сертификат назначенияроли верификатору привилегий, который наглядно показывает только то, что назначительпривилегий имеет специфическую роль. Верификатор привилегий может знать априори илиможет обнаружить некоторыми другими методами привилегии, связанные с назначеннойролью, чтобы принять решение об удачной/неудачной авторизации. Сертификат,определяющий роль, может быть использован для этой цели.Верификатор привилегий должен иметь согласование определенных привилегий дляроли. Назначение этих привилегий для роли может быть сделано в пределах PMI всертификате определения роли или за пределами PMI. Если привилегии роли утверждены в65

O′z DSt 1108:2006сертификате определения роли, механизмы для сцепления этого сертификата с уместнымсертификатом назначения роли предусмотрено в данном стандарте. Сертификат,определяющий роли, не может быть делегирован другому объекту. Издатель сертификатаназначения роли может не зависеть от издателя сертификата, определяющего роль, и онимогут управляться (утрачивать силу, аннулироваться и т.д.) раздельно. Тот же самыйсертификат (сертификат атрибута или сертификат открытого ключа) может бытьсертификатом назначения роли и заодно содержать назначение других привилегийнепосредственно одной и той же личности. Однако, сертификат определения роли долженбыть отдельным сертификатом.Определение значений для атрибута роли выходит за пределы данного стандарта.role ATTRIBUTE ::= {WITH SYNTAX RoleSyntaxID id-at-role }RoleSyntax ::= SEQUENCE {roleAuthority [0] GeneralNames OPTIONAL,roleName [1] GeneralName }Атрибут привилегий должен быть использован для заполнения поля attributesсертификата назначения роли. Если сертификат назначения роли это сертификат открытогоключа, атрибут должен быть использован для заполнения расширенияsubjectDirectoryAttributes этого сертификата открытого ключа.Если представлен roleAuthority, то он указывает признанный орган, которыйответственный за издание сертификата, определяющего роль.Если указан roleAuthority, и если верификатор привилегий использует сертификатопределения роли для определения привилегий, назначенных для роли, то по крайней мереодно название в roleAuthority должно представляться в поле issuer в этом сертификатеназначения роли. Если верификатор привилегий использовал средство другое, чемсертификат, определяющий роли, для определения привилегий назначенных для роли, тогдамеханизмы для гарантирования того, что привилегии были назначены органом, указанным вэтой компоненте, выходят за пределы данного стандарта.Если отсутствует roleAuthority, идентификация ответственного органа должна бытьопределена другими способами.Компонента roleName идентифицирует роль, которая назначается для владельцасертификата назначения роли, содержащего этот атрибут. Если верификатор привилегийиспользует сертификат определения роли для определения привилегий, назначенных дляэтой роли, то это название роли должно также представляться в поле holder сертификата,определяющего роль.13 Расширения сертификата для управления привилегиями13.1 Базовое расширение управления привилегиями13.1.1 Необходимые условияСледующие расширения сертификата могут быть включены в сертификат в целяхуправления привилегиями. Вместе с определением самих расширений, так же предоставленыправила для типов сертификата, в которых могут быть представлены эти расширения.За исключением расширения идентификатора источника полномочий, любые израсширений, которые могут быть включены в сертификат открытого ключа, могут бытьвключены только в том случае, если этот сертификат открытого ключа является одним изтех, который назначает привилегии для своего субъекта (т.е. должно быть представленорасширение subjectDirectoryAttributes). Если любое из этих расширений представлено всертификате открытого ключа, это расширение применяют ко всем привилегиям,представленным в расширении subjectDirectoryAttribute.66

O′z DSt 1108:2006Список аннулирований, использованный для опубликования извещений обаннулировании для сертификатов атрибута (ACRL и AARL), может содержать любой CRLили расширение элемента CRL, как это определено для использования в CRL и CARL вразделах с 4 по 11 настоящего стандарта.Этот раздел определяет расширения в следующих областях:a) базовое управление привилегиями: Эти расширения сертификата сообщаютинформацию, связанную с предъявлением привилегий;b) аннулирование привилегии: Эти расширения сертификата сообщают информацию,связанную с местонахождением информации о статусе аннулирования;c) источник полномочий: Эти расширения сертификата связывают с достовернымисточником привилегий, назначаемым верификатором для данного ресурса;d) роли: Эти расширения сертификата сообщают информацию, касающуюсяместонахождения, связанных сертификатов определения роли;e) делегирование: Эти расширения сертификата позволяют ставить ограничения напоследующее делегирование назначенных привилегий.Следующие требования связаны с базовым управлением привилегиями:a) издателям необходимо иметь возможность устанавливать условные ограничения навремя, в течение которого привилегия может быть предъявлена;b) издателю необходимо иметь возможность направлять сертификаты атрибута наспецифический сервер/сервис;c) возможно, издателям будет необходимо сообщать информацию, предназначеннуючтобы показать назначителю привилегий и/или верификатору привилегий, используясертификат.d) издателям, возможно, будет необходимо иметь возможность ставитьограничивающие условия на политику привилегии, вместе с которой может бытьиспользована назначенная привилегия.13.1.2 Поля базового расширения управления привилегиями13.1.2.1 Расширение спецификации времениОпределены следующие поля расширения:a) спецификация времени;b) намечаемая информация;c) извещение пользователя;d) допустимые политики привилегий.Расширение спецификации времени может быть использовано органом по присвоениюатрибутов для того, чтобы ограничить определенный период времени, в течение которогопривилегия, назначенная в сертификате, содержащем это расширение, может быть назначенавладельцем привилегий. Например, орган по присвоению атрибутов может издатьсертификат, назначив привилегии, которые могут быть предоставлены только спонедельника до пятницы с 9:00 до 17:00. Это поле определяется следующим образом:timeSpecification EXTENSION ::= {SYNTAXTimeSpecificationIDENTIFIED BY id-ce-timeSpecification }Это расширение может быть представлено в сертификатах атрибута или в сертификатахоткрытого ключа, изданных органом по присвоению атрибутов, включающий источникполномочий, для объектов, которые могут действовать, как назначители привилегий. Эторасширение не должно быть включено в сертификаты, которые содержат расширениеидентификатора источника полномочий, или в сертификаты, изданные для органа поприсвоению атрибутов, которые не могут действовать так же, как назначители привилегий.67

O′z DSt 1108:2006Если это расширение представлено в сертификате, изданном для объекта, которыйявляется органом по присвоению атрибутов, то он применяет только те утверждения объектапривилегий, которые содержатся в сертификате.Из-за того, что данное расширение точно определяет период действительностисертификата, который содержит это расширение, данное расширение должно быть отмеченокак критическое (т.е. издатель, посредством включения этого расширения, точно определяетне действительность назначения привилегии за пределами указанного времени).Если это расширение существует, но не понимается верификатором привилегий, тосертификат будет отвергнут.13.1.2.2. Соответствие спецификации времениПравила согласования спецификации времени сравнивает равенство представленногозначения со значением атрибута типа AttributeCertificate.timeSpecificationMatch MATCHING-RULE ::= {SYNTAX TimeSpecificationID id-mr-timeSpecMatch }Это правило согласования возвращает значение TRUE, если хранимое значениесодержит расширение timeSpecification и если компоненты, которые даны в представленномзначении, совпадают с соответствующими компонентами хранимого значения.13.1.2.3 Расширение намечаемой информацииРасширение намечаемой информации дает возможность определять сертификататрибута на специфический набор серверов/сервисов. Сертификат атрибута, содержащий эторасширение, должен быть применим только в этих, точно указанных серверах/сервисах. Этополе определяется следующим образом:targetingInformation EXTENSION ::= {SYNTAX SEQUENCE SIZE (1..MAX) OF TargetsIDENTIFIED BY id-ce-targetInformation }Targets ::= SEQUENCE SIZE (1..MAX) OF TargetTarget : := CHOICE {targetName [0] GeneralName,targetGroup [1] GeneralName,targetCert [2] TargetCert }TargetCert ::= SEQUENCE {targetCertificate IssuerSerial,targetName GeneralName OPTIONAL,certDigestInfo ObjectDigestInfo OPTIONAL }Компонента targetName, если она существует, представляет название целевыхсерверов/сервисов, для которых предназначен содержащийся сертификат атрибута.Компонента targetGroup, если она существует, то она предоставляет название целевойгруппы, для которой предназначен содержащийся сертификат атрибута. Определениеколичества целевых членов в пределах компоненты targetGroup выходит за областирассмотрения данного стандарта.Компонента targetCert, если существует, то она идентифицирует целевыесерверы/сервисы, ссылаясь на их сертификат.Это расширение может присутствовать в сертификатах атрибута, изданных органом поприсвоению атрибутов, включающих источник полномочий, для объектов, которые могутдействовать в качестве назначителя привилегий. Это расширение не должно быть включенов сертификаты открытого ключа или сертификаты атрибута, изданных для органа поприсвоению атрибутов, которые не могут действовать также как назначитель привилегий.Если это расширение присутствует в сертификате атрибута, изданном для объекта, который68

O′z DSt 1108:2006является органом по присвоению атрибутов, то он применяется только на те утвержденияобъекта привилегий, которые содержатся в этом сертификате. Это не влияет на возможностиоргана по присвоению атрибутов издавать сертификаты. Это расширение всегда являетсякритическим. Если это расширение присутствует, но верификатор привилегий не являетсяодним из тех, которые определены, то сертификат атрибута должен быть отвергнут. Если эторасширение не присутствует, то сертификат атрибута считается не целевым и может бытьпризнан любым сервером.13.1.2.4 Расширение извещения пользователяРасширение извещения пользователя позволяет органу по присвоению атрибутоввключить извещение, которое должно демонстрироваться владельцам, когда предъявляютсяих привилегии, и/или верификатору привилегий при использовании сертификата атрибута,содержащего это расширение.Это поле определяется следующим образом:userNotice EXTENSION ::= {SYNTAX SEQUENCE SIZE (1..MAX) OF UserNoticeIDENTIFIED BY id-ce-userNotice }Это расширение может присутствовать в сертификатах атрибута или в сертификатахоткрытого ключа, изданных органом по присвоению атрибутов, включающих источникполномочий, для объектов, которые могут действовать в качестве назначителя привилегий,включая другие органы по присвоению атрибутов и конечные объекты. Это расширение недолжно быть включено в сертификаты, которые содержат расширения идентификатораисточника полномочий, или в сертификаты, изданные для органа по присвоению атрибутов,которые не могут действовать также как назначитель привилегий. Если это расширениеприсутствует в сертификате атрибута, изданном для объекта, который является органом поприсвоению атрибутов, то он применяет только те утверждения объекта привилегий,которые содержатся в сертификате. Это не влияет на возможности органа по присвоениюатрибутов издавать сертификаты. Это расширение может по выбору издателя сертификатабыть либо критическим или некритическим. Если это расширение отмечено как критическое,извещения о пользователе будут представлены верификатору привилегий каждый раз припредъявлении привилегии. Если назначитель привилегий предоставляет сертификат атрибутаверификатору привилегий (т.е. верификатор привилегий не получает его самостоятельнонапрямую из хранилища), то извещение о пользователе также должно быть представленоназначителю привилегий.Если это расширение отмечено как некритическое, то привилегия, утвержденная всертификате, может быть предоставлена верификатором привилегий, несмотря на то, чтобыли показаны извещения о пользователе назначителю привилегий и/или верификаторупривилегий.13.1.2.5 Расширение допустимых политик привилегийПоле допустимых политик привилегий используется для ограничения утвержденияназначенных привилегий для использования вместе с определенным набором политикпривилегий. Это поле определяется следующим образом:acceptablePrivilegePolicies EXTENSION ::= {SYNTAXAcceptablePrivilegePoliciesSyntaxIDENTIFIED BY id-ce-acceptablePrivilegePolicies }AcceptablePrivilegePoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OFPrivilegePolicyЭто расширение может быть представлено в сертификатах атрибута или в сертификатахоткрытого ключа, изданных органом по присвоению атрибутов, включающих источник69

O′z DSt 1108:2006полномочий, для других органов по присвоению атрибутов или для конечных объектов.Если, это расширение содержится в сертификате открытого ключа, то оно связано только соспособностями субъекта действовать, как назначитель привилегий, согласно привилегиямсодержащимся в расширении subjectDirectoryAttributes.В случае присутствия это расширение должно быть помечено как критическое.Если это расширение присутствует, и верификатор привилегий признает его, товерификатор должен гарантировать, что политика привилегий, с которой эти привилегиисравниваются, является одной из тех, которые установлены в этом расширении.Если это расширение присутствует, но он не понятно верификатору привилегий, тосертификат будет игнорирован.13.2 Расширения аннулирования привилегий13.2.1 Необходимые условияСледующие условия касаются аннулирования сертификатов атрибута:a) для того чтобы контролировать размеры CRL, необходимо назначить поднабор наборавсех сертификатов, изданных одним органом по присвоению атрибутов для различных CRL;b) издателям сертификата атрибута необходимо иметь возможность указать всертификате атрибута, что никакая информация об аннулировании непригодна для этогосертификата.13.2.2 Поля расширения аннулирования привилегий13.2.2.1 Расширение пункта распределения CRLОпределены следующие поля расширения:a) пункты распределения CRL;b) расширение о не существовании информации об аннулировании;Расширение пункта распределения CRL определено в разделах 5, 6, 7, 8 и 9 данногостандарта для использования в сертификатах открытого ключа. Это поле также может бытьвключено в сертификат атрибута. Оно может присутствовать в сертификатах, изданных дляоргана по присвоению атрибутов, включающих источник полномочий, так же как и всертификатах, изданных для конечных объектов.Если это расширение присутствует в сертификате, верификатор привилегий долженобработать это расширение точно таким же образом, как это описано в разделах 5, 6, 7, 8 и 9для сертификатов открытого ключа.13.2.2.2 Расширение о несуществовании информации об аннулированииВ некоторых средах (например, когда сертификаты атрибута изданы с очень маленькимпериодом действия), не будет необходимости аннулировать сертификаты атрибута. Орган поприсвоению атрибутов может использовать это расширение для того, чтобы указать, что непредоставляется информация о статусе аннулирования этого сертификата атрибута. Это полеопределяется следующим образом:noRevAvail EXTENSION ::= {SYNTAXNULLIDENTIFIED BY id-ce-noRevAvail }Это расширение может присутствовать в сертификатах атрибута, изданных органом поприсвоению атрибутов, включающих источник полномочий, для конечных объектов. Эторасширение не должно включаться в сертификаты открытого ключа или в сертификатыатрибута, изданные для органа по присвоению атрибутов. Это расширение всегда являетсянекритическим.Если это расширение присутствует в сертификате атрибута, верификатору привилегиинет необходимости искать информацию о статусе аннулирования.70

O′z DSt 1108:200613.3 Расширения источника полномочий13.3.1 Необходимые условияК источнику полномочий предъявляются следующие условия:a) в некоторых средах существует необходимость для тесного контроля со стороны ЦРобъектов, которые могут действовать как источник полномочий;b) существует необходимость выполнения обоснованного определения синтаксиса ипреобладание правил для атрибутов привилегий, которые имеются в распоряженииответственных источников полномочий.13.3.2 Поля расширения источника полномочий13.3.2.1 Расширение идентификатора источника полномочийОпределены следующие поля расширения:a) идентификатор источника полномочий;b) дескриптор атрибута.Расширение идентификатора источника полномочий указывает, что субъектсертификата может действовать как источник полномочий, в целях управленияпривилегиями. По существу, субъект сертификата может определять атрибуты, которыеназначают привилегии, издавать сертификаты дескриптора атрибута для этих атрибутов ииспользовать закрытый ключ, соответствующий удостоверенному открытому ключу, длятого, чтобы издавать сертификаты, которые назначают привилегию владельцу. Этипоследующие сертификаты могут быть сертификатами атрибута или сертификатамиоткрытого ключа с расширением subjcetDirectoryAttributes, содержащим эти привилегия.В некоторых средах это расширение не требуется, а вместо этого могут бытьиспользованы другие механизмы, чтобы определить то, что объекты могут действовать какисточник полномочий. Это расширение требуется только в тех обстоятельствах, гдетребуется тесный централизованный контроль со стороны ЦР, для того чтобы управлятьобъектами, которые действуют как источник полномочий. Это поле определяетсяследующем образом:sOAIdentifier EXTENSION ::= {SYNTAX NULLIDENTIFIED BY id-ce-sOAIdentifier }Если это расширение не присутствует в сертификате, возможность действиясубъекта/владельца в качестве источника полномочий определяется другими способами.Это поле может присутствовать в сертификатах открытого ключа, изданных дляисточника полномочий. Оно не должно включатся в сертификаты атрибута или всертификаты открытого ключа, изданных для других органом по присвоению атрибутов илидля владельца привилегий конечного объекта. Это расширение всегда являетсянекритическим.13.3.2.2 Расширение дескриптора атрибута и соответствия дескриптора атрибутаОпределение атрибута привилегии и доминирующих правил, контролирующихпоследующее делегирование этих привилегий, необходимы для верификаторов привилегийдля того, чтобы гарантировать, что авторизация выполнена правильно. Эти определения иправила могут быть предоставлены верификатору привилегий различными путями, описаниекоторых лежит за области рассмотрения данного стандартаЭто расширение предоставляет механизм, который может быть использован со стороныисточника полномочий для определения атрибутов привилегий и связанныхконтролирующих правил, доступных верификатору привилегий. Сертификат атрибута,содержащий такого рода расширения, называется сертификатом дескриптора атрибута, и онявляется специальным типом сертификата атрибута. Хотя синтаксически этот сертификатявляется идентичным к AttributeCertificate, но сертификат дескриптора атрибута отличаетсяследующим:71

O′z DSt 1108:2006- содержит пустое SEQUENCE в своем поле attributes;- является сертификатом, изданным самому себе (т.е. издатель и владелец являетсяодним и тем же объектом);- включает расширение дескриптора атрибута.Это поле определяется следующим образом:attributeDescriptor EXTENSION ::= {SYNTAXAttributeDescriptorSyntaxIDENTIFIED BY {id-ce-attributeDescriptor } }AttributeDescriptorSyntax ::= SEQUENCE {identifierAttributeIdentifier,attributeSyntax OCTET STRING (SIZE(1..MAX)),name [0] AttributeName OPTIONAL,description [1] AttributeDescription OPTIONAL,dominationRule PrivilegePolicyIdentifier}AttributeIdentifier ::= ATTRIBUTE.&id({AttributeIDs})AttributeIDs ATTRIBUTE ::= {...}AttributeName ::= UTF8String(SIZE(1..MAX))AttributeDescription ::= UTF8String(SIZE(1..MAX))PrivilegePolicyIdentifier ::= SEQUENCE {privilegePolicyPrivilegePolicy,privPolSyntax InfoSyntax }Компонента identifier со значением, равным расширению attribteDescriptor, являетсяидентификатором объекта, идентифицирующий тип атрибута.Компонента attributeSyntax содержит ASN.1 описание синтаксиса атрибута.Компонента name возможно (необязательно) будет содержать простое удобное дляпользователя имя, по которому будет распознаваться атрибут.Компонента description возможно (необязательно) будет содержать простое удобноедля пользователя описание атрибута.Компонента dominationRule устанавливает для атрибута, что он означает дляделегирования привилегии, будучи «меньше чем» соответствующая привилегия, хранимаяделегатором.Компонента privilegePolicy идентифицирует (указывает) по своему идентификаторуобъекта экземпляр политики привилегии, которая содержит правила. КомпонентаprivPolSyntax содержит либо саму политику привилегий, либо указатель наместонахождение, где он может быть расположен. Если включен указатель, то необязательное (опциональное) хэш значение политики привилегий может также бытьвключено, для того чтобы позволить проверить на целостность по сосланной политикепривилегии.Это расширение может присутствовать только в сертификатах дескриптора атрибута.Это расширение не будет присутствовать в сертификатах открытого ключа или всертификатах атрибута, кроме тех, которые являются сертификатами источника полномочий,изданных самому себе. Это расширение всегда будет некритическим.Правило соответствия дескриптора атрибута сравнивает на равенство представленноезначение со значением атрибута типа AttributeCertificate.attDescriptor MATCHING-RULE ::= {SYNTAX AttributeDescriptorSyntaxID id-mr-attDescriptorMatch }Правило соответствия возвращает значение TRUE, если хранимое значение содержит всебе расширение attributeDescriptor и если присутствующие компоненты в представленномзначении совпадают с аналогичными компонентами хранимого значения.72

O′z DSt 1108:200613.4 Расширения роли13.4.1 Необходимые условияСледующие условия относится к ролям:- Если сертификат является сертификатом назначения роли, верификатору привилегийнеобходимо иметь возможность определить место соответствующего сертификатаопределяющего роль, которая содержит специфические привилегии, назначенные на самуроль.13.4.2 Поля расширения роли13.4.2.1 Расширение идентификатора сертификата определяющего роль и правилосоответствия идентификационного номера (ID) сертификата,определяющего рольОпределено следующее поле расширения:- Идентификатор сертификата определяющего роль.Расширение идентификатора сертификата, определяющего роль, может бытьиспользовано органом по присвоению атрибутов в качестве указателя на сертификат,определяющего роль, который содержит назначение привилегии на роль. Оно можетприсутствовать в сертификате назначения роли (т.е. сертификат, который содержит атрибутrole).Когда верификатор привилегий имеет дело с сертификатом назначения роли, то емунеобходимо получить набор привилегий этой роли, для того, чтобы определить результатверификации либо как успешно завершенный, либо неудачный. Если привилегии былиназначены для роли в сертификате определения роли, то это поле может быть использованодля того, чтобы определить место этого сертификата. Это поле определяется следующимобразом:roleSpecCertIdentifier EXTENSION ::={SYNTAXRoleSpecCertIdentifierSyntaxIDENTIFIED BY { id-ce-roleSpecCertIdentifier }}RoleSpecCertIdentifierSyntax ::= SEQUENCE SIZE (1..MAX) OFRoleSpecCertIdentifierRoleSpecCertIdentifier ::= SEQUENCE {roleName [0] GeneralName,roleCertIssuer [1] GeneralName,roleCertSerialNumber [2] CertificateSerialNumber OPTIONAL,roleCertLocator [3] GeneralNames OPTIONAL}Поле roleName идентифицирует роль. Его имя должно быть таким же, как и вкомпоненте holder сертификата, определяющего роль.roleCertIssuer идентифицирует орган по присвоению атрибутов, который издалсосланный сертификат определения роли.roleCertSerialNumber, если существует, то он содержит серийный номер сертификатаопределения роли. Нужно заметить, что если изменяются сами привилегии, назначенные нароль, то новый сертификат, определяющий роль, должен быть издан для этой роли. Любыесертификаты, содержащие это расширение, включая компоненту roleCertSerialNumber,должны быть заменены сертификатами, на которые ссылается новый серийный номер.roleCertLocator, если существует, то содержит информацию, которая может бытьиспользована для определения места сертификата определения роли.Это расширение, может присутствовать в сертификатах назначения роли, которыеявляются сертификатами атрибута или сертификатами открытого ключа, изданными состороны органа по присвоению атрибутов, включающих источник полномочий, для другихорганов по присвоению атрибутов или владельцем привилегий конечного объекта. Это73

O′z DSt 1108:2006расширение не должно включаться в сертификаты, которые содержат расширениеидентификатора источника полномочий.При присутствии этого расширения, его можно использовать верификаторомпривилегий, для того, чтобы определить место сертификата определения роли.Если это расширение не присутствует:a) либо другое средство будет использовано для того, чтобы определить местосертификата определения роли;b) либо для того, чтобы назначить привилегии для роли используются другиемеханизмы, отличающиеся от сертификата определения роли (т.е. привилегии роли могутбыть локально сконфигурированы на стороне верификатора привилегий).Это расширение всегда является некритическим.Правило соответствия идентификатора сертификата, определяющего роль, сравниваетна равенство представленное значение со значением атрибута типа AttributeCertificate.roleSpecCertIdMatch MATCHING-RULE ::= {SYNTAX RoleSpecCertIdentifierSyntaxID id-mr-roleSpecCertIdMatch }Это правило соответствия возвращает значение true, если хранимое значение содержитрасширение roleSpecCertIdentifier и если компоненты, которые присутствуют впредставленном значении, соответствуют аналогичным компонентам хранимых значений.13.5 Расширение делегирования13.5.1 Необходимые условияСледующие условия относятся к делегированию привилегий:a) сертификаты привилегий конечного объекта необходимы, чтобы отличить отсертификатов органов по присвоению атрибутов, для того, чтобы защититься от того, чтобыконечные объекты не устанавливали себя как орган по присвоению атрибутов безавторизации. Это также необходимо для органа по присвоению атрибутов, чтобы он имелвозможность установить лимит на длину пути последующего делегирования;b) орган по присвоению атрибутов должен иметь возможность указать подходящеепространство имен, внутри которого может произойти делегирование привилегий. Строгоесоблюдение этих ограничений требуется, чтобы быть контролепригодным со стороныверификатора привилегий;c) орган по присвоению атрибутов должен иметь возможность указать допустимыеполитики сертификата, которые предъявители привилегий передают дальше «вниз» по путиделегирования и которые будут использоваться для аутентификации их самих припредъявлении делегирования привилегий этим органом по присвоению атрибутов;d) верификатор привилегий должен иметь возможность определения места,соответствующего сертификата атрибута для издателя, для того чтобы гарантировать, чтоиздатель имел достаточные привилегии для делегирования привилегий в текущемсертификате.13.5.2 Поля расширения делегирования13.5.2.1 Расширение ограничения базового атрибута и правило соответствияограничений базового атрибутаОпределены следующие поля расширения:a) ограничения базового атрибута:b) ограничения делегированных имен;c) допустимая политика сертификата;d) идентификатор атрибута органа.Расширение ограничения базового атрибута указывает на то, что позволено липоследующее делегирование привилегий, назначенных в сертификате, содержащем эторасширение. Если так, то можно указать ограничение длины пути делегирования.74

O′z DSt 1108:2006Это поле определяется следующим образом:basicAttConstraints EXTENSION ::={SYNTAXBasicAttConstraintsSyntaxIDENTIFIED BY { id-ce-basicAttConstraints }}BasicAttConstraintsSyntax ::= SEQUENCE{authorityBOOLEAN DEFAULT FALSE,pathLenConstraint INTEGER (0..MAX) OPTIONAL}Компонента authority указывает, разрешено ли хранителю дальнейшее делегированиепривилегий. Если значение authority равно true, то хранителем является орган поприсвоению атрибутов и ему разрешается дальнейшее делегирование привилегий, взависимости от релевантных ограничений. Если значение authority равняется FALSE, тохранителем является конечный объект и ему не разрешено дальнейшее делегированиепривилегии.Компонента pathLenConstraint имеет значение, только если значение компонентыauthority равно True. Она указывает на максимальное количество сертификатов органа поприсвоению атрибутов, за которыми может проследовать этот сертификат по путиделегирования. Значение 0 указывает, что субъект этого сертификата может издаватьсертификаты только для конечных объектов, но не для органа по присвоению атрибутов.Если в сертификате делегирования пути не встречается поле pathLenConstraint, то этоозначает, что нет ограничения на дозволенную длину пути делегирования. Нужно заметить,что ограничение вступает в силу, начиная со следующего сертификата в пути. Этоограничение контролирует количество сертификатов органа по присвоению атрибутовмежду сертификатом органа по присвоению атрибутов, содержащим это ограничение исертификатом конечного объекта.Это расширение может присутствовать в сертификатах атрибута или в сертификатеоткрытого ключа, изданных органом по присвоению атрибутов, включающим источникполномочий, для других органов по присвоению атрибутов или конечных объектов. Эторасширение не должно включаться в сертификаты, которые содержат расширениеидентификатора источника полномочий.Если это расширение присутствует в сертификате атрибута, но не в сертификатыоткрытого ключа, и значение authority равняется true, то владельцу разрешается издаватьпоследующие сертификаты атрибута, делегирующие содержащиеся привилегии для другихобъектов.Если это расширение присутствует в сертификате открытого ключа и если расширениеbasicConstraints указывает на то, что субъект также является ЦР, то субъекту разрешаетсяиздавать последующие сертификаты открытого ключа, которые делегируют эти привилегиидругим объектам, но не сертификаты атрибута. Если ограничение длины пути включено, тосубъект может делегировать в пределах пересечения ограничений, указанных в этомрасширении, а также любых ограничений, указанных в расширении basicConstraints. Еслиэто расширение присутствует в сертификате открытого ключа, но в нём отсутствуетрасширение basicConstraints, или указывает, что субъект является конечным объектом, тосубъекту запрещается делегировать привилегии.Это расширение может быть по выбору издателя сертификата либо критическим, либонекритическим. Рекомендуется, чтобы это расширение было отмечено как критическое, впротивном случае владелец, которому не разрешено быть органом по присвоению атрибутов,может издать сертификаты и верификатор привилегий, может непреднамеренноиспользовать такой сертификат.Если это расширение присутствует и отмечено как критическое, тогда:75

O′z DSt 1108:2006- если значение authority не установлено на true, то делегированный атрибут не будетиспользоваться для дальнейшего делегирования;- если значение authority установлено на true и присутствует pathLenConstraint, товерификатор привилегий будет проверять этот обрабатываемый путь делегирования,который является совместимым со значением pathLenConstraint.Если это расширение присутствует и отмечено как некритическое, и не опознано состороны верификатора привилегий, то эта система должна использовать другие средства дляопределения можно ли использовать делегированный атрибут для дальнейшегоделегирования.Если расширение не присутствует, или это расширение присутствует с пустымзначением SEQUENCE, то владелец ограничивается только, чтобы быть конечным объектом,а не органом по присвоению атрибутов, и не имеет разрешения делегирования привилегий,содержащихся в сертификате атрибута.Правило соответствия ограничений базового атрибута сравнивает на равенствопредставленное значение со значением атрибута типа AttributeCertificate.basicAttConstraintsMatch MATCHING-RULE ::= {SYNTAX BasicAttConstraintsSyntaxID id-mr-basicAttConstraintsMatch }Это правило соответствия возвращает значение true, если хранимые значения содержатрасширение BasicAttConstraints, и если компоненты, которые существуют впредставленном значении, соответствуют аналогичным компонентам хранимых значений.13.5.2.2 Расширение ограничения делегированного имени и правило соответствияограничения делегированного имениПоле ограничений делегированного имени указывает на пространство имен, внутрикоторого должны быть расположены все имена держателей последующих сертификатов,указанных в пути делегирования. Это поле определяется следующим образом:delegatedNameConstraints EXTENSION ::= {SYNTAXNameConstraintsSyntaxIDENTIFIED BY id-ce-delegatedNameConstraints }Это расширение обрабатывается таким же образом, как и расширение nameConstraintsдля сертификатов открытого ключа. Если присутствует permittedSubtrees, то из всехсертификатов атрибута, изданных со стороны держателя органа по присвоению атрибутов ипоследующих держателей органа по присвоению атрибутов, находящихся в путиделегирования, допустимы только те сертификаты атрибута в пределах этого поддерева,которые с именем держателя. Если существует excludedSubtrees, то любой сертификататрибута, изданный со стороны держателя органа по присвоению атрибутов илипоследующего органа по присвоению атрибутов, находящегося в пути делегирования,который имеет имя держателя внутри этих поддеревьев, считается недопустимым. Если обаи permittedSubtrees и excludedSubtrees присутствуют и пространства имен как-топерекрывают друг друга, то сначала выполняется оператор исключения этих двухпространств (результат оператора исключения этих пространств имеет превосходство).Это расширение может быть представлено в сертификатах атрибута или в сертификатахоткрытого ключа, изданного со стороны органа по присвоению атрибутов, включая источникполномочий, для других органов по присвоению атрибутов. Это расширение не должновключаться в сертификаты, изданные для конечных объектов или в сертификаты, которыесодержат расширение идентификатора источника полномочий.Если это расширение присутствует в сертификате открытого ключа, и такжеприсутствует расширение nameConstraints, то субъект может делегировать только впределах пересечения ограничений, указанного в этом расширении и указанного врасширении nameConstraints.76

O′z DSt 1108:2006Это расширение может быть по выбору издателя сертификата атрибута либокритическим или некритическим. Рекомендуется, чтобы это расширение отмечалось каккритическое, в противном случае издатель сертификата атрибута может не проверить тепоследующие сертификаты атрибута, находящиеся на пути делегирования, которыепомещены в пространстве имен, подразумеваемых издающим органом по присвоениюатрибутов.Правило соответствия ограничений делегированного имени сравнивает на равенствопредставленное значение со значением атрибута типа AttributeCertificate.delegatedNameConstraintsMatch MATCHING-RULE ::= {SYNTAX NameConstraintsSyntaxIDid-mr-delegatedNameConstraintsMatch}Это правило соответствия возвращает значение true, если хранимое значение содержитрасширение attributeNameConstratints и если компоненты, которые присутствуют впредставленном значении, соответствуют аналогичным компонентам хранимого значения.13.5.2.3 Расширения допустимой политики сертификата и правило соответствиядопустимой политики сертификатаПоле допустимой политики сертификата используется при делегированиисертификатов атрибута, для того, чтобы контролировать допустимую политику сертификата,согласно которой сертификаты открытого ключа для последующих владельцев, находящихсяв пути делегирования, были изданными. Перечисляя набор политики в этом поле, орган поприсвоению атрибутов требует, чтобы последующие издатели, находящиеся в путиделегирования, делегировали только содержащиеся привилегии владельцам, которые имеютсертификаты открытого ключа, изданные согласно одному или нескольким перечисленнымполитикам сертификата. Политики, перечисленные здесь, не являются теми политиками,согласно которым сертификат атрибута был издан, а являются политиками, согласнокоторым должны быть изданы допустимые сертификаты открытого ключа для последующихвладельцев. Это поле определяется следующим образом:acceptableCertPolicies EXTENSION ::= {SYNTAXAcceptableCertPoliciesSyntaxIDENTIFIED BY id-ce-acceptableCertPolicies }AcceptableCertPoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF CertPolicyIdCertPolicyId ::= OBJECT IDENTIFIERЭто расширение может присутствовать только в сертификатах атрибута, изданныхорганом по присвоению атрибутов, включающих источник полномочий, для других органовпо присвоению атрибутов. Это расширение не должно включаться в сертификаты атрибутаконечного объекта или в любой сертификат открытого ключа. В случае делегирования,используя сертификаты открытого ключа, подобную функциональность можно предоставитьс помощью cetificatePolicies и другими подобными расширениями.В случае присутствия, это расширение должно быть помечено как критическое.Если это расширение присутствует, и верификатор привилегий может понять его, товерификатор гарантирует, что все последующие назначители привилегий, находящиеся впути делегирования, удостоверены сертификатом открытого ключа согласно одной илинескольким перечисленным политикам сертификата.Если это расширение присутствует, но оно не понятно верификатору привилегий, тосертификат должен быть отвергнут.Правило соответствия допустимой политики сертификата сравнивает на равенствопредставленное значение со значением атрибута типа AttributeCertificate.acceptableCertPoliciesMatch MATCHING-RULE ::= {SYNTAX AcceptableCertPoliciesSyntaxID id-mr-acceptableCertPoliciesMatch }77

O′z DSt 1108:2006Это правило соответствия возвращает значение true, если хранимое значение содержитрасширение acceptableCertPolicies и если компоненты, которые существуют впредставленном значении, соответствуют аналогичным компонентам хранимого значения.13.5.2.4 Расширение идентификатора органа по присвоению атрибутов и правилосоответствия идентификатора органа по присвоению атрибутовПри делегировании привилегий орган по присвоению атрибутов, который делегируетпривилегии, должен иметь хотя бы минимальные привилегии и полномочия дляделегирования таких привилегий. Орган по присвоению атрибутов, делегирующийпривилегии другому органу по присвоению атрибутов, или для конечного объекта, можетпоместить это расширение в сертификат органа по присвоению атрибута или конечногообъекта, которым он издаёт сертификат. Это расширение является указателем насертификат, в котором издатель сертификата, содержащий это расширение, назначил егосоответствующие привилегии. Это расширение может быть использовано со стороныверификатора привилегий, чтобы гарантировать, что издающий орган по присвоениюатрибутов имел достаточную привилегию, для того чтобы иметь возможность делегироватьдержателю сертификата, который содержит это расширение. Это поле определяетсяследующим образом:authorityAttributeIdentifier EXTENSION ::={SYNTAXAuthorityAttributeIdentifierSyntaxIDENTIFIED BY { id-ce-authorityAttributeIdentifier }}AuthorityAttributeIdentifierSyntax ::= SEQUENCE SIZE (1..MAX) OF AuthAttIdAuthAttId ::= IssuerSerialСертификат, содержащий это расширение, может включать делегирование множествапривилегий владельцу сертификата. Если назначение тех привилегий к органу поприсвоению атрибутов, который издаёт этот сертификат, были назначены более чем однимсертификатом, то это расширение должно включать более чем один указатель.Это расширение может присутствовать в сертификатах атрибута или в сертификатахоткрытого ключа, изданных органом по присвоению атрибутов для других органов поприсвоению атрибутов или для владельцев привилегий конечных объектов. Это расширениене должно быть включено в сертификаты, изданные со стороны источника полномочий или всертификаты открытого ключа, которые содержат расширение идентификатора источникаполномочий. Это расширение всегда является некритическим.Правило соответствия идентификатора органа по распространению атрибутовсравнивает на равенство представленное значение со значением атрибута типаAttributeCertificate.authAttIdMatch MATCHING-RULE ::= {SYNTAX AuthorityAttirbuteIdentifierSyntaxID id-mr-authAttIdMatch }Это правило соответствия возвращает значение true, если хранимое значение содержитрасширение authorityAttributeIdentifier и если компоненты, которые присутствуют впредставленном значении, соответствуют аналогичным компонентам хранимого значения.7814 Процедура обработки пути привилегий14.1 Процедура простой обработкиОбработка пути привилегий завершается верификатором привилегий. Правилаобработки пути сертификатов атрибута, в некоторой степени, аналогичны правиламобработки пути сертификатов открытого ключа.

O′z DSt 1108:2006Для путей привилегий, состоящих из одного сертификата, т.е. привилегий, назначенныхнепосредственно назначителю привилегий источником полномочий, пока привилегия небудет назначена для роли, требуется только простая процедура, описанная в данномподразделе. В этом случае, если верификатор привилегии не сконфигурирован соспецифическими привилегиями роли, может быть необходимым получение сертификатаопределения роли, который назначает специфические привилегии ролям, как описано в 14.2.Если эти привилегии даны назначителю привилегий промежуточным органом поприсвоению атрибутов, тогда требуется процедура пути делегирования, описанная в 14.3.Эта процедура не выполняется последовательно. Процедура обработки пути и процедураобработки делегирования, прежде всего, нужна для того, чтобы узнать предъявлены лидостаточные привилегии или нет для контекста использования в простой процедуре.Подпись на всех сертификатах в пути должна быть проверена. Верификаторпривилегий проверяет идентичность каждого объекта в пути, используя процедуры,приведенные в разделе 7. Заметим, что проверка подписи на сертификате атрибутаобязательно включает проверку сосланного сертификата открытого ключа на егодействительность. Там где привилегии назначаются, используя сертификат атрибута,средства обработки пути необходимы, для того чтобы принимать во внимание элементы иPMI и PKI в ходе определения окончательного утверждения утвердителя привилегиисертификата атрибута. Однажды подтвержденная действительность привилегии,содержащейся в сертификате, может быть использована в зависимости от сравнениярелевантной политики привилегий и другой информации, связанной с контекстом, в которомсертификат используется.Контекст использования устанавливается, если владелец привилегии действительнопредназначен для назначения содержащихся привилегий для использования в этомконтексте. Цепь сертификатов в доверенном источнике полномочий не достаточна для того,чтобы сделать это определение. Готовность хозяина привилегий чтобы использовать такойсертификат должна быть точно указана и проверена. Однако, механизмы гарантированиятого, что такое назначение привилегии адекватно продемонстрировано владельцемпривилегий выходит за пределы рассмотрения данного стандарта. В качестве примера такогоутверждения привилегии может быть верифицируемость, если владелец привилегииподписал привилегии для данного сертификата, таким образом, указывается их готовностьдля использования этого сертификата в этом контексте.Для каждого сертификата атрибута в пути, который не содержит расширениеnoRevAvail, верификатор привилегий должен гарантировать, что сертификат атрибутанеаннулирован.Верификатор привилегий должен гарантировать, что выданные привилегиидействительны в течении времени называемого «время оценки». В контексте услугиуправления доступом проверка всегда делается для настоящего времени. Когда сертификатутвержден, верификатор привилегий должен гарантировать, что время оценки истекло непозднее всего периода действительности всех сертификатов, используемых в пути. Также,если любые из сертификатов в пути содержат расширение timeSpecification, ограничения,расположенные на протяжении времени привилегии, могут быть назначены также, чтобыпозволить утверждению привилегии быть действительным ко времени оценки.Если расширение targetingInformation представлено в сертификате и используется дляутверждения привилегии, то верификатор привилегий должен проверить, что сервер/сервис,для которого он верифицируется, включен в список целей.Если сертификат является сертификатом назначения роли, то процедура обработкироли, описанная в разделе 14.2, необходима для гарантирования того, что соответствующиепривилегии идентифицируются. Если привилегия делегирована объекту, а не назначенанепосредственно источником полномочий, утвержденным верификатором привилегий, топроцедура обработки делегирования, описанная в разделе 14.3, необходима для того, чтобыгарантировать, что делегирование выполнено правильно.79

O′z DSt 1108:2006Верификатор привилегий также нужен для определения того, что достаточны или нетпривилегии, утвержденные для контекста использования. Политика привилегийустанавливает правила для создания этого определения и включения спецификации какойлибопеременной среды, которую необходимо учитывать. Утвержденные привилегии,включающие результаты из процедуры роли в разделе 14.2 и процедуры делегирования 14.3и любые переменные среды (например, время дня или баланс текущего счета) сравниваютсяс политикой привилегий для определения достаточны они или нет для контекстаиспользования. Если представлено расширение acceptablePrivilegePolicies, утверждениепривилегии может удастся, только если политика привилегий верификатора привилегийсравнивается с одной из тех политик привилегий, которая включена в это расширение.14.2 Процедура обработки ролиЕсли утвержденный сертификат это сертификат утверждения роли, то верификаторпривилегий должен получить специфические привилегии, назначенные для этой роли.Название роли, для которой предназначен назначитель привилегий, содержится в атрибутесертификата role. Верификатор привилегий, если не сконфигурирован с привилегияминазначенных ролей, может быть необходим для установления сертификата определенияроли, который назначает привилегии для этой роли. Информация в атрибуте role врасширении roleSpecCertIdentifier может быть использована для установления этогосертификата.Привилегии, назначенные для роли косвенным образом, предназначены дляназначителя привилегий и поэтому включены между утвержденными привилегиями,которые сравниваются с политикой привилегий в базовой процедуре описанной в разделе14.1 для того, чтобы определить достаточны или нет назначенные привилегии для контекстаиспользования.14.3 Процедура обработки делегирования14.3.1 Проверка целостности доминирующего правилаЕсли назначенные привилегии делегированы назначителю привилегий промежуточныморганом по присвоению атрибутов, то верификатор привилегий должен гарантировать, чтопуть это действительный путь делегирования, гарантирующий что:- каждый орган по присвоению атрибутов, который издал сертификат в путиделегирования, был авторизован, чтобы делать это;- каждый сертификат в пути делегирования действителен по отношению к пути иограничений названия, наложенных на него;- каждый объект в пути делегирования удостоверяется сертификатом открытого ключа,который действителен согласно с любым наложенным ограничением политики;- нет более значительней привилегии делегирования, чем привилегии, имеющиеся уоргана по присвоению атрибутов.До начала утверждения, пути делегирования верификатор привилегий получаетследующим образом. Любой из нижеприведенных, может быть предоставлен назначителюпривилегий, или получен верификатором привилегий из какого-нибудь другого источника,такого как директория. Атрибуты сервиса могут быть предоставлены верификаторупривилегий в виде структурированного документа или посредством какого-нибудь другогосредства:- установленное доверие в проверяющем открытом ключе используется дляутверждения подписи доверенного источника полномочий. Это доверие может бытьустановлено посредством объединенных средств или посредством сертификата открытогоключа, изданного источником полномочий для ЦР, в котором верификатор привилегий ужеустановил доверие. Такой сертификат должен содержать расширение sOAIdentifier;- привилегия назначителя привилегий закодирована в его сертификате атрибута или врасширении атрибутов субъекта директории их сертификата открытого ключа;80

O′z DSt 1108:2006- путь делегирования сертификатов от утвердителя привилегий до доверенногоисточника полномочий;- будет установлено доминирующее правило для привилегии; это может быть полученоиз дескриптора атрибута выданного ответственным за рассматриваемый атрибут источникомполномочий, или он может быть получен посредством объединенных средств;- политика привилегий; она может быть получена из директории или посредствомнекоторых объединенных средств;- переменные среды, включающие, например, текущую дату/время, баланс текущегосчета и т.д.Реализация должна быть функционально эквивалентна внешнему режиму работы,получающемуся из этой процедуры. Однако, алгоритм, используемый исключительнойреализацией для получения правильных выходных параметров из данных входныхпараметров, не стандартизируется.Доминирующее правило связано с делегируемыми привилегиями,. Синтаксис и методдля получения доминирующего правила не стандартизируется. Однако, может бытьпроверена целостность восстановленных доминирующих правил. Сертификат дескриптораатрибута, выданный источником полномочий ответственного за делегирование атрибута,может содержать HASH доминирующего правила. Верификатор привилегий можетвоспроизвести HASH функцию восстановленной копии доминирующего правила и сравнитьдва хэша. Если они идентичны, то верификатор привилегий принимает, что доминирующееправило правильно.14.3.2 Установление действительности пути делегированияВерификатор привилегий находит путь делегирования и получает сертификаты длякаждого объекта в пути. Путь делегирования расстилается от непосредственного назначителяпривилегий до источника полномочий. Каждый промежуточный сертификат в путиделегирования должен содержать расширение BasicAttConstraints с набором компонентавторизации, установленным на true. Издатель каждого сертификата должен бытьодинаковым с владельцем/субъектом сертификата, который является смежным к нему в путиделегирования. Расширение authorityAttributeIdentifier используется для установлениясоответствующего сертификата смежного объекта в пути делегирования. Количествосертификатов в пути от каждого объекта к непосредственному назначителю привилегий(включительно) не должен превышать 2 и границ значения pathLenConstraint врасширении объекта basicAttConstraints. Это потому, что pathLenConstraint ограничиваетколичество промежуточных сертификатов между двумя конечными точками (т.е.сертификат, содержащий ограничения и сертификат конечного объекта) так, чтомаксимальная длина это значение этого ограничения плюс сертификаты, являющиесяконечными точками.Если расширение delegatedNameConstraints представляется в любых сертификатах впути делегирования, ограничения обрабатываются таким же образом, как расширениеnameConstraints, которое обрабатывается процедурой обработки пути сертификации,приведенным в разделе 7.Если расширение представляется в любых сертификатах в пути делегирования,верификатор привилегий гарантирует, что аутентификация каждого последующего объектав пути делегирования выполняется сертификатом открытого ключа, который содержит, покрайней мере, одну допустимую политику.14.3.3 Проверка делегирования привилегииНе один делегатор не может делегировать привилегии, которые больше чемпривилегии, которые он имеет. Доминирующее правило в атрибуте дескриптора атрибутаобеспечивает правила для случая, когда данное значение «меньше чем» другое значение дляатрибута, который делегируется.81

O′z DSt 1108:2006Для каждого сертификата в пути делегирования, включающего сертификатнепосредственного назначителя привилегий, верификатор привилегий гарантирует, чтоделегатор был авторизован для делегирования привилегий, которыми он обладает, и чтоделегированные привилегии не больше чем те привилегии, которыми они обладают.Для каждого из этих сертификатов верификатор привилегий сравниваетделегированные привилегии с привилегиями, которые принадлежат делегатору, согласно сэтим делегатором в соответствии с доминирующим правилом для привилегий. Привилегии,обладаемые делегатором, получаются из смежных сертификатов в пути делегирования какописано в подразделе 14.3.1.14.3.4 Определение успешности/неудачи проверкиПри условии, что действительный путь делегирования установлен, привилегиинепосредственного назначителя привилегий представляются, как входные параметры, длясравнения с политикой привилегий, как описано в разделе 14.1, чтобы определитьдостаточно ли привилегий имеет или не имеет непосредственный назначитель привилегийдля контекста использования.8215 Схема директории PMI15.1 Класс объекта директории PMI15.1.1 Классы объекта пользователя PMI и органа по присвоению атрибутов PMIЭтот подраздел определяет элементы схемы директории, использованные дляпредставления информации PMI в директории. Раздел включает релевантный класс объекта,атрибуты и правила согласования значений атрибута.Класс объекта пользователя PMI используется для определения элементов дляобъектов, которые могут быть владельцем сертификата атрибута.pmiUser OBJECT-CLASS ::= {SUBCLASS OF {top}KINDauxiliaryMAY CONTAIN {attributeCertificateAttribute}ID id-oc-pmiUser }Класс объекта орган по присвоению атрибутов PMI использует в определенииэлементов для объектов, которые действуют как орган по присвоению атрибутов.pmiAA OBJECT-CLASS ::= {SUBCLASS OF{top}KINDauxiliaryMAY CONTAIN {aACertificate |attributeCertificateRevocationList |attributeAuthorityRevocationList}ID id-oc-pmiAA }15.1.2 Класс объекта источник полномочий PMIКласс объекта источник полномочий PMI используется в определении элементов дляобъектов, которые действуют как источник полномочий. Заметим, что если объект былавторизован, чтобы действовать, как источник полномочий посредством выдачи сертификатаоткрытого ключа, содержащего расширение sOAIdentifier, содержимое директориипоказывает, что объект также должен содержать класс объекта pkiCA.pmiSOA OBJECT-CLASS ::= {SUBCLASS OF{top}KINDauxiliaryMAY CONTAIN {attributeCertificateRevocationList |attributeAuthorityRevocationList |

O′z DSt 1108:2006attributeDescriptorCertificate}ID id-oc-pmiSOA }15.1.3 Класс объекта пункт распределения сертификата атрибута CRLКласс объекта пункт распределения сертификата атрибута CRL используется вопределении элементов для объектов, которые содержат сертификат атрибута и сегментысписка аннулирования органа по присвоению атрибутов. Этот вспомогательный класспредназначен для объединения со структурным классом объекта crlDistributionPoint, когдасодержимое подвергается обработке. Поскольку атрибуты в certificateRevocationList иauthorityRevocationList не обязательны в этом классе, можно создать элементы, которыесодержат, например, только список аннулированных органов по присвоению атрибутов илиэлементы, которые содержат списки аннулирования множественных типов, зависящих оттребований.attCertCRLDistributionPt OBJECT-CLASS ::= {SUBCLASS OF{top}KINDauxiliaryMAY CONTAIN { attributeCertificateRevocationList |attributeAuthorityRevocationList }ID id-oc-attCertCRLDistributionPts }15.1.4 Делегирование пути PMIКласс объекта пути делегирования PMI используется для определения элемента дляобъектов, которые могут делегировать пути. Он обычно используется в сочетании сэлементом структурного класса объекта pmiAA.pmiDelegationPath OBJECT-CLASS ::= {SUBCLASS OF{top}KINDauxiliaryMAY CONTAIN { delegationPath }ID id-oc-pmiDelegationPath }15.1.5 Класс объекта политики привилегийКласс объекта политики привилегий используется в определении элемента для объекта,который содержит информацию о политике привилегии.privilegePolicy OBJECT-CLASS ::= {SUBCLASS OF{top}KINDauxiliaryMAY CONTAIN {privPolicy }IDid-oc-privilegePolicy15.2 Атрибуты директории PMI15.2.1 Атрибут сертификата атрибутаЭтот подраздел определяет атрибуты директории, использованные для храненияданных PMI в элементах директории.Следующий атрибут содержит сертификаты атрибута, выданные для специфическихвладельцев и хранится в элементе директории этого держателя.attributeCertificateAttribute ATTRIBUTE ::= {WITH SYNTAXAttributeCertificateEQUALITY MATCHING RULE attributeCertificateExactMatchIDid-at-attributeCertificate83

O′z DSt 1108:200615.2.2 Сертификат атрибута органа по присвоению атрибутаСледующий атрибут содержит сертификаты атрибута, выданные для органа поприсвоению атрибутов и хранится в элементе директории владельца органа по присвоениюатрибутов.aACertificate ATTRIBUTE ::= {WITH SYNTAXAttributeCertificateEQUALITY MATCHING RULE attributeCertificateExactMatchID id-at-aACertificate }15. 2.3 Сертификат атрибута дескриптора атрибутаСледующий атрибут содержит сертификаты атрибута, выданные источникомполномочий, которые содержат расширения attributeDescriptor. Эти сертификаты атрибутасодержат действительный синтаксис и спецификацию доминирующего правила атрибутапривилегий и хранится в элементе директории издающего источника полномочий.attributeDescriptorCertificate ATTRIBUTE ::= {WITH SYNTAXAttributeCertificateEQUALITY MATCHING RULEttributeCertificateExactMatchIDid-at-attributeDescriptorCertificate15.2.4 Атрибут списка аннулированных сертификата атрибутовСледующий атрибут содержит список аннулированных сертификатов атрибута. Этисписки могут храниться в элементе директории издающего органа, или в других элементахдиректории (например, пункт распределения).attributeCertificateRevocationList ATTRIBUTE ::= {WITH SYNTAXCertificateListEQUALITY MATCHING RULE certificateListExactMatchIDid-at-attributeCertificateRevocationList}15.2.5 Атрибут списка аннулированных сертификатов органа по присвоениюатрибутовСледующий атрибут содержит список аннулированных сертификатов атрибута,выданных для органа по присвоению атрибутов. Эти списки могут храниться в элементедиректории издающего органа или в других элементах директории (например, пунктраспределения).attributeAuthorityRevocationList ATTRIBUTE ::= {WITH SYNTAXCertificateListEQUALITY MATCHING RULE certificateListExactMatchID id-at-attributeAuthorityRevocationList }15.2.6 Атрибут пути делегированияАтрибут пути делегирования содержит пути делегирования, каждый из которыхсостоит из последовательности сертификатов атрибута.delegationPath ATTRIBUTE ::= {WITH SYNTAXAttCertPathID id-at-delegationPath }AttCertPath ::= SEQUENCE OF AttributeCertificateЭтот атрибут может храниться в элементе директории органа по присвоению атрибутови должен содержать какие-либо пути делегирования от этого органа по присвоениюатрибутов к другим органам по присвоению атрибутов. Этот атрибут, если он используется,позволяет более эффективно восстанавливать делегированные сертификаты атрибута, формакоторых часто используется путями делегирования.84

O′z DSt 1108:200615.2.7 Атрибут политики привилегийАтрибут политики привилегий содержит информацию о политике привилегий.privPolicy ATTRIBUTE ::= {WITH SYNTAX PolicySyntaxIDid-at-privPolicyКомпонента policyIdentifier включает идентификатор объекта, зарегистрированный дляотдельного объекта.Если представлен content, то включается полное содержание политики привилегий.Если представлен pointer, то компонента name ссылается на одно или более мест, гдемогут быть расположены копии политики привилегий. Если представлена компонента hash,она содержит HASH содержание политики привилегий, которая должна быть найдена насосланном месте. Этот хэш может быть использован для выполнения проверки нацелостность сосланного документа.15.3 Общие правила соответствия директории PMI15.3.1 Точное соответствие сертификата атрибутаЭтот подраздел определяет правила соответствия для атрибутов директории PMI.Точное правило соответствия сертификата атрибута сравнивает равенствопредставленного значения со значением атрибута типа AttributeCertificate.attributeCertificateExactMatch MATCHING-RULE ::= {SYNTAXAttributeCertificateExactAssertionID id-mr-attributeCertificateExactMatch }AttributeCertificateExactAssertion ::= SEQUENCE {serialNumber CertificateSerialNumber OPTIONAL,issuerIssuerSerialЭто правило соответствия возвращает значение true, если компоненты в значенииатрибута эквивалентны тем, которые приведены в представленном значении.15.3.2 Соответствие сертификата атрибутаПравило соответствия сертификата атрибута сравнивает представленное значение сзначением типа AttributeCertificate. Эти правила соответствия обеспечивают болеекомплексное соответствие, чем certificateExactMatch.attributeCertificateMatch MATCHING-RULE ::= {SYNTAXAttributeCertificateAssertionID id-mr-attributeCertificateMatch }AttributeCertificateAssertion ::= SEQUENCE {holder [0] CHOICE {baseCertificateID [0] IssuerSerial,holdertName [1] GeneralNames} PTIONAL,issuer [1] GeneralNames OPTIONAL,attCertValidity [2] GeneralizedTime OPTIONAL,attType [3] SET OF AttributeType OPTIONAL}-- как минимум одна компонента последовательности должна быть представленаПравило соответствия возвращает значение true, если все из компонент, которыепредставлены в представленном значении соответствуют аналогичным компонентамзначения атрибута, следующим образом:- baseCertificateID совпадает, если он эквивалентен компоненте IssuerSerialхранимого значения атрибута;- holderName совпадает, если хранимое значение атрибута содержит расширениеимени с одинаковым типом имени как указано в представленном значении;85

O′z DSt 1108:2006- issuer совпадает, хранимое значение атрибута содержит компоненту именивышеупомянутого типа имени как указано в представленном значении;- attCertValidity совпадает, если он находится в пределах определенного периодадействительности хранимого значения атрибута;- для каждого attType в представленном значении в компоненте attributes хранимогозначения представляется атрибут этого типа.15.3.3 Соответствие издателя и владельца сертификатаПравило соответствия атрибута сертификата держателя и издателя сравниваетравенство представленного значения держателя и/или компонентов издателяпредставленного значения со значением атрибута типа AttributeCertificate.holderIssuerMatch MATCHING-RULE ::= {SYNTAXHolderIssuerAssertionID id-mr-holderIssuerMatch }HolderIssuerAssertion ::= SEQUENCE {holder [0] Holder OPTIONAL,issuer [1] AttCertIssuer OPTIONAL }Правило согласования возвращает значение true если все из компонент, которыепредставлены в представленном значении соответствуют аналогичным компонентамзначения атрибута.15.3.4 Соответствие пути делегированияПравило согласования delegationPathMatch сравнивает равенство представленногозначения со значением атрибута типа delegationPath. Верификатор привилегий можетиспользовать это правило согласования, чтобы выбрать путь, начинающийся с сертификата,изданного его источником полномочий и заканчивающийся сертификатом, выданныморганом по присвоению атрибутов, который выдан утвержденному конечному держателюсертификата.delegationPathMatch MATCHING-RULE ::= {SYNTAXDelMatchSyntaxID id-mr-delegationPathMatch }DelMatchSyntax ::= SEQUENCE {firstIssuer AttCertIssuer,lastHolder Holder }Это правило согласования возвращает значение true, если представленное значение вкомпоненте firstIssuer соответствует аналогичному элементу поля издателя первогосертификата в SEQUENCE в хранимом значении и представленное значение в компонентесовпадает (соответствует) элементам поля держателя последнего сертификата в SEQUENCEв хранимом значении. Это правило согласования возвращает значение FALSE, если обасравнения неудачны.16 Аутентификация директории16.1 Процедура простой аутентификации16.1.1 Генерация защищенной идентифицирующей информацииДиректория поддерживает аутентификацию пользователей, обращающихся кдиректории через агента пользователя директории (DUA) и аутентификацию справочныхсистем (DSA) для доступа к пользователем и к другим DSA. В зависимости от обстановки,может быть использована либо простая, либо жесткая аутентификация. Процедуры,86

O′z DSt 1108:2006используемые для простой и жесткой аутентификации в директории описаны в следующихразделах.Простая аутентификация предназначена для предоставления локальной авторизации,основанной на различительном имени пользователя, двухсторонне соглашенного (необязательного) пароля, и двухсторонне понимаемых средств использования и обращенияэтого пароля внутри одного домена. Использование простой аутентификации главнымобразом предназначено только для локального использования, т.е. аутентификацияравноправных объектов между одним DUA и одним DSA или между двумя DSA. Простаяаутентификация может быть реализована несколькими способами:a) передачей различительного имени пользователя и (необязательного) пароля внезащищенном виде получателю для анализа;b) передачей различительного имени пользователя, пароля и случайного числа и/илиметки времени, каждая из них защищена с помощью применения односторонней функции;c) передачей защищенной информации, описанной в пункте b), вместе со случайнымчислом и/или параметром времени, каждое из которых защищено с помощью примененияодносторонней функции.В местах, где пароли не защищены, обеспечивается минимальный уровеньбезопасности для предотвращения несанкционированного доступа. Это не должнорассматриваться, как основа для служб безопасности. Защита различительного именипользователя и пароля обеспечивает значительный уровень безопасности. Алгоритмы,используемые для механизма защиты являются не шифрующими одностороннимифункциями, которые очень просто реализовать. Общая процедура для реализации простойаутентификации показана на рисунке 4.2Директория1А4В3Рисунок 4 - Не защищенная процедура простой аутентификацииСюда включены следующие шаги:1) исходный (отправитель) пользователь A отправляет свое различительное имя ипароль пользователю (получателю) B;2) B отправляет предполагаемое различительное имя и пароль пользователя A вдиректорию, где пароль проверяется с тем, который храниться как атрибут UserPassword вэлементе директории для пользователя A (используя операцию сравнения директории);3) директория подтверждает (или отвергает) для B, что переданные данные являютсядействительными;4) результат успешности (или неудачи) аутентификации может быть сообщенпользователю A.Самая базовая форма простой аутентификации включает в себя только шаг 1) и послетого как пользователь B проверил различительное имя и пароль, можно включить шаг 4).Рисунок 5 иллюстрирует два подхода, согласно которым можно сгенерироватьзащищенную идентифицирующую информацию. f1 и f2 являются одностороннимифункциями (либо идентичные, либо различные), а также временные параметры (метки) ислучайные числа являются необязательными и являются предметом двухстороннегосоглашения.87

O′z DSt 1108:2006Apassw At1 Aq1 At2 Aq2 Af1f2Защита пароля1Защита пароля 2A –различительное имя пользователяt1 A – временной штампpassw A – пароль пользователя Aq A – случайные числаРисунок 5 - Защищенная простая аутентификация16.1.2 Процедура для простой защищенной аутентификацииРисунок 6 иллюстрирует процедуру для простой защищенной аутентификации.A1B2В эту процедуру включены следующие шаги (первоначально использованием толькоf1):1) первичный (отправитель) пользователь A отправляет свою защищеннуюидентифицирующую информацию (Аутентификатор1) пользователю B. Защита достигаетсяприменением односторонней функцию (f1) из Рисунка 5, где временной параметр (метка)и/или случайное число (при использовании) используются для минимизациивоспроизведения и маскировки (скрытия) пароля.Защита пароля пользователя A выполняется в форме:Защищенный пароль1 = f1 (t1A, q1A, A, passwA)Информация, пользователю B передается в форме:Аутентификатор1 = t1A, q1A, A, Защищенный пароль1;2) B проверяет подлинность защищенной идентифицируемой информациипредоставленной со стороны A, с помощью генерации (используя отличительное имя инеобязательный временной параметр (метка) и/или случайное число, предоставленное состороны пользователя A, вместе с локальной копией пароля этого пользователя A) локальнойзащищенной копии пароля пользователя A (в форме Защищенный пароль1). Пользователь Bсравнивает на равенство предъявленную идентифицирующую информацию (Защищенныйпароль1) с локально сгенерированным значением;3) пользователь B подтверждает или отклоняет верификацию защищеннойидентифицирующей информации пользователя А.Процедура может быть модифицирована для того, чтобы предоставить большезащищенности, используя f1 и f2. Основные различия являются следующими:1) Пользователь A отправляет свою дополнительно-защищеннуюидентифицирующую информацию (Аутентификатор2) пользователю B. Дополнительнаязащита осуществляется применением дополнительного использования одностороннейфункции f2, как это показано на рисунке 5. Дополнительная защита будет в следующейформе:88Рисунок 6 - Процедура простой защищенной аутентификации

O′z DSt 1108:2006Защищенный пароль 2 = f2(t2 A , q2 A , Защищенный пароль1)Информация, передаваемая пользователю B, определяется формулой:Аутентификатор2 = t1 A , t2 A , q1 A , q2 A , A, Защищенный пароль2Для сравнения, пользователь B генерирует локальное значение дополнительнозащищенного пароля пользователя A и сравнивает его на равенство с Защищенный пароль 2;2) пользователь B подтверждает или игнорирует верификацию защищеннойидентифицирующей информации пользователя A.16.1.3 Тип атрибута пароль пользователяТип атрибута пароль пользователя содержит пароль объекта. Значение атрибута дляпароля пользователя является строкой, которая определяется объектом.userPassword ATTRIBUTE ::= {WITH SYNTAXOCTET STRING (SIZE (0..ub-user-password))EQUALITY MATCHING RULE octetStringMatchID id-at-userPassword }16.2 Жесткая аутентификация16.2.1 Получение из директории сертификата открытого ключаПроцедура, описанная в этом подразделе, используется в аутентификации между DUAи DSA, так же как между парными DSA. Процедуры пользуются структурой сертификата,определенной в настоящем стандарте. Кроме того, процедуры используют саму директорию,как хранилище для информации об открытом ключе требующуюся для аутентификации.Процедура, использованная здесь для жесткой аутентификации, может также бытьиспользована приложениями, отличающимися от директории, которые также пользуютсятакими хранилищами. Для директории, использующей эти процедуры, термин«пользователь» в этих процедурах может означать оба и DUA, и DSA.Подход к жесткой аутентификации, принятый в спецификации настоящего стандарта,использует свойства семейства криптографических систем, известных, как криптосистемыоткрытых ключей (PKCS). Эти криптосистемы определены как ассиметричные, включающиепару ключей: один частный (закрытый) и один открытый, а не один ключ, как в обычныхкриптографических системах.Эта структура не поручает для использования отдельную криптосистему. Онаподразумевает, что структура должна быть применима к любой криптосистеме с открытымключом и должна поддерживать изменения, как результат будущего прогресса вкриптографии.Аутентификация предполагает, что каждый пользователь имеет различительное имя.Распределение различительных имен это ответственность органа по распределению имен.Поэтому каждый пользователь доверяет тому, что орган по присвоению имен не издастдубликат различительных имен.Каждый пользователь идентифицируется его собственным закрытым ключом. Еслипартнер имеет закрытый ключ, второй пользователь имеет возможность определить это иможет использовать закрытый ключ, чтобы подтвердить, что связанный партнердействительно пользователь. Действительность этого подтверждения зависит от закрытогоключа, остающегося секретным для пользователя.Пользователь, чтобы определить связанного партнера, получает открытый ключдругого пользователя. Несмотря на то, что получение значения этого открытого ключа изэлемента директории легко, проверка правильности более проблематична. Существуютмного возможных путей для выполнения проверки правильности открытого ключапользователя: данный подраздел описывает процесс, посредством которого открытый ключпользователя может быть проверен ссылкой на директорию. Этот процесс может работать,если только существует целая (неразорванная) цепь доверенных пунктов в директориимежду пользователями, требующими аутентификацию. Такая цепь может быть построенапосредством идентификации общего пункта доверия. Этот общий пункт доверия должен89

O′z DSt 1108:2006быть присоединен к каждому пользователю посредством, неразорванной цепи доверенныхпунктов.Сертификаты содержатся в элементах директории как атрибуты типов UserCertificate,CACertificate и CrossCertificatePair. Эти типы атрибутов известны для директории. Этиатрибуты могут управляться одним и тем же протоколом, работающим как другой атрибут.Спецификация этого типа атрибута определяется в подразделе 9.2.В общем случае, прежде чем пользователи могут взаимно аутентифицироваться,директория доставляет полный сертификат и обратные пути сертификации. Однако, напрактике, количество информации, которая будет получена из директории, может бытьуменьшеноы для отдельных случаев аутентификации следующим образом:a) если два пользователя, которые хотят аутентифицироваться, обслуживаются однимсертифицирующим органом, тогда путь сертификации становится ограниченным ипользователи непосредственно разворачивают сертификаты друг друга;b) если ЦР пользователей расположены в иерархии, пользователь должен хранитьоткрытые ключи, сертификаты и наоборот сертификаты всех ЦР между пользователем икорнем DIT;c) если пользователь часто связывается с пользователями сертифицированными другим,отдельным (индивидуальным) ЦР, этот пользователь изучит путь сертификации к этому ЦР иобратный путь от этого ЦР, это необходимо только для получения сертификата другогопользователя из директории;d) ЦР могут кросс - сертифицировать посредством двусторонних соглашений. Врезультате происходит сокращение пути сертификации;e) два пользователя, прежде чем связаться и изучить сертификаты друг-друга, онимогут аутентифицироваться без какой либо помощи директории.В любом случае, при знании любых сертификатов из пути сертификации, пользователидолжны проверять действительность полученных сертификатов.16.2.2 Процедуры жесткой аутентификации16.2.2.1 Односторонняя аутентификацияПростой подход для аутентификации в общих чертах описан выше, т.е. подтверждениеподлинности осуществляется посредством обладания закрытым ключом. Тем не менее,многие процедуры аутентификации по возможности используют этот подход. В общем,определение соответствующей процедуры в качестве подходящей политики безопасностиприложения это задача специфического приложения. Этот подраздел описывает триотдельные процедуры аутентификации, которые могут быть полезны в ряде приложений.Эти три процедуры включают различное количество обмена аутентифицирующейинформацией и следовательно обеспечивают различные типы гарантий их участникам. Аименно:a) односторонняя аутентификация, описанная в 16.2.2.1, включает одиночную передачуинформации от пользователя А, предназначенную пользователю В, и устанавливаетследующее:- подлинность А и что идентификационный признак действительно былгенерирован А;- подлинность В, и что идентификационный признак действительно былпредназначен для передачи В;- идентификационный признак был передан в целостности и в «оригинальном»виде.b) двухсторонняя аутентификация, описанная в 16.2.2.2, к тому же включает ответ В кА. Она устанавливается следующим образом:- идентификационным признаком, генерируемым из ответа, который генерируетсяВ и предназначен для передачи А;- целостностью и оригинальностью идентификационного признака, переданного вответе;90

O′z DSt 1108:2006d) трехсторонняя аутентификация, описанная в 16.2.2.3, к тому же включаетдальнейшую передачу от А к В. Она устанавливает такие же свойства как и двухсторонняяаутентификация, но делает это без потребности сравнения связанной временной метки.В каждом случае, где жесткая аутентификация имеет место, А должен получитьоткрытый ключ В и обратный путь сертификации от В к А, предшествующий любомуобмену информацией. Это может включать доступ к директории, как описано в 16.2.При использовании временной метки рекомендуется использовать универсальноеустановленное время.Для каждого из трех процедур аутентификации, описанных выше, предполагается чтосторона А проверяет действительность всех сертификатов в пути сертификации.Рисунок 7 включает следующие шаги:1) А генерирует одноразовое число r A , которое используется для обнаруженияпроизведенных атак и предотвращения подделки;2) А передает следующее сообщение В:B>A, A{t А , r А , B},где: t А это временная метка. t А содержит две или более дат: время генерации признака(которое не обязательно) и дату истечения срока. Если аутентификация источника данныхэто "sgnData" она обеспечивается цифровой подписью:BA, A{ t А , r А , B, sgnData}В случае, где информация была сообщена и была использована как закрытый ключ (этаинформация обозначается как "encData"):BA, A{ t А , r А , B, sgnData, Bp[encData]}Использование "encData" как закрытый ключ подразумевает, что он будет выбраносторожно, например, чтобы быть сильным ключом какой-либо криптосистемыиспользуемой как указано в поле "encData" признака;3) В выполняет следующие действия:a) получает А р от ВА, проверяет не истек ли срок сертификата А;b) проверяет подписи, и таким образом целостность подписанной информации;c) проверяет, что сам В является получателем (действительно ли предназначеноему);d) проверяет что временная метка «текущая»;e) факультативно, проверяет что r А не был воспроизведен. Это, например,может быть получено обладанием r А включая последовательные части, которые проверенылокальным выполнением для уникальности его значения. r А действителен до тех пор, покадата указанная в t А , не кончилась. r А всегда сопровождается последовательной частью,которая указывает, что А не повторит знака в течении времени t А и поэтому сопоставлениесвоего значения r А не требуется.A123BРисунок 7 - Односторонняя аутентификация16.2.2.2 Двухсторонняя аутентификацияРисунок 8 включает следующие шаги:1) как в 16.2.2.1;2) как в 16.2.2.1;3) как в 16.2.2.1;4) В генерирует одноразовое число r B , использованное для похожих целей как и r A ;5) В посылает следующий идентификационный признак А:B{t B , r B , A, r A },91

O′z DSt 1108:2006где: t B временная метка, определенная также как t A .Если аутентификация источника данных это "sgnData" она обеспечивается цифровойподписью:B{tB, rB, A, rA, sgnData}В случае, где информация была сообщена и была использована как закрытый ключ (этаинформация обозначается как "encData"):B{tB, rB, A, rA, sgnData, Ap[encData]}.Использование "encData" как закрытый ключ подразумевает, что он будет выбраносторожно, например чтобы быть сильным ключом какой-либо криптосистемы,используемой как указано в поле "encData" признака;6) А выполняет следующие действия:a) проверяет подпись и таким образом целостность подписанной информации;b) проверяет, что А это предназначенный получатель;c) проверяет что r B не был воспроизведен (см. 16.2.2.1, шаг 3), г)).A1523B64Рисунок 8 - Двухсторонняя аутентификация16.2.2.3 Трехсторонняя аутентификацияРисунок 9 включает следующие шаги:1) как в 16.2.2.2;2) как для 16.2.2.2 временная метка t A может быть обнулена;3) как для 16.2.2.2 исключает, что временная метка не должна быть проверена;4) как в 16.2.2.2;5) как для 16.2.2.2 временная метка t A может быть обнулена;6) как для 16.2.2.2 исключает, что временная метка не должна быть проверена;7) А проверяет, что принятый r A идентичен r A , который был проверен;8) А посылает следующий идентификационный признак В:A{rB,B};9) В выполняет следующие действия:a) проверяет подпись и таким образом целостность подписанной информации;b) проверяет, что полученный r B идентичен r B , который был принят В.A1 32654B87Рисунок 9 - Трехсторонняя аутентификация992

O′z DSt 1108:2006Приложение A(обязательное)Структура сертификата открытого ключа исертификата атрибутаА.1 Данное приложение включает все типы ASN.1, значение и определения классовинформационных объектов, содержащихся в данном стандарте в форме трех модулей ASN.1:AuthenticationFramework, CertificateExtensions и AttributeCertificateDerinitions.-- A.2 Модуль структуры АутентификацииAuthenticationFramework {joint-iso-itu-t ds(5) module(1) authenticationFramework(7)4}DEFINITIONS ::=BEGIN-- EXPORTS All –IMPORTSid-at, id-nf, id-oc, informationFramework, upperBounds, selectedAttributeTypes,basicAccessControl,certificateExtensionsFROM UsefulDefinitions {joint-iso-itu-t ds(5) module(1) usefulDefinitions(0) 4}Name, ATTRIBUTE, OBJECT-CLASS, NAME-FORM, topFROM InformationFramework informationFrameworkub-user-password, ub-contentFROM UpperBounds upperBoundsUniqueIdentifier, octetStringMatch, DirectoryString, commonNameFROM SelectedAttributeTypes selectedAttributeTypescertificateExactMatch, certificatePairExactMatch, certificateListExactMatch,KeyUsage, GeneralNames,CertificatePoliciesSyntax, algorithmIdentifierMatch, CertPolicyIdFROM CertificateExtensions certificateExtensions ;-- Определение сертификата открытого ключа --Certificate ::= SIGNED { SEQUENCE {version [0] Version DEFAULT v1,serialNumber CertificateSerialNumber,signature AlgorithmIdentifier,issuer Name,validity Validity,subject Name,subjectPublicKeyInfo SubjectPublicKeyInfo,issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL,subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL,extensions [3] Extensions OPTIONAL} }Version ::= INTEGER { v1(0), v2(1), v3(2) }CertificateSerialNumber ::= INTEGERAlgorithmIdentifier ::= SEQUENCE {algorithm ALGORITHM.&id ({SupportedAlgorithms}),parameters ALGORITHM.&Type ({SupportedAlgorithms}{ @algorithm})OPTIONAL }SupportedAlgorithms ALGORITHM ::= { ... }Validity ::= SEQUENCE {93

O′z DSt 1108:2006notBefore Time,notAfter Time }SubjectPublicKeyInfo ::= SEQUENCE {algorithm AlgorithmIdentifier,subjectPublicKey BIT STRING }Time ::= CHOICE {utcTime UTCTime,generalizedTime GeneralizedTime }Extensions ::= SEQUENCE OF ExtensionExtension ::= SEQUENCE {extnId EXTENSION.&id ({ExtensionSet}),critical BOOLEAN DEFAULT FALSE,extnValue OCTET STRING}ExtensionSet EXTENSION ::= { ... }EXTENSION ::= CLASS {&id OBJECT IDENTIFIER UNIQUE,&ExtnType }WITH SYNTAX {SYNTAX &ExtnTypeIDENTIFIED BY &id }-- другие конструкции сертификата PKICertificates ::= SEQUENCE {userCertificate Certificate,certificationPath ForwardCertificationPath OPTIONAL}ForwardCertificationPath ::= SEQUENCE OF CrossCertificatesCrossCertificates ::= SET OF CertificateCertificationPath ::= SEQUENCE {userCertificate Certificate,theCACertificates SEQUENCE OF CertificatePair OPTIONAL}CertificatePair ::= SEQUENCE {forward [0] Certificate OPTIONAL,reverse [1] Certificate OPTIONAL}(WITH COMPONENTS {…, forward PRESENT} |WITH COMPONENTS {…, reverse PRESENT})-- Список отозванных сертификатов (CRL)CertificateList ::= SIGNED { SEQUENCE {version Version OPTIONAL,signature AlgorithmIdentifier,issuer Name,thisUpdate Time,nextUpdate Time OPTIONAL,revokedCertificates SEQUENCE OF SEQUENCE {serialNumber CertificateSerialNumber,revocationDate Time,crlEntryExtensions Extensions OPTIONAL } OPTIONAL,crlExtensions [0] Extensions OPTIONAL }}-- классы информационных объектов --ALGORITHM ::= TYPE-IDENTIFIER-- параметpизованные типы --HASH {ToBeHashed} ::= SEQUENCE {algorithmIdentifier AlgorithmIdentifier,hashValue BIT STRING ( CONSTRAINED BY {94

O′z DSt 1108:2006} ) }ENCRYPTED-HASH { ToBeSigned } ::= BIT STRING ( CONSTRAINED BY {})ENCRYPTED { ToBeEnciphered } ::= BIT STRING ( CONSTRAINED BY {})SIGNATURE { ToBeSigned } ::= SEQUENCE {algorithmIdentifier AlgorithmIdentifier,encrypted ENCRYPTED-HASH { ToBeSigned }}SIGNED { ToBeSigned } ::= SEQUENCE {toBeSigned ToBeSigned,COMPONENTS OF SIGNATURE { ToBeSigned }}-- классы объекта PKI --pkiUser OBJECT-CLASS ::= {SUBCLASS OF {top}KIND auxiliaryMAY CONTAIN {userCertificate}ID id-oc-pkiUser }pkiCA OBJECT-CLASS ::= {SUBCLASS OF {top}KIND auxiliaryMAY CONTAIN {cACertificate |certificateRevocationList |authorityRevocationList |crossCertificatePair }ID id-oc-pkiCA }cRLDistributionPoint OBJECT-CLASS ::= {SUBCLASS OF { top }KIND structuralMUST CONTAIN { commonName }MAY CONTAIN { certificateRevocationList |authorityRevocationList |deltaRevocationList }ID id-oc-cRLDistributionPoint }cRLDistPtNameForm NAME-FORM ::= {NAMES cRLDistributionPointWITH ATTRIBUTES { commonName}ID id-nf-cRLDistPtNameForm }deltaCRL OBJECT-CLASS ::= {SUBCLASS OF {top}KIND auxiliaryMAY CONTAIN {deltaRevocationList}ID id-oc-deltaCRL }cpCps OBJECT-CLASS ::= {SUBCLASS OF {top}KIND auxiliaryMAY CONTAIN {certificatePolicy |certificationPracticeStmt}ID id-oc-cpCps }pkiCertPath OBJECT-CLASS ::= {SUBCLASS OF {top}KIND auxiliaryMAY CONTAIN { pkiPath }ID id-oc-pkiCertPath }95

O′z DSt 1108:2006-- Атрибуты директории PKI --userCertificate ATTRIBUTE ::= {WITH SYNTAX CertificateEQUALITY MATCHING RULE certificateExactMatchID id-at-userCertificate}cACertificate ATTRIBUTE ::= {WITH SYNTAX CertificateEQUALITY MATCHING RULE certificateExactMatchID id-at-cAcertificate }crossCertificatePair ATTRIBUTE ::= {WITH SYNTAX CertificatePairEQUALITY MATCHING RULE certificatePairExactMatchID id-at-crossCertificatePair }certificateRevocationList ATTRIBUTE ::= {WITH SYNTAX CertificateListEQUALITY MATCHING RULE certificateListExactMatchID id-at-certificateRevocationList }authorityRevocationList ATTRIBUTE ::= {WITH SYNTAX CertificateListEQUALITY MATCHING RULE certificateListExactMatchID id-at-authorityRevocationList }deltaRevocationList ATTRIBUTE ::= {WITH SYNTAX CertificateListEQUALITY MATCHING RULE certificateListExactMatchID id-at-deltaRevocationList }supportedAlgorithms ATTRIBUTE ::= {WITH SYNTAX SupportedAlgorithmEQUALITY MATCHING RULE algorithmIdentifierMatchID id-at-supportedAlgorithms }SupportedAlgorithm ::= SEQUENCE {algorithmIdentifier AlgorithmIdentifier,intendedUsage [0] KeyUsage OPTIONAL,intendedCertificatePolicies [1] CertificatePoliciesSyntax OPTIONAL }certificationPracticeStmt ATTRIBUTE ::= {WITH SYNTAX InfoSyntaxID id-at-certificationPracticeStmt }InfoSyntax ::= CHOICE {content DirectoryString {ub-content},pointer SEQUENCE {name GeneralNames,hash HASH { HashedPolicyInfo } OPTIONAL } }POLICY ::= TYPE-IDENTIFIERHashedPolicyInfo ::= POLICY.&Type( {Policies} )Policies POLICY ::= {...} -- Определенная со стороны реализатора --certificatePolicy ATTRIBUTE ::= {WITH SYNTAX PolicySyntaxID id-at-certificatePolicy }PolicySyntax ::= SEQUENCE {policyIdentifier PolicyID,policySyntax InfoSyntax}96PolicyID ::= CertPolicyId

O′z DSt 1108:2006pkiPath ATTRIBUTE ::= {WITH SYNTAX PkiPathID id-at-pkiPath }PkiPath ::= SEQUENCE OF CrossCertificatesuserPassword ATTRIBUTE ::= {WITH SYNTAX OCTET STRING (SIZE (0..ub-user-password))EQUALITY MATCHING RULE octetStringMatchID id-at-userPassword }id-oc-cRLDistributionPoint OBJECT IDENTIFIER ::= {id-oc 19}id-oc-pkiUser OBJECT IDENTIFIER ::= {id-oc 21}id-oc-pkiCA OBJECT IDENTIFIER ::= {id-oc 22}id-oc-deltaCRL OBJECT IDENTIFIER ::= {id-oc 23}id-oc-cpCps OBJECT IDENTIFIER ::= {id-oc 30}id-oc-pkiCertPath OBJECT IDENTIFIER ::= {id-oc 31}--формы имен--id-nf-cRLDistPtNameForm OBJECT IDENTIFIER ::= {id-nf 14}--атрибуты директории --id-at-userPassword OBJECT IDENTIFIER ::= {id-at 35}id-at-userCertificate OBJECT IDENTIFIER ::= {id-at 36}id-at-cAcertificate OBJECT IDENTIFIER ::= {id-at 37}id-at-authorityRevocationList OBJECT IDENTIFIER ::= {id-at 38}id-at-certificateRevocationList OBJECT IDENTIFIER ::= {id-at 39}id-at-crossCertificatePair OBJECT IDENTIFIER ::= {id-at 40}id-at-supportedAlgorithms OBJECT IDENTIFIER ::= {id-at 52}id-at-deltaRevocationList OBJECT IDENTIFIER ::= {id-at 53}id-at-certificationPracticeStmt OBJECT IDENTIFIER ::= {id-at 68}id-at-certificatePolicy OBJECT IDENTIFIER ::= {id-at 69}id-at-pkiPath OBJECT IDENTIFIER ::= {id-at 70}END-- A.3 Модуль расширений сертификатаCertificateExtensions {joint-iso-itu-t ds(5) module(1) certificateExtensions(26) 4}DEFINITIONS IMPLICIT TAGS ::=BEGINIMPORTSid-at, id-ce, id-mr, informationFramework, authenticationFramework,selectedAttributeTypes, upperBoundsFROM UsefulDefinitions {joint-iso-itu-t ds(5) module(1)usefulDefinitions(0) 4}Name, RelativeDistinguishedName, ATTRIBUTE, Attribute, MATCHING-RULEFROM InformationFramework informationFrameworkCertificateSerialNumber, CertificateList, AlgorithmIdentifier,EXTENSION, Time, PolicyIDFROM AuthenticationFramework authenticationFrameworkDirectoryStringFROM SelectedAttributeTypes selectedAttributeTypesub-nameFROM UpperBounds upperBoundsORAddressFROM MTSAbstractService {joint-iso-itu-t mhs(6) mts(3)modules(0) mts-abstract-service(1) version-1999 (1) } ;-- Сертификат открытого ключа и расширения CRL --authorityKeyIdentifier EXTENSION ::= {97

O′z DSt 1108:2006SYNTAX AuthorityKeyIdentifierIDENTIFIED BY id-ce-authorityKeyIdentifier }AuthorityKeyIdentifier ::= SEQUENCE {keyIdentifier [0] KeyIdentifier OPTIONAL,authorityCertIssuer [1] GeneralNames OPTIONAL,authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }( WITH COMPONENTS {..., authorityCertIssuer PRESENT,authorityCertSerialNumber PRESENT} |WITH COMPONENTS {..., authorityCertIssuer ABSENT,authorityCertSerialNumber ABSENT} )KeyIdentifier ::= OCTET STRINGsubjectKeyIdentifier EXTENSION ::= {SYNTAX SubjectKeyIdentifierIDENTIFIED BY id-ce-subjectKeyIdentifier }SubjectKeyIdentifier ::= KeyIdentifierkeyUsage EXTENSION ::= {SYNTAX KeyUsageIDENTIFIED BY id-ce-keyUsage }KeyUsage ::= BIT STRING {digitalSignature (0),nonRepudiation (1),keyEncipherment (2),dataEncipherment (3),keyAgreement (4),keyCertSign (5),cRLSign (6),encipherOnly (7),decipherOnly (8) }extKeyUsage EXTENSION ::= {SYNTAX SEQUENCE SIZE (1..MAX) OF KeyPurposeIdIDENTIFIED BY id-ce-extKeyUsage }KeyPurposeId ::= OBJECT IDENTIFIERprivateKeyUsagePeriod EXTENSION ::= {SYNTAX PrivateKeyUsagePeriodIDENTIFIED BY id-ce-privateKeyUsagePeriod }PrivateKeyUsagePeriod ::= SEQUENCE {notBefore [0] GeneralizedTime OPTIONAL,notAfter [1] GeneralizedTime OPTIONAL }( WITH COMPONENTS {..., notBefore PRESENT} |WITH COMPONENTS {..., notAfter PRESENT} )certificatePolicies EXTENSION ::= {SYNTAX CertificatePoliciesSyntaxIDENTIFIED BY id-ce-certificatePolicies }CertificatePoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformationPolicyInformation ::= SEQUENCE {policyIdentifier CertPolicyId,policyQualifiers SEQUENCE SIZE (1..MAX) OFPolicyQualifierInfo OPTIONAL }CertPolicyId ::= OBJECT IDENTIFIERPolicyQualifierInfo ::= SEQUENCE {policyQualifierId CERT-POLICY-QUALIFIER.&id({SupportedPolicyQualifiers}),qualifier CERT-POLICY-QUALIFIER.&Qualifier98

({SupportedPolicyQualifiers}{@policyQualifierId})OPTIONAL }SupportedPolicyQualifiers CERT-POLICY-QUALIFIER ::= { ... }anyPolicy OBJECT IDENTIFIER ::= { 2 5 29 32 0 }CERT-POLICY-QUALIFIER ::= CLASS {&id OBJECT IDENTIFIER UNIQUE,&Qualifier OPTIONAL }WITH SYNTAX {POLICY-QUALIFIER-ID &id[QUALIFIER-TYPE &Qualifier] }policyMappings EXTENSION ::= {SYNTAX PolicyMappingsSyntaxIDENTIFIED BY id-ce-policyMappings }PolicyMappingsSyntax ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {issuerDomainPolicy CertPolicyId,subjectDomainPolicy CertPolicyId }subjectAltName EXTENSION ::= {SYNTAX GeneralNamesIDENTIFIED BY id-ce-subjectAltName }GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralNameGeneralName ::= CHOICE {otherName [0] INSTANCE OF OTHER-NAME,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 }OTHER-NAME ::= TYPE-IDENTIFIEREDIPartyName ::= SEQUENCE {nameAssigner [0] DirectoryString {ub-name} OPTIONAL,partyName [1] DirectoryString {ub-name} }issuerAltName EXTENSION ::= {SYNTAX GeneralNamesIDENTIFIED BY id-ce-issuerAltName }subjectDirectoryAttributes EXTENSION ::= {SYNTAX AttributesSyntaxIDENTIFIED BY id-ce-subjectDirectoryAttributes }AttributesSyntax ::= SEQUENCE SIZE (1..MAX) OF AttributebasicConstraints EXTENSION ::= {SYNTAX BasicConstraintsSyntaxIDENTIFIED BY id-ce-basicConstraints }BasicConstraintsSyntax ::= SEQUENCE {cA BOOLEAN DEFAULT FALSE,pathLenConstraint INTEGER (0..MAX) OPTIONAL }nameConstraints EXTENSION ::= {SYNTAX NameConstraintsSyntaxIDENTIFIED BY id-ce-nameConstraints }O′z DSt 1108:2006NameConstraintsSyntax ::= SEQUENCE {permittedSubtrees [0] GeneralSubtrees OPTIONAL,99

O′z DSt 1108:2006excludedSubtrees [1] GeneralSubtrees OPTIONAL }GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtreeGeneralSubtree ::= SEQUENCE {base GeneralName,minimum [0] BaseDistance DEFAULT 0,maximum [1] BaseDistance OPTIONAL }BaseDistance ::= INTEGER (0..MAX)policyConstraints EXTENSION ::= {SYNTAX PolicyConstraintsSyntaxIDENTIFIED BY id-ce-policyConstraints }PolicyConstraintsSyntax ::= SEQUENCE {requireExplicitPolicy [0] SkipCerts OPTIONAL,inhibitPolicyMapping [1] SkipCerts OPTIONAL }SkipCerts ::= INTEGER (0..MAX)cRLNumber EXTENSION ::= {SYNTAX CRLNumberIDENTIFIED BY id-ce-cRLNumber }CRLNumber ::= INTEGER (0..MAX)reasonCode EXTENSION ::= {SYNTAX CRLReasonIDENTIFIED BY id-ce-reasonCode }CRLReason ::= ENUMERATED {unspecified (0),keyCompromise (1),cACompromise (2),affiliationChanged (3),superseded (4),cessationOfOperation (5),certificateHold (6),removeFromCRL (8),privilegeWithdrawn (9),aaCompromise (7) }holdInstructionCode EXTENSION ::= {SYNTAX HoldInstructionIDENTIFIED BY id-ce-instructionCode }HoldInstruction ::= OBJECT IDENTIFIERinvalidityDate EXTENSION ::= {SYNTAX GeneralizedTimeIDENTIFIED BY id-ce-invalidityDate }crlScope EXTENSION ::= {SYNTAX CRLScopeSyntaxIDENTIFIED BY id-ce-cRLScope }CRLScopeSyntax ::= SEQUENCE SIZE (1..MAX) OF PerAuthorityScopePerAuthorityScope ::= SEQUENCE {authorityName [0] GeneralName OPTIONAL,distributionPoint [1] DistributionPointName OPTIONAL,onlyContains [2] OnlyCertificateTypes OPTIONAL,onlySomeReasons [4] ReasonFlags OPTIONAL,serialNumberRange [5] NumberRange OPTIONAL,subjectKeyIdRange [6] NumberRange OPTIONAL,nameSubtrees [7] GeneralNames OPTIONAL,baseRevocationInfo [9] BaseRevocationInfo OPTIONAL}100

OnlyCertificateTypes ::= BIT STRING {user (0),authority (1),attribute (2) }NumberRange ::= SEQUENCE {startingNumber [0] INTEGER OPTIONAL,endingNumber [1] INTEGER OPTIONAL,modulus INTEGER OPTIONAL }BaseRevocationInfo ::= SEQUENCE {cRLStreamIdentifier [0] CRLStreamIdentifier OPTIONAL,cRLNumber[1] CRLNumber,baseThisUpdate [2] GeneralizedTime }statusReferrals EXTENSION ::= {SYNTAXStatusReferralsIDENTIFIED BY id-ce-statusReferrals }StatusReferrals ::= SEQUENCE SIZE (1..MAX) OF StatusReferralStatusReferral ::= CHOICE {cRLReferral [0] CRLReferral,otherReferral [1] INSTANCE OF OTHER-REFERRAL}CRLReferral ::= SEQUENCE {issuer [0] GeneralName OPTIONAL,location [1] GeneralName OPTIONAL,deltaRefInfo [2] DeltaRefInfo OPTIONAL,cRLScopeCRLScopeSyntax,lastUpdate [3] GeneralizedTime OPTIONAL,lastChangedCRL [4] GeneralizedTime OPTIONAL}DeltaRefInfo ::= SEQUENCE {deltaLocation GeneralName,lastDelta GeneralizedTime OPTIONAL }OTHER-REFERRAL ::= TYPE-IDENTIFIERcRLStreamIdentifier EXTENSION ::= {SYNTAX CRLStreamIdentifierIDENTIFIED BY id-ce-cRLStreamIdentifier }CRLStreamIdentifier ::= INTEGER (0..MAX)orderedList EXTENSION ::= {SYNTAX OrderedListSyntaxIDENTIFIED BY id-ce-orderedList }OrderedListSyntax ::= ENUMERATED {ascSerialNum (0),ascRevDate (1) }deltaInfo EXTENSION ::= {SYNTAX DeltaInformationIDENTIFIED BY id-ce-deltaInfo }DeltaInformation ::= SEQUENCE {deltaLocation GeneralName,nextDelta GeneralizedTime OPTIONAL }cRLDistributionPoints EXTENSION ::= {SYNTAX CRLDistPointsSyntaxIDENTIFIED BY id-ce-cRLDistributionPoints }CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPointO′z DSt 1108:2006DistributionPoint ::= SEQUENCE {distributionPoint [0] DistributionPointName OPTIONAL,101

O′z DSt 1108:2006reasons [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)}issuingDistributionPoint EXTENSION ::= {SYNTAX IssuingDistPointSyntaxIDENTIFIED BY id-ce-issuingDistributionPoint }IssuingDistPointSyntax ::= SEQUENCE {distributionPoint [0] DistributionPointName OPTIONAL,onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,onlyContainsAuthorityCerts [2] BOOLEAN DEFAULT FALSE,onlySomeReasons [3] ReasonFlags OPTIONAL,indirectCRL [4] BOOLEAN DEFAULT FALSE,onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }certificateIssuer EXTENSION ::= {SYNTAX GeneralNamesIDENTIFIED BY id-ce-certificateIssuer }deltaCRLIndicator EXTENSION ::= {SYNTAX BaseCRLNumberIDENTIFIED BY id-ce-deltaCRLIndicator }BaseCRLNumber ::= CRLNumberbaseUpdateTime EXTENSION ::= {SYNTAX GeneralizedTimeIDENTIFIED BY id-ce-baseUpdateTime }freshestCRL EXTENSION ::= {SYNTAX CRLDistPointsSyntaxIDENTIFIED BY id-ce-freshestCRL }inhibitAnyPolicy EXTENSION ::= {SYNTAX SkipCertsIDENTIFIED BY id-ce-inhibitAnyPolicy }-- Правила соответствия PKI --certificateExactMatch MATCHING-RULE ::= {SYNTAX CertificateExactAssertionID id-mr-certificateExactMatch }CertificateExactAssertion ::= SEQUENCE {serialNumber CertificateSerialNumber,issuer Name }certificateMatch MATCHING-RULE ::= {SYNTAX CertificateAssertionID id-mr-certificateMatch }102CertificateAssertion ::= SEQUENCE {

serialNumber [0] CertificateSerialNumber OPTIONAL,issuer [1] Name OPTIONAL,subjectKeyIdentifier [2] SubjectKeyIdentifier OPTIONAL,authorityKeyIdentifier [3] AuthorityKeyIdentifier OPTIONAL,certificateValid [4] Time OPTIONAL,privateKeyValid [5] GeneralizedTime OPTIONAL,subjectPublicKeyAlgID [6] OBJECT IDENTIFIER OPTIONAL,keyUsage [7] KeyUsage OPTIONAL,subjectAltName [8] AltNameType OPTIONAL,policy [9] CertPolicySet OPTIONAL,pathToName [7] Name OPTIONAL,subject [8] Name OPTIONAL,nameConstraints [12] NameConstraintsSyntax OPTIONAL }AltNameType ::= CHOICE {builtinNameForm ENUMERATED {rfc822Name (1),dNSName (2),x400Address (3),directoryName (4),ediPartyName (5),uniformResourceIdentifier (6),iPAddress (7),registeredId (8)},otherNameForm OBJECT IDENTIFIER }CertPolicySet ::= SEQUENCE SIZE (1..MAX) OF CertPolicyIdcertificatePairExactMatch MATCHING-RULE ::= {SYNTAX CertificatePairExactAssertionID id-mr-certificatePairExactMatch }CertificatePairExactAssertion ::= SEQUENCE {issuedToThisCAAssertion [0] CertificateExactAssertion OPTIONAL,issuedByThisCAAssertion [1] CertificateExactAssertion OPTIONAL }( WITH COMPONENTS {..., issuedToThisCAAssertion PRESENT} |WITH COMPONENTS {..., issuedByThisCAAssertion PRESENT} )certificatePairMatch MATCHING-RULE ::= {SYNTAX CertificatePairAssertionID id-mr-certificatePairMatch }CertificatePairAssertion ::= SEQUENCE {issuedToThisCAAssertion [0] CertificateAssertion OPTIONAL,issuedByThisCAAssertion [1] CertificateAssertion OPTIONAL }( WITH COMPONENTS {..., issuedToThisCAAssertion PRESENT} |WITH COMPONENTS {..., issuedByThisCAAssertion PRESENT} )certificateListExactMatch MATCHING-RULE ::= {SYNTAX CertificateListExactAssertionID id-mr-certificateListExactMatch }CertificateListExactAssertion ::= SEQUENCE {issuer Name,thisUpdate Time,distributionPoint DistributionPointName OPTIONAL OPTIONAL }certificateListMatch MATCHING-RULE ::= {SYNTAX CertificateListAssertionID id-mr-certificateListMatch }O′z DSt 1108:2006CertificateListAssertion ::= SEQUENCE {103

O′z DSt 1108:2006issuerName OPTIONAL,minCRLNumber [0] CRLNumber OPTIONAL,maxCRLNumber [1] CRLNumber OPTIONAL,reasonFlagsReasonFlags OPTIONAL,dateAndTimeTime OPTIONAL,distributionPoint [2] DistributionPointName OPTIONAL,authorityKeyIdentifier [3] AuthorityKeyIdentifier OPTIONAL}algorithmIdentifierMatch MATCHING-RULE ::= {SYNTAX AlgorithmIdentifierID id-mr-algorithmIdentifierMatch }policyMatch MATCHING-RULE ::= {SYNTAX PolicyIDID id-mr-policyMatch }pkiPathMatch MATCHING-RULE ::= {SYNTAX PkiPathMatchSyntaxID id-mr-pkiPathMatch }PkiPathMatchSyntax ::= SEQUENCE {firstIssuer Name,lastSubject Name }-- Присвоение (назначение) идентификатора Объекта --id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= {id-ce 9}id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 14}id-ce-keyUsage OBJECT IDENTIFIER ::= {id-ce 15}id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= {id-ce 16}id-ce-subjectAltName OBJECT IDENTIFIER ::= {id-ce 17}id-ce-issuerAltName OBJECT IDENTIFIER ::= {id-ce 18}id-ce-basicConstraints OBJECT IDENTIFIER ::= {id-ce 19}id-ce-cRLNumber OBJECT IDENTIFIER ::= {id-ce 20}id-ce-reasonCode OBJECT IDENTIFIER ::= {id-ce 21}id-ce-instructionCode OBJECT IDENTIFIER ::= {id-ce 23}id-ce-invalidityDate OBJECT IDENTIFIER ::= {id-ce 24}id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= {id-ce 27}id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= {id-ce 28}id-ce-certificateIssuer OBJECT IDENTIFIER ::= {id-ce 29}id-ce-nameConstraints OBJECT IDENTIFIER ::= {id-ce 30}id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31}id-ce-certificatePolicies OBJECT IDENTIFIER ::= {id-ce 32}id-ce-policyMappings OBJECT IDENTIFIER ::= {id-ce 33}OBJECT IDENTIFIER ::= {id-ce 34}id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 35}id-ce-policyConstraints OBJECT IDENTIFIER ::= {id-ce 36}id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37}id-ce-cRLStreamIdentifier OBJECT IDENTIFIER ::= {id-ce 40}id-ce-cRLScope OBJECT IDENTIFIER ::= {id-ce 44}id-ce-statusReferrals OBJECT IDENTIFIER ::= {id-ce 45}id-ce-freshestCRL OBJECT IDENTIFIER ::= {id-ce 46}id-ce-orderedList OBJECT IDENTIFIER ::= {id-ce 47}id-ce-baseUpdateTime OBJECT IDENTIFIER ::= {id-ce 51}id-ce-deltaInfo OBJECT IDENTIFIER ::= {id-ce 53}id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= {id-ce 54}104-- правило соответствия OID --id-mr-certificateExactMatch OBJECT IDENTIFIER ::= {id-mr 34}

O′z DSt 1108:2006id-mr-certificateMatch OBJECT IDENTIFIER ::= {id-mr 35}id-mr-certificatePairExactMatch OBJECT IDENTIFIER ::= {id-mr 36}id-mr-certificatePairMatch OBJECT IDENTIFIER ::= {id-mr 37}id-mr-certificateListExactMatch OBJECT IDENTIFIER ::= {id-mr 38}id-mr-certificateListMatch OBJECT IDENTIFIER ::= {id-mr 39}id-mr-algorithmIdentifierMatch OBJECT IDENTIFIER ::= {id-mr 40}id-mr-policyMatch OBJECT IDENTIFIER ::= {id-mr 60}id-mr-pkiPathMatch OBJECT IDENTIFIER ::= {id-mr 62}-- Следующие Идентификаторы Объекта (OBJECT IDENTIFIERS) не используются вэтом стандарте:-- {id-ce 2}, {id-ce 3}, {id-ce 4}, {id-ce 5}, {id-ce 6}, {id-ce 7},-- {id-ce 8}, {id-ce 7}, {id-ce 8}, {id-ce 12}, {id-ce 13},-- {id-ce 22}, {id-ce 25}, {id-ce 26}END-- A.4 Модуль Структуры Сертификата АтрибутаAttributeCertificateDefinitions {joint-iso-itu-t ds(5) module(1)attributeCertificateDefinitions(32) 4}DEFINITIONS IMPLICIT TAGS ::=BEGINIMPORTSid-at, id-ce, id-mr, informationFramework, authenticationFramework,selectedAttributeTypes, upperBounds, id-oc, certificateExtensionsFROM UsefulDefinitions {joint-iso-itu-t ds(5) module(1)usefulDefinitions(0) 4}Name, RelativeDistinguishedName, ATTRIBUTE, Attribute,MATCHING-RULE, AttributeType, OBJECT-CLASS, topFROM InformationFramework informationFrameworkCertificateSerialNumber, CertificateList, AlgorithmIdentifier,EXTENSION, SIGNED, InfoSyntax, PolicySyntax, Extensions, CertificateFROM AuthenticationFramework authenticationFrameworkDirectoryString, TimeSpecification, UniqueIdentifierFROM SelectedAttributeTypes selectedAttributeTypesGeneralName, GeneralNames, NameConstraintsSyntax, certificateListExactMatchFROM CertificateExtensions certificateExtensionsub-nameFROM UpperBounds upperBoundsUserNoticeFROM PKIX1Implicit93 {iso(1) identified-organization(3) dod(6) internet(1)security(5) mechanisms(5)pkix(7) id-mod(0) id-pkix1-implicit-93(4)}ORAddressFROM MTSAbstractService {joint-iso-itu-t mhs(6) mts(3)modules(0) mts-abstract-service(1) version-1999 (1) } ;AttributeCertificate ::= SIGNED {AttributeCertificateInfo}AttributeCertificateInfo ::= SEQUENCE{version AttCertVersion, -- version is v2holderHolder,issuerAttCertIssuer,signatureAlgorithmIdentifier,serialNumberCertificateSerialNumber,attrCertValidityPeriod AttCertValidityPeriod,attributesSEQUENCE OFAttribute,105

O′z DSt 1108:2006issuerUniqueIDUniqueIdentifier OPTIONAL,extensions Extensions OPTIONAL}AttCertVersion ::= INTEGER {v1(0), v2(1) }Holder ::= SEQUENCE{baseCertificateID [0] IssuerSerial OPTIONAL,-- издатель и серийный номер сертификата открытого ключа хранителяentityName[1] GeneralNames OPTIONAL,-- имя объекта или ролиobjectDigestInfo [2] ObjectDigestInfo OPTIONAL}ObjectDigestInfo ::= SEQUENCE {digestedObjectType ENUMERATED {publicKey (0),publicKeyCert (1),otherObjectTypes (2) },otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,digestAlgorithm AlgorithmIdentifier,objectDigest BIT STRING }AttCertIssuer ::= [0] SEQUENCE {issuerName GeneralNames OPTIONAL,baseCertificateID [0] IssuerSerial OPTIONAL,objectDigestInfo [1] ObjectDigestInfo OPTIONAL }-- По крайне мере одна компонента должна быть представлена( WITH COMPONENTS { ..., issuerName PRESENT } |WITH COMPONENTS { ..., baseCertificateID PRESENT } |WITH COMPONENTS { ..., objectDigestInfo PRESENT } )IssuerSerial ::= SEQUENCE {issuerGeneralNames,serialCertificateSerialNumber,issuerUID UniqueIdentifier OPTIONAL }AttCertValidityPeriod ::= SEQUENCE {notBeforeTime GeneralizedTime,notAfterTime GeneralizedTime }AttributeCertificationPath ::= SEQUENCE {attributeCertificate AttributeCertificate,acPath SEQUENCE OF ACPathData OPTIONAL }ACPathData ::= SEQUENCE {certificate [0] Certificate OPTIONAL,attributeCertificate [1] AttributeCertificate OPTIONAL }PrivilegePolicy ::= OBJECT IDENTIFIER-- атрибуты привилегий --role ATTRIBUTE ::= {WITH SYNTAX RoleSyntaxID id-at-role }RoleSyntax ::= SEQUENCE {roleAuthority [0] GeneralNames OPTIONAL,roleName [1] GeneralName }-- Классы объекта PMI --pmiUser OBJECT-CLASS ::= {SUBCLASS OF {top}KIND auxiliaryMAY CONTAIN {attributeCertificateAttribute}106

O′z DSt 1108:2006ID id-oc-pmiUser}pmiAA OBJECT-CLASS ::= {-- a PMI AASUBCLASS OF {top}KIND auxiliaryMAY CONTAIN {aACertificate |attributeCertificateRevocationList |attributeAuthorityRevocationList}ID id-oc-pmiAA}pmiSOA OBJECT-CLASS ::= { -- источник полномочий PMISUBCLASS OF {top}KIND auxiliaryMAY CONTAIN {attributeCertificateRevocationList |attributeAuthorityRevocationList |attributeDescriptorCertificate}ID id-oc-pmiSOA}attCertCRLDistributionPt OBJECT-CLASS ::= {SUBCLASS OF {top}KIND auxiliaryMAY CONTAIN { attributeCertificateRevocationList |attributeAuthorityRevocationList }ID id-oc-attCertCRLDistributionPts}pmiDelegationPath OBJECT-CLASS ::= {SUBCLASS OF {top}KIND auxiliaryMAY CONTAIN { delegationPath }ID id-oc-pmiDelegationPath }privilegePolicy OBJECT-CLASS ::= {SUBCLASS OF {top}KIND auxiliaryMAY CONTAIN {privPolicy }ID id-oc-privilegePolicy }-- Атрибуты директории PMI --attributeCertificateAttribute ATTRIBUTE ::= {WITH SYNTAX AttributeCertificateEQUALITY MATCHING RULE attributeCertificateExactMatchID id-at-attributeCertificate }aACertificate ATTRIBUTE ::= {WITH SYNTAX AttributeCertificateEQUALITY MATCHING RULE attributeCertificateExactMatchID id-at-aACertificate }attributeDescriptorCertificate ATTRIBUTE ::= {WITH SYNTAX AttributeCertificateEQUALITY MATCHING RULE attributeCertificateExactMatchID id-at-attributeDescriptorCertificate }attributeCertificateRevocationList ATTRIBUTE ::= {WITH SYNTAX CertificateListEQUALITY MATCHING RULE certificateListExactMatchID id-at-attributeCertificateRevocationList}107

O′z DSt 1108:2006attributeAuthorityRevocationList ATTRIBUTE ::= {WITH SYNTAX CertificateListEQUALITY MATCHING RULE certificateListExactMatchID id-at-attributeAuthorityRevocationList }delegationPath ATTRIBUTE ::= {WITH SYNTAX AttCertPathID id-at-delegationPath }AttCertPath ::= SEQUENCE OF AttributeCertificateprivPolicy ATTRIBUTE ::= {WITH SYNTAX PolicySyntaxID id-at-privPolicy }--Расширения сертификата атрибута и правила соответствия --attributeCertificateExactMatch MATCHING-RULE ::= {SYNTAX AttributeCertificateExactAssertionID id-mr-attributeCertificateExactMatch }AttributeCertificateExactAssertion ::= SEQUENCE {serialNumber CertificateSerialNumber OPTIONAL,issuer IssuerSerial}attributeCertificateMatch MATCHING-RULE ::= {SYNTAX AttributeCertificateAssertionID id-mr-attributeCertificateMatch }AttributeCertificateAssertion ::= SEQUENCE {holder [0] CHOICE {baseCertificateID [0] IssuerSerial,holderName [1] GeneralNames} OPTIONAL,issuer [1] GeneralNames OPTIONAL,attCertValidity [2] GeneralizedTime OPTIONAL,attType [3] SET OF AttributeType OPTIONAL}-- По крайне мере одна компонента последовательности должна присутствоватьholderIssuerMatch MATCHING-RULE ::= {SYNTAX HolderIssuerAssertionID id-mr-holderIssuerMatch }HolderIssuerAssertion ::= SEQUENCE {holder [0] Holder OPTIONAL,issuer [1] AttCertIssuer OPTIONAL}delegationPathMatch MATCHING-RULE ::= {SYNTAX DelMatchSyntaxID id-mr-delegationPathMatch }DelMatchSyntax ::= SEQUENCE {firstIssuer AttCertIssuer,lastHolder Holder }sOAIdentifier EXTENSION ::= {SYNTAX NULLIDENTIFIED BY id-ce-sOAIdentifier }authorityAttributeIdentifier EXTENSION ::={SYNTAX AuthorityAttributeIdentifierSyntaxIDENTIFIED BY { id-ce-authorityAttributeIdentifier } }AuthorityAttributeIdentifierSyntax ::= SEQUENCE SIZE (1..MAX) OF AuthAttIdAuthAttId ::= IssuerSerialauthAttIdMatch MATCHING-RULE ::= {108

SYNTAX AuthorityAttributeIdentifierSyntaxID id-mr-authAttIdMatch }roleSpecCertIdentifier EXTENSION ::={SYNTAX RoleSpecCertIdentifierSyntaxIDENTIFIED BY { id-ce-roleSpecCertIdentifier } }RoleSpecCertIdentifierSyntax ::= SEQUENCE SIZE (1..MAX) OFRoleSpecCertIdentifierRoleSpecCertIdentifier ::= SEQUENCE {roleName [0] GeneralName,roleCertIssuer [1] GeneralName,roleCertSerialNumber [2] CertificateSerialNumber OPTIONAL,roleCertLocator [3] GeneralNames OPTIONAL }roleSpecCertIdMatch MATCHING-RULE ::= {SYNTAX RoleSpecCertIdentifierSyntaxID id-mr-roleSpecCertIdMatch }basicAttConstraints EXTENSION ::={SYNTAXBasicAttConstraintsSyntaxIDENTIFIED BY { id-ce-basicAttConstraints }}BasicAttConstraintsSyntax ::= SEQUENCE{authorityBOOLEAN DEFAULT FALSE,pathLenConstraint INTEGER (0..MAX) OPTIONAL}basicAttConstraintsMatch MATCHING-RULE ::= {SYNTAX BasicAttConstraintsSyntaxID id-mr-basicAttConstraintsMatch }delegatedNameConstraints EXTENSION ::= {SYNTAX NameConstraintsSyntaxIDENTIFIED BY id-ce-delegatedNameConstraints }delegatedNameConstraintsMatch MATCHING-RULE ::= {SYNTAX NameConstraintsSyntaxID id-mr-delegatedNameConstraintsMatch}timeSpecification EXTENSION ::= {SYNTAX TimeSpecificationIDENTIFIED BY id-ce-timeSpecification }timeSpecificationMatch MATCHING-RULE ::= {SYNTAX TimeSpecificationID id-mr-timeSpecMatch }acceptableCertPolicies EXTENSION ::= {SYNTAX AcceptableCertPoliciesSyntaxIDENTIFIED BY id-ce-acceptableCertPolicies }O′z DSt 1108:2006AcceptableCertPoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF CertPolicyIdCertPolicyId ::= OBJECT IDENTIFIERacceptableCertPoliciesMatch MATCHING-RULE ::= {SYNTAX AcceptableCertPoliciesSyntaxID id-mr-acceptableCertPoliciesMatch }attributeDescriptor EXTENSION ::= {SYNTAX AttributeDescriptorSyntaxIDENTIFIED BY {id-ce-attributeDescriptor } }109

O′z DSt 1108:2006AttributeDescriptorSyntax ::= SEQUENCE {identifierAttributeIdentifier,attributeSyntax OCTET STRING (SIZE(1..MAX)),name [0] AttributeName OPTIONAL,description [1] AttributeDescription OPTIONAL,dominationRule PrivilegePolicyIdentifier}AttributeIdentifier ::= ATTRIBUTE.&id({AttributeIDs})AttributeIDs ATTRIBUTE ::= {...}AttributeName ::= UTF8String(SIZE(1..MAX))AttributeDescription ::= UTF8String(SIZE(1..MAX))PrivilegePolicyIdentifier ::= SEQUENCE {privilegePolicy PrivilegePolicy,privPolSyntax InfoSyntax }attDescriptor MATCHING-RULE ::= {SYNTAX AttributeDescriptorSyntaxID id-mr-attDescriptorMatch }userNotice EXTENSION ::= {SYNTAX SEQUENCE SIZE (1..MAX) OF UserNoticeIDENTIFIED BY id-ce-userNotice }targetingInformation EXTENSION ::= {SYNTAX SEQUENCE SIZE (1..MAX) OF TargetsIDENTIFIED BY id-ce-targetInformation }Targets ::= SEQUENCE SIZE (1..MAX) OF TargetTarget ::= CHOICE {targetName [0] GeneralName,targetGroup [1] GeneralName,targetCert [2] TargetCert }TargetCert ::= SEQUENCE {targetCertificate IssuerSerial,targetName GeneralName OPTIONAL,certDigestInfo ObjectDigestInfo OPTIONAL }noRevAvail EXTENSION ::= {SYNTAX NULLIDENTIFIED BY id-ce-noRevAvail }acceptablePrivilegePolicies EXTENSION ::= {SYNTAX AcceptablePrivilegePoliciesSyntaxIDENTIFIED BY id-ce-acceptablePrivilegePolicies }AcceptablePrivilegePoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PrivilegePolicy-- присвоение (назначение) идентификатора объекта-- классы объекта --id-oc-pmiUser OBJECT IDENTIFIER ::= {id-oc 24}id-oc-pmiAA OBJECT IDENTIFIER ::= {id-oc 25}id-oc-pmiSOA OBJECT IDENTIFIER ::= {id-oc 26}id-oc-attCertCRLDistributionPts OBJECT IDENTIFIER ::= {id-oc 27}id-oc-privilegePolicy OBJECT IDENTIFIER ::= {id-oc 32}id-oc-pmiDelegationPath OBJECT IDENTIFIER ::= {id-oc 33}-- атрибуты директории --id-at-attributeCertificate OBJECT IDENTIFIER ::= {id-at 58}id-at-attributeCertificateRevocationList OBJECT IDENTIFIER ::= {id-at 59}id-at-aACertificate OBJECT IDENTIFIER ::= {id-at 61}id-at-attributeDescriptorCertificate OBJECT IDENTIFIER ::= {id-at 62}id-at-attributeAuthorityRevocationList OBJECT IDENTIFIER ::= {id-at 63}id-at-privPolicy OBJECT IDENTIFIER ::= {id-at 71}110

O′z DSt 1108:2006id-at-role OBJECT IDENTIFIER ::= {id-at 72}id-at-delegationPath OBJECT IDENTIFIER ::= {id-at 73}--расширение сертификата атрибута --id-ce-authorityAttributeIdentifier OBJECT IDENTIFIER ::= {id-ce 38}id-ce-roleSpecCertIdentifier OBJECT IDENTIFIER ::= {id-ce 39}id-ce-basicAttConstraints OBJECT IDENTIFIER ::= {id-ce 41}id-ce-delegatedNameConstraints OBJECT IDENTIFIER ::= {id-ce 42}id-ce-timeSpecification OBJECT IDENTIFIER ::= {id-ce 43}id-ce-attributeDescriptor OBJECT IDENTIFIER ::= {id-ce 48}id-ce-userNotice OBJECT IDENTIFIER ::= {id-ce 49}id-ce-sOAIdentifier OBJECT IDENTIFIER ::= {id-ce 50}id-ce-acceptableCertPolicies OBJECT IDENTIFIER ::= {id-ce 52}id-ce-targetInformation OBJECT IDENTIFIER ::= {id-ce 55}id-ce-noRevAvail OBJECT IDENTIFIER ::= {id-ce 56}id-ce-acceptablePrivilegePolicies OBJECT IDENTIFIER ::= {id-ce 57}-- правила соответствия PMI --id-mr-attributeCertificateMatch OBJECT IDENTIFIER ::= {id-mr 42}id-mr-attributeCertificateExactMatch OBJECT IDENTIFIER ::= {id-mr 45}id-mr-holderIssuerMatch OBJECT IDENTIFIER ::= {id-mr 46}id-mr-authAttIdMatch OBJECT IDENTIFIER ::= {id-mr 53}id-mr-roleSpecCertIdMatch OBJECT IDENTIFIER ::= {id-mr 54}id-mr-basicAttConstraintsMatch OBJECT IDENTIFIER ::= {id-mr 55}id-mr-delegatedNameConstraintsMatch OBJECT IDENTIFIER ::= {id-mr 56}id-mr-timeSpecMatch OBJECT IDENTIFIER ::= {id-mr 57}id-mr-attDescriptorMatch OBJECT IDENTIFIER ::= {id-mr 58}id-mr-acceptableCertPoliciesMatch OBJECT IDENTIFIER ::= {id-mr 59}id-mr-delegationPathMatch OBJECT IDENTIFIER ::= {id-mr 61}END111

O′z DSt 1108:2006Приложение B(обязательное)Правила генерации и обработки CRL112B.1 ВведениеB.1.1 Типы CRLДоверяющей стороне (пользователь сертификата) необходимо иметь возможностьпроверять статус сертификата для того, чтобы облегчить принятие решения о достоверностиэтого сертификата. Списки аннулированных сертификатов (CRL) являются одним измеханизмов, используемых доверяющими сторонами, чтобы получить эту информацию.Также могут быть использованы и другие механизмы, обсуждение которых находится заобластью рассмотрения данного стандарта.Данное приложение описывает использование доверяющей стороной спискованнулированных сертификатов для проверки статуса аннулирования проверяемогосертификата. Различные органы могут иметь различную политику по отношению изданиясписков аннулирования. Некоторые органы могут объединить аннулирование сертификатаконечного объекта и сертификатов ЦР в один список, в то время как другие органы могутразделить их на различные списки. Некоторые органы могут разделить их совокупность(семейство) сертификата на фрагменты CRL, а некоторые органы могут издать дельтаобновления на список аннулирования между регулярными интервалами CRL. В результатедоверяющим сторонам необходимо иметь возможность определения границ CRL, которыеони восстанавливают, чтобы дать им возможность гарантировать, что они имеют полныйнабор информации об аннулировании. Расширение clrScope может быть использовано какодин из механизмов для определения области. Данное приложение предоставляет механизм,который может быть использован в случае отсутствия расширения crlScope в CRL.Данное приложение написано для проверки статуса аннулирования сертификатовоткрытого ключа, использующих CRL, CRL конечного объекта и CARL. Однако, этоописание также может быть применено для проверки статуса аннулирования сертификатоватрибута, использующих списки аннулированных сертификатов атрибута (ACRL) и спискианнулированных органов по распределению атрибутов (AARL). В данном приложенииACRL может рассматриваться вместо CRL и AARL вместо CARL.Доверяющей стороне могут быть доступны один или более одного CRL следующихтипов основанных на аспектах аннулирования:- полный и завершенный CRL;- полный и завершенный CRL конечного объекта (EERL);- полный и завершенный Список Аннулированных Центров регистрации (CARL);- пункт распределения CRL, ACRL конечного объекта или CARL;- косвенный CRL, ACRL конечного объекта или CARL;- дельта CRL, ACRL конечного объекта или CARL;- косвенный дельта CRL, ACRL конечного объекта или CARL.Полный и завершенный CRL - это список всех аннулированных сертификатовконечных объектов и сертификатов ЦР, которые были изданы по различным причинам состороны органа.Полный и завершенный ACRL конечного объекта - это список всех аннулированныхсертификатов конечных объектов, которые были изданы со стороны органа по различнымпричинам.Полный и завершенный CARL - это список аннулированных сертификатов ЦР, которыебыли изданы со стороны органа по различным причинам.Пункт распределения CRL, ACRL конечного объекта или CARL это пункт, которыйохватывает все или подмножество сертификатов, изданных со стороны органа.Подмножество может основывается на различных критериях.

O′z DSt 1108:2006Косвенный CRL, ACRL конечного объекта или CARL (iCRL) - это CRL, которыйсодержит список аннулированных сертификатов, в котором некоторые или все изсертификатов не были изданы со стороны органа, подписывающего и издающего CRL.Дельта CRL, ACRL конечного объекта или CARL - это CRL, который содержит толькоизменения CRL и который является завершенным для данной области.Необходимо заметить, что сосланный CRL может быть единственным CRL, которыйявляется завершенным для данной области, или может являться dCRL, который используетсядля локального построения CRL, который является завершенным для данной области. Всеперечисленные выше типы CRL (за исключением dCRL) это такие CRL, которые являютсязавершенными, для своих областей. dCRL будет использован совместно с ассоциированнымCRL, который является завершенным для той же области, для того, чтобы формироватьполное представление о статусе аннулирования сертификатов.Косвенный дельта CRL, EERL или CARL является CRL, который содержит толькоизменения к одному или к нескольким наборам CRL, которые являются завершенными длясвоих областей и в которых несколько или все из этих сертификатов не могут быть изданысо стороны органа, который и подписывает и издает этот CRL.Внутри этого приложения «Область CRL» определена двумя независимымиизмерениями. Первое измерение это набор сертификатов, охватываемых CRL. Второеизмерение это набор кодов причин, охватываемых CRL. Область CRL может бытьопределена одним или несколькими из следующих путей:- из расширения издающего пункта распределения (IDP) в CRL;- из расширения области применения CRL в CRL;- другими способами, выходящими за пределы рассмотрения данного стандарта.B.1.2 Обработка CRLЕсли доверяющие стороны используют CRL как механизм определения аннулированиясертификата, то они должны быть уверены, что используют соответствующий CRL для этогосертификата. Это приложение описывает процедуру получения и обработкисоответствующих CRL посредством нескольких специфических шагов. Реализация будетфункционально эквивалентной внешнему режиму работы, получающемуся в результате этойпроцедуры. Алгоритм, используемый специфической реализацией для полученияправильных выходных параметров (т.е. статуса аннулирования сертификата) из данныхвходных параметров (сам сертификат и входные параметры из локальной политики), нестандартизируется.Данное приложение не включает процедуры для следующих указателей конструкцииCRL, содержащей расширение statusReferrals. Любой CRL, содержащий это расширение, небудет использован в качестве источника для проверки статуса аннулирования любогосертификата доверяющей стороной. Скорее всего, CRL, содержащий это расширение можетбыть использован со доверяющей стороной, как дополнительный инструмент длянахождения соответствующих CRL для проверки статуса аннулирования.В нижеприведенных пунктах с B.2 по B.5 описаны общие шаги:1) определение параметров для CRL;2) определение необходимых CRL;3) получение CRL;4) обработка CRL.Шаг 1) указывает параметры из сертификата, которые будут использованы дляопределения, какие типы CRL необходимы.Шаг 2) применяет значения параметров для принятия решения.Шаг 3) идентифицирует атрибуты директории, из которых могут быть извлечены типыCRL.Шаг 4) описывает обработку соответствующих CRL.113

O′z DSt 1108:2006B.2 Определение параметров для CRLИнформация, расположенная в самом сертификате, так же как и информация изполитики, согласно которой действует доверяющая сторона, предоставляют параметры дляопределения соответствия кандидатов CRL. Следующая информация необходима дляопределения типов CRL, являющихся подходящими:- тип сертификата (т.е. сертификат конечного объекта или ЦР);- пункт распределения критического CRL;- критический самый новый CRL;- код причины важности.Тип сертификата может быть определен из расширений базового ограничениясертификата. Если расширение существует, то оно определяет то, что является лисертификат сертификатом ЦР или сертификатом конечного объекта. Если расширениеотсутствует, то тип сертификата рассматривается, как сертификат конечного объекта. Этаинформация необходима для определения того, что можно ли использовать CRL, EERL илиCARL для проверки сертификата на аннулирование.Если сертификат содержит критическое расширение пункта распределения CRL, тосистема обработки сертификата доверяемой стороны должна понимать это расширение длятого, чтобы возможно было доверять сертификату. Доверие на полный CRL, может быть недостаточным.Если сертификат содержит расширение критического самого нового CRL, тодоверяющая сторона не может использовать сертификат без предварительного получения ипроверки самого нового CRL.Коды причины важности определяются политикой и обычно поддерживаютсяприложениями. Они должны включать в себя все коды причины. Эта информациянеобходима для определения, какие CRL являются достаточными относительно кодапричины.Нужно заметить, что политика также может определять полагается ли проверятьдоверяемой стороне dCRL на статус аннулирования, даже когда расширение freshnestCRLустановлено как некритическое или отсутствует в сертификате. Несмотря на то, чтообработка этих необязательных dCRL исключена из этого шага, они описаны в шаге 4).114B.3 Определение необходимых CRLB.3.1 Конечный объект с критическим CRL DPЗначения параметров, описанных в B.2 определяют критерии, в которых требуютсятипы CRL для определения статуса аннулирования данного сертификата. Определение типовCRL может быть осуществлено на основе следующего набора критериев, как это описанониже в пунктах с B.3.1 по B.3.4:- сертификат конечного объекта с предъявленным критическим CRL DP;- сертификат конечного объекта без предъявленного критического CRL DP;- сертификат ЦР с предъявленным критическим CRL DP;- сертификат ЦР без предъявленного критического CRL DP.Обработка остальных параметров приводиться внутри каждого раздела.Если сертификат является сертификатом конечного объекта и в нём присутствуетрасширение cRLDistributionPoints, а также если это расширение отмечено как критическое,то будут получены следующие CRL:- CRL из одного из назначенных пунктов распределения CRL, который охватывает одинили несколько кодов причин важности;- если все коды причин важности не охвачены этим CRL, статус аннулирования дляостальных кодов важности может быть удовлетворен комбинацией любой, из следующихCRL:- дополнительный пункт распределения CRL;- дополнительный полный CRL;

O′z DSt 1108:2006- дополнительные полный EERL.Если расширение самого нового CRL также присутствует в сертификате и отмечено каккритическое, то один или несколько CRL будут также получены из одного или несколькихпунктов распределения, назначенных в этом расширении.B.3.2 Конечный объект с некритическим CRL DPЕсли сертификат является сертификатом конечного объекта, и расширениеcRLDistributionPoints отсутствует в сертификате, или же присутствует, но не отмечено каккритическое, то статус аннулирования для кодов причин важности может быть удовлетворенлюбой комбинацией следующих CRL:- CRL пунктов распределения (если присутствует);- полный CRL;- полный EPRL.Если расширение самого нового CRL также присутствует в сертификате и еслиотмечено как критическое, один или несколько CRL будут также получены из одного илинескольких назначенных в этом расширении пунктов распределения.B.3.3 ЦР с критическим CRL DPЕсли сертификат является сертификатом РОМ и расширение cRLDistributionPointsприсутствует в сертификате и отмечено как критическое, то будут получены следующиеCRL/CARL:- CRL или CARL из одного назначенного пункта распределения, который покрываетодин или несколько кодов причин важности;- если все коды причин важности не охвачены этим CRL/CARL, статус аннулированиядля остальных кодов важности может быть удовлетворен любой комбинацией следующихCRL/CARL:- дополнительный пункт распределения CRL/CARL;- дополнительные полный CRL;- дополнительный полный CARL.Если расширение самого нового CRL также присутствует в сертификате и отмечено каккритическое, то один или более CRL/CARL также будут получены из одного или болееназначенных в этом расширении пунктов распределения.B.3.4 ЦР без критического CRL DPЕсли сертификат является сертификатом ЦР и расширение cRLDistributionPointsотсутствует в сертификате или же присутствует, но отмечено как некритическое, то статусаннулирования для кодов причин важности могут быть удовлетворены любой комбинациейследующих CRL:- пункт распределения CRL/CARL (если присутствует);- полный CRL;- полный CARL.Если расширение самого нового CRL также присутствует в сертификате и отмечено каккритическое, то один или более CRL/CARL будут также получены из одного или несколькихназначенных в этом расширении пунктов распределения.B.4 Получение CRLЕсли доверяющая сторона получает подходящие CRL из директории, то эти CRL насамом деле получаются (извлекаются) из CRL DP или из элемента директории издателясертификата, извлекая соответствующие атрибуты, т.е. из следующих атрибутов:- список аннулированных сертификатов;- список аннулированных органов;- дельта список аннулирования.115

O′z DSt 1108:2006B.5 Обработка CRLB.5.1 Утверждение базовой области CRLB.5.1.1 Полный CRLПосле рассмотрения параметров, приведенных в подразделе B.2, определениеподходящих типов CRL, как это описано в подразделе B.3 и получение подходящего набораCRL как это описано в B.4, доверяющая сторона готова обработать CRL. Набор CRL будетсодержать по крайне мере один базовый CRL и может также содержать один или болееdCRL. При каждой обработке CRL, доверяющая сторона должна гарантировать, что CRLявляется правильным по отношению к своей области. Доверяющая сторона к этому времениуже определит, что CRL является подходящим для области интересующего сертификата порезультатам обработки, приведенным в пунктах B.2 и B.3. Кроме того, проверки надействительность будут вестись над CRL и они будут проверяться для определения, являетсяли сертификат аннулированным. Эти проверки описаны в подразделах с B.5.1 по B.5.4.Как описано в подразделе B.3, возможно будет существовать более чем один тип CRL,который можно будет использовать как базовый CRL для проверки статуса аннулированиясертификата. В зависимости от политики издающего органа по отношению издания CRL,доверяющая сторона может иметь один или несколько следующих базовых типов CRLдоступных для него:- завершенный CRL для всех объектов;- завершенный EERL;- завершенный CARL;- пункт распределения основанный на CRL/EPRL/CARL.Подпункты с B.5.1.1 по B.5.1.4 предоставляют набор условий, которые будут иметьзначение true, надлежащим образом, для использования доверяющей стороной каждого типаCRL как базового CRL, для проверки статуса аннулирования сертификата для кода причиныважности.Для того, чтобы определить, что CRL является полным для сертификата конечногообъекта и сертификата ЦР для всех кодов причин важности, должны удовлетворятсяследующие условия:- расширение индикатора дельта CRL должно отсутствовать; и- расширение издающего пункта распределения может отсутствовать; и- расширение издающего пункта распределения не должно содержать поле пунктараспределения;- расширение издающего пункта распределения не должно содержать полеonlyContainsUserCerts с установленным значением true;- расширение издающего пункта распределения не должно содержать полеonlyContainsAuthorityCerts с установленным значением true; и- расширение издающего пункта распределения не должно содержать полеonlyContainsAttributCerts с установленным значением true;и- если поле reasonCodes присутствует в расширении издающего пункта распределения,то поле кодов причин должно включать все причины важности для приложения; и- расширение издающего пункта распределения должно или не должно содержать полеindirectCRL (следовательно, это поле необязательно проверять).B.5.1.2 Завершенный EERLДля того чтобы определить, что CRL является завершенным EERL для кодов причинважности, должны удовлетворятся все следующие условия:- расширение индикатора дельта CRL должно отсутствовать;- расширение издающего пункта распределения должно присутствовать;- расширение издающего пункта распределения не должно содержать поле пунктараспределения;116

O′z DSt 1108:2006- расширение издающего пункта распределения должно содержать полеonlyContainsUserCerts. Значение этого поля должно быть установлено на true;- расширение издающего пункта распределения не должно содержать полеonlyContainsAuthorityCerts с установленным значением true;- расширение издающего пункта распределения не должно содержать полеonlyContainsAttributeCerts с установленным значением true;- если поле reasonCodes присутствует в расширении издающего пункта распределения,то поле кодов причин должно включать все причины важности для приложения;- расширение издающего пункта распределения может или не может содержать полеindirectCRL (следовательно, это поле необязательно проверять).Этот CRL может быть использован, только если доверяющая сторона определила, чтосертификат субъекта является сертификатом конечного объекта. Таким образом, длясертификатов версии 3, если сертификат субъекта содержит расширение basicConstraints, тоего значение должно быть cA=FALSE.B.5.1.3 Завершенный CARLДля того чтобы определить, что CRL является завершенным CARL для кодов причинважности, должны удовлетворятся все следующие условия:- расширение индикатора дельта CRL должно отсутствовать; и- должно присутствовать расширение Издающего пункта распределения; и- расширение издающего пункта распределения не должно содержать поле пунктараспределения; и- расширение издающего пункта распределения не должно содержать полеonlyContainsUserCerts с установленным значением true;- расширение издающего пункта распределения не должно содержать полеonlyContainsAttributeCerts с установленным значением true;- расширение издающего пункта распределения должно содержать в себе полеonlyContainsAuthorityCerts. Значение этого поля должно быть установлено на true;- если поле reasonCodes присутствует в расширении издающего пункта распределения,то поле кодов причин должно включать все причины важности для приложения;- расширение издающего пункта распределения может или не может содержать в себеполе inderectCRL (следовательно, это поле необязательно проверять).Этот CARL может быть использован, только, если сертификат субъекта являетсясертификатом ЦР. Таким образом, для сертификата версии 3 сертификат субъекта долженсодержать расширение basicConstraints со значением cA=TRUE.B.5.1.4 Пункт распределения основанный на CRL/EPRL/CARLДля того, чтобы определить, что CRL является одним из CRL, указанных расширениемпункта распределения CRL в сертификате, должны удовлетворятся все следующие условия:- либо поле пункта распределения в расширении издающего пункта распределения CRLдолжно отсутствовать (только в тех случаях, когда не ожидается критический CRL DP), илиодно из имен в поле пункта распределения расширения пункта распределения CRLсертификата соответствует одному из имен в поле пункта распределения расширенияиздающего пункта распределения CRL;- если сертификат является сертификатом конечного объекта, то CRL не долженсодержать поле onlyContainsAuthorityCerts с установленным значением true в расширенииCRL издающего пункта распределения;- если в расширении CRL издающего пункта распределения значениеonlyContstraintsAuthorityCerts установлено на true, то проверяемый сертификат долженсодержать расширение basicConstraints с компонентой сА установленным значением true;- если поле кодов причин присутствует в расширении пункта распределения CRLсертификата, то это поле должно либо отсутствовать в расширении CRL издающего пункта117

O′z DSt 1108:2006распределения или содержать по крайне мере один из кодов причин, предъявленных врасширении пункта распределения CRL сертификата;- если поле cRLIssuer отсутствует в расширении пункта распределения CRLсертификата, то CRL должен быть подписан тем ЦР, который подписал сертификат; и- если поле cRLIssuer присутствует в расширении пункта распределения CRLсертификата, то CRL должен быть подписан со стороны издателя CRL, установленного врасширении пункта распределения CRL сертификата и CRL должен содержать полеindirectCRL в расширении издающего пункта распределения.B.5.2 Утверждение области дельта CRLДоверяющая сторона может также быть проверяющим (контролирующим) dCRL, либопотому, что это затребовано посредством критического расширения freshestCRL всертификате или потому что политика, согласно которой работает доверяющая сторона,поддерживает проверку dCRL.Доверяющая сторона может быть всегда уверенной, что она имеет соответствующуюинформацию CRL для сертификата, если будут выполняться все следующие условия:- базовый CRL, используемый доверяющей стороной, соответствует сертификату (врамках области);- дельта CRL, используемый доверяющей стороной, соответствует сертификату (врамках области);- базовый CRL был издан в одно и тоже время или позже чем базовый CRL, сосланныйсо стороны dCRL.Для того чтобы определить, что dCRL является соответствующим для сертификата,должны выполнятся все следующие условия:- расширение индикатора дельта CRL должно присутствовать;- dCRL должен быть изданным после CRL. Один из путей гарантирования этого, этопроверка того, что номер CRL в расширении crlNumber dCRL больше чем номер CRL врасширении crlNumber базового CRL, который используется доверяющей стороной, и поляcRLStreamIdentifier базового CRL и dCRL соответствуют. Другой путь - это сравнениеполей thisUpdate базового CRL и dCRL, имеющийся у доверяющей стороны;- базовый CRL, используемый доверяющей стороной, должен быть dCRL, которыйиздан до базового CRL или позже него. Один из путей гарантирования этого - это проверкатого, что номер CRL в расширении deltaCRLIndicator dCRL меньше чем или равно номеруCRL в расширении crlNumber базового CRL, который используется доверяющей стороной иполя cRLStreamIdintifier в базовом CRL и dCRL соответствуют. Другим путем являетсясравнение полей thisUpdate базового CRL, который имеется у доверяющей стороны, ибазового CRL, указанного со стороны dCRL;- если dCRL содержит расширение издающего пункта распределения, то областьиздающего пункта распределения будет совместимой с сертификатом, как это описано вышев B.5.1.4;- если dCRL содержит расширение область CRL, то сертификат будет в области этогоCRL;- если dCRL не содержит какую-нибудь из таких расширений как streamIdentifier,crlScope и issuingDistributionPoint, то он будет использован только в сочетании с полным изавершенным базовым CRL.B.5.3 Проверка действительности и употребительности базового CRLДля того чтобы проверить, что базовый CRL является точным и не изменен с тех пор,как его издали, все следующие условия должны выполнятся:- доверяющая сторона должна иметь возможность получить открытый ключ издателя,установленного в CRL, используя удостоверенные способы;- подпись на базовом CRL должна быть проверена, используя удостоверенныйоткрытый ключ;118

O′z DSt 1108:2006- если поле nextUpdate присутствует, то текущее время должно быть более ранним, чемполе nextUpdate;- имя издателя в CRL должно совпадать с именем издателя в сертификате, которыйпроверяется на аннулирование, до тех пор, пока CRL не извлечен из CRL DP в сертификате ирасширение CRL DP содержит компоненту издателя CRL. В этом случае, одно из имен вкомпоненте издателя CRL в расширении CRL DP должно соответствовать имени издателя вCRL.B.5.4 Действительность и контроль над дельта CRLДля того, чтобы проверить, что dCRL является точным и не был изменен с тех пор какбыл издан, должны выполнятся все следующие условия:- доверяющая сторона должна иметь возможность получить открытый ключ издателя,установленного в CRL, используя удостоверенные способы;- подпись на дельта CRL должна быть проверена, используя удостоверенный открытыйключ;- если поле nextUpdate присутствует, то текущее время должно быть более ранним, чемполе nextUpdate;- имя издателя в CRL должно совпадать с именем издателя в сертификате, которыйпроверяется на аннулирование, до тех пор, пока выполняются следующие условия:a) дельта CRL извлечен из CRL DP в сертификате и расширение CRL DP содержиткомпоненту издателя CRL. В этом случае, одно из имен в компоненте издателя CRL врасширении CRL DP должно соответствовать имени издателя в CRL;b) дельта CRL извлечен из расширения freshestCRL в сертификате и расширениеCRLScope в dCRL содержит компоненту PerAuthorityScope с authorityName, которыйсоответствует имени издателя сертификата.119

O′z DSt 1108:2006Приложение C(обязательное)Эталонное определение алгоритма идентификаторов объектаДанное приложение определяет идентификаторы объекта, присвоенные алгоритмамаутентификации и шифрования, при отсутствии формального регистра. Оно предназначенодля того, чтобы использовать такой регистр, как только он будет доступным. Определениеимеет форму модуля ASN.1, AlgorithmObjectIdentifier.AlgorithmObjectIdentifiers {joint-iso-itu-t ds(5) module(1)algorithmObjectIdentifiers(8) 4}DEFINITIONS ::=BEGIN-- EXPORTS All --IMPORTSalgorithm, authenticationFrameworkFROM UsefulDefinitions {joint-iso-itu-t ds(5) module(1) usefulDefinitions(0) 4}ALGORITHMFROM AuthenticationFramework authenticationFramework ;-- категории идентификатора объекта --encryptionAlgorithm OBJECT IDENTIFIER ::= {algorithm 1}hashAlgorithm OBJECT IDENTIFIER ::= {algorithm 2}signatureAlgorithm OBJECT IDENTIFIER ::= {algorithm 3}-- синонимы --id-ea OBJECT IDENTIFIER ::= encryptionAlgorithmid-ha OBJECT IDENTIFIER ::= hashAlgorithmid-sa OBJECT IDENTIFIER ::= signatureAlgorithm-- алгоритмы --rsa ALGORITHM ::= {KeySizeIDENTIFIED BY id-ea-rsa }KeySize ::= INTEGER-- присвоение (назначение) идентификатора объекта --id-ea-rsa OBJECT IDENTIFIER ::= {id-ea 1}id-ha-sqMod-n OBJECT IDENTIFIER ::= {id-ha 1}id-sa-sqMod-nWithRSA OBJECT IDENTIFIER ::= {id-sa 1}END120

O′z DSt 1108:2006Приложение D(обязательное)Технические отклонения и их объясненияВ стандарт были включены отдельные дополнения, вызванные на основаниитребований законодательства Республики Узбекистан. Технические отклонения идополнительная информация были включены непосредственно в разделы, к которым ониотносятся и где необходимо их включение.D.1 Исключения: Из стандарта ITU-T «Information Technologies. Open SystemInterconnection. Public key and certificate attribute frameworks» (Информационная технология.Взаимосвязь открытых систем. Структура сертификата открытого ключа ЭЦП и сертификатаатрибута) исключены следующие приложения и разделы.Таблица 1. Технические отклоненияРаздул/подразделИсключения1. Раздел 2 «Нормативные ссылки»2. Подраздел 3.1 и 3.2 Соответственно «Определение архитектурыбезопасности Эталонной Модели ВОС» и «Определениемодели Директории»3. Разделы 5 и 6 Соответственно «Соглашения» и «Обзор структур»4. Приложение D «Политика привилегий и образцы ОпределенияАтрибутов Привилегий»5. Приложение C «Примеры издания дельта-CRL»6. Приложение E «Введение в криптосистемы с открытым ключом»7. Приложение G «Пример использования ограничений путисертификации»8. Приложение H «Алфавитный список определений разделов»9. Приложение I «Исправления и опечатки»Объяснение: Разделы и приложения исключены по той причине, что они предоставляетлибо дополнительную, т.е. вводную или справочную информацию, которая приводится влитературе.D.2 Дополнения: В данном стандарте введены дополнения, касающиеся терминологии,т.е. некоторые термины, применяемые в Инфраструктуре Открытых Ключей создаваемой вРеспублике Узбекистан в некоторой степени отличаются от терминов используемых вмеждународном стандарте ITU-T X.509 или несут за собой смысл, отличающийся от смыслатерминов международного стандарта ITU-T X.509.Таблица 2. ДополненияРаздел/подразделДополнения1. Раздел 2 «Нормативная ссылка»2. Раздел 4 «Общие положения»3 Раздел 3 «Термины, определения и сокращения» в этот разделвключены термины:- Центр регистрации;- Орган регистрации Центров регистрации.Эти термины использованы по всему документу всоответствии с синтаксисом и заменяют термин«сертифицирующий орган» там, где необходимо.Объяснение: Дополнения были включены из-за необходимости точности изложениясведений приводимых в данном стандарте и целей преследуемых данным стандартом.121

O′z DSt 1108:2006При введении дополнений и изменений в международный стандарт ITU-T X.509 неизмененным было оставлено около 60 % текста исходного стандарта.В связи с вышеприведенными изменениями данный стандарт являетсямодифицированным в отношении международного стандарта ITU-T X.509 «InformationTechnologies. Open System Interconnection. Public key and certificate attribute frameworks»(Информационная технология. Взаимосвязь Открытых Систем. Структура сертификатаоткрытого ключа ЭЦП и сертификата атрибута).122

O′z DSt 1108:2006Библиография[1] Стандарт ITU-T X.509v.3:2000Information technology. Open systems interconnection. TheDirectory: Public-key and attribute certificate frameworks[2] Стандарт ITU-T X.500 Information Technology. Open systems interconnection.The directory: Overview of concepts, models and services123

O′z DSt 1108:2006УДК: 621.321 ОКС 35.240 Группа П 85Ключевые слова: сертификат открытого ключа, сертификат атрибута, идентификатор,директория, промежуточный сертификат, владелец, обработка, инициализация,аутентификация, расширение, процедура, схема, ограничение, дескриптор, распределение,структура, привилегия, делегирование.124