Протоколы безопасного сетевого взаимодействия

Инфраструктура Открытого Ключа (часть 6)

Разбить на страницы
Показывать лекцию целиком

Протоколы PKI управления сертификатом

Введение

В этой лекции будут рассматриваться управляющие протоколы PKI.

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

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

Протоколы управления требуются для поддержки on-line взаимодействия между компонентами PKI. Например, протокол управления должен использоваться между СА и системой клиента, с которым связана пара ключей, или между двумя САs, которые выпустили кросс-сертификаты друг для друга.

Все конечные участники требуют локального безопасного доступа к некоторой информации – как минимум к своему собственному имени и закрытому ключу, имени СА, который является доверенным для данного участника, и открытому ключу СА (или дайджесту открытого ключа, если допустима самосертифицированная версия). Может использоваться локальное безопасное хранение и для большего количества информации (например, сертификата конечного участника или информации, относящейся к приложению). Форма хранения также может быть различной – от файлов до неподделываемых криптографических токенов. Такое локальное доверенное хранение мы будем определять как персональное безопасное окружение (Personal Security Environment – PSE) конечного участника.

Хотя форматы PSE находятся вне рассматриваемой предметной области (в частности, они очень зависят от оборудования), здесь мы определим общий формат обмена для PSEs.

Требования к управлению PKI

Рассматриваемые протоколы должны удовлетворять следующим требованиям к управлению PKI.

  • Управление PKI должно соответствовать стандарту ISO 9594-8 и связанным с ним расширениям сертификата.
  • Управление PKI должно соответствовать остальным частям стандарта Х.509 v3.
  • Должна быть возможность регулярного изменения любой пары ключей без влияния на какую-либо другую пару ключей.
  • Использование сервисов, обеспечивающих конфиденциальность, в протоколах управления PKI должно быть сведено к минимуму, чтобы уменьшить связанные с этим проблемы.
  • Протоколы управления PKI должны допускать использование различных криптографических алгоритмов, являющихся промышленными стандартами (специально включая только RSA, DSA, MD5, SHA-1). Это означает, что данный СА, RA или конечный участник могут в принципе использовать для своей пары ключей любой набор алгоритмов.
  • Протоколы управления PKI не должны препятствовать созданию пары ключей как конечным участником, так и RA или СА –ключ может создаваться где-то еще, но в целях управления PKI мы можем предполагать, что генерация ключа происходит в тот момент, когда он впервые передан конечному участнику, RA или СА.
  • Протоколы управления PKI должны поддерживать опубликование сертификатов, относящихся к конечным участникам, RA или СА.
  • Протоколы управления PKI должны поддерживать создание CRLs, позволяя сертифицированным конечным участникам посылать запросы на отмену сертификатов – это должно быть организовано так, чтобы невозможно было предпринять DoS-атаку.
  • Протоколы управления PKI должны использоваться поверх различных транспортных механизмов, включая LDAP, SMTP, HTTP, TCP/IP и FTP.
  • Конечным уполномоченным органом при создании сертификата является СА; предполагается, что оборудование ни конечного участника, ни RA не может выпустить сертификат – СА может изменить значения полей сертификата или может добавить, удалить или изменить расширения в соответствии со своей политикой функционирования. Например, СА может уменьшить запрошенный период действительности. Заметим, что политика может определять, что СА не должен публиковать или каким-то другим образом распределять сертификат, пока участник не просмотрит и не получит заново созданный сертификат (обычно с использованием PKIConfirm -сообщения).
  • Должна поддерживаться возможность гибкого изменения от одной нескомпрометированной пары ключей СА к следующей (заметим, что если ключ СА скомпрометирован, переинициализация должна выполняться для всех участников в домене данного СА). Конечный участник, чей PSE содержит новый открытый ключ СА (следуя изменению ключа СА ) должен также иметь возможность проверять сертификаты, с использованием старого открытого ключа. Конечные участники, которые непосредственно доверяют старой паре ключей СА, должны также иметь возможность проверять сертификаты, подписанные с использованием нового закрытого ключа СА. (Обычно это требуется в ситуациях, когда старый открытый ключ СА "встроен" в криптографическое оборудование конечного участника.)
  • Функции RA в некоторых реализациях или окружениях выполняются самим СА. Протоколы должны быть разработаны так, чтобы конечные участники могли использовать тот же протокол (но, конечно, не тот же ключ!) независимо от существующей взаимосвязи RA или СА.
  • При запросе конечным участником сертификата, содержащего данное значение открытого ключа, конечный участник должен быть готов продемонстрировать обладание соответствующим значением закрытого ключа. Это можно организовать по-разному, в зависимости от типа алгоритма открытого ключа.
    •

    Операции управления PKI

    Множество операций, для которых определены управляющие сообщения, могут быть сгруппированы следующим образом.

  • Инициализация СА: при инициализации нового СА должны выполняться определенные шаги, такие как создание начальных CRLs, экспорт открытого ключа СА и т.п.
  • Инициализация конечного участника; данная операция включает импорт открытого ключа корневого СА и запрошенной информации об опциях, поддерживаемых управляющим участником PKI.
  • Сертификация: множество операций, в результате которых создается новый сертификат.
  • Начальная регистрация / сертификация – это процесс, в результате которого конечный участник впервые сообщает о себе СА или RA, до того как СА выпустит сертификат или сертификаты для данного конечного участника. Конечным результатом данного процесса (если он успешен) является выпуск сертификата для открытого ключа участника и возврат этого сертификата конечному участнику и/или помещение его в открытый репозиторий. Данный процесс может включать (и обычно включает) несколько "шагов", таких как инициализация оборудования конечного участника. Например, оборудование конечного участника может быть безопасно инициализировано открытым ключом СА, который будет использоваться для проверки действительности сертификационных путей. Более того, конечному участнику обычно бывает необходима инициализация собственной пары ключей.
  • Изменение пары ключей: каждая пара ключей должна регулярно изменяться (замещаться новой парой), и должен выпускаться новый сертификат.
  • Изменение сертификата: после того, как срок действительности сертификата истек, он может быть обновлен, если было соответствующее уведомление.
  • Изменение пары ключей СА: как и в случае конечных участников пара ключей СА должна регулярно изменяться; при этом требуются различные механизмы, позволяющие в течение некоторого времени использовать как новый, так и старый открытые ключи СА.
  • Запрос кросс-сертификации: один СА запрашивает выпуск кросс-сертификата у другого СА. В данном стандарте определены следующие термины. Кросс-сертификат – это сертификат, в котором subject CA и issuer CA различны, и SubjectPublicKeyInfo содержит ключ проверки (например, сертификат выпущен для пары ключей подписывания subject CA). Когда необходимо более тонкое различие, могут использоваться следующие термины: кросс-сертификат называется междоменным кросс-сертификатом, если subject и issuer CA принадлежат различным административным доменам; в противном случае он называется внутридоменным кросс-сертификатом.

    Замечание 1. Во многих окружениях термин "кросс-сертификат", если не будет дальнейшего уточнения, обычно считается синонимом "междоменного кросс-сертификата ".

    Замечание 2. Выпуск кросс-сертификатов может быть взаимным; это означает, что два СА могут выпустить кросс-сертификаты друг для друга, но также возможна ситуация, когда только один СА выпускает кросс-сертификат для другого СА.

  • Изменение кросс-сертификата: происходит аналогично обычному изменению сертификата, но операция относится к кросс-сертификату.
    •
  • Операции опубликования сертификата и/или CRL: результатом некоторых операций управления PKI является опубликование сертификатов или CRLs:
  • Опубликование сертификата: способы включают использование определенных сообщений или применение конкретного протокола (LDAP, например).
  • Опубликование CRL аналогично опубликованию сертификата.
  • Операции восстановления: определенные операции управления PKI используются при потере конечным участником своего PSE.
  • Восстановление пары ключей: в качестве дополнительной возможности материал ключа пользователя (например, закрытый ключ пользователя, применяемый для шифрования) может быть сохранен СА, RA или системой архивирования, связанной с СА или RA. Если данный материал ключа необходимо восстановить (например, был забыт пароль или потерян файл ключей), может потребоваться протокол для поддержки такого восстановления.
  • Операции отмены: результатом определенных операций PKI является создание новых записей CRL и/или новых CRLs.
  • Запрос отмены: авторизованная личность оповещает СА об исключительной ситуации, требующей отмены сертификата.
  • PSE операции: хотя определение операций PSE (например, пересылка PSE, цепочка PIN и т.д.) находится вне данной предметной области, определено специальное сообщение, которое может служить основой для таких операций.

    • Заметим, что on-line протоколы являются не единственным способом реализации перечисленных выше операций. Для всех операций существуют off-line методы, с помощью которых можно добиться того же самого результата, и в принципе никто не требует задействовать исключительно on-line протоколы. Например, если используется аппаратный токен, многие операции могут быть получены как часть физической доставки токена.

    Далее определим множество стандартных сообщений, поддерживающих перечисленные выше операции. Также определим протоколы для доставки этих сообщений в различных окружениях (на основе различных протоколов).

    Инициализация конечного участника

    Первым действием конечного участника является запрос информации о поддерживаемых функциях PKI и безопасное получение открытого ключа (ключей) соответствующего корневого СА.

    Начальная регистрация/сертификация

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

    Однако можно классифицировать схемы начальной регистрации / сертификации, которые могут поддерживаться. Заметим, что слово "начальная" является ключевым – мы имеем дело с ситуацией, когда конечный участник ранее не имел контакта с PKI. Если конечный участник уже обладает сертифицированными ключами, то возможны некоторые упрощения или альтернативы.

    Составив классификацию схем, мы определим некоторые из них как обязательные и некоторые – как дополнительные. Обязательные схемы должны охватывать достаточное количество реальных случаев, в то время как дополнительные схемы применяются в исключительных случаях, которые возникают реже. Таким образом можно добиться баланса между гибкостью и легкостью реализации.

    Рассмотрим классификацию схем начальной регистрации / сертификации.

    Используемые классификации схем

    Инициализация регистрации/сертификации

    Пользуясь терминами создаваемых сообщений PKI, можно сказать, что инициализация начальных обменов регистрации / сертификации происходит в момент создания конечным участником первого сообщения. Заметим, что в реальном мире инициализация процедуры регистрации / сертификации может происходить как-то еще (например, по телефону).

    Начальная аутентификация сообщения конечного участника

    On-line сообщения, созданные конечным участником, запрашивающим сертификат, могут быть как аутентифицированы, так и нет. Требованием является аутентификация подлинности любых сообщений от конечного участника к PKI (CA/RA).

    Подобная аутентификация может обеспечиваться следующим образом: PKI (CA/RA) передает конечному участнику секретное значение (ключ начальной аутентификации) и справочное значение (используемое для идентификации транзакции) некоторыми внешними способами. Ключ начальной аутентификации может затем использоваться для защиты соответствующих значений PKI.

    Мы можем таким образом классифицировать схемы начальной регистрации / сертификации в соответствии с тем, аутентифицированы on-line сообщения EE к PKI или нет.

    Замечание 1: мы не рассматриваем аутентификацию сообщений PKI к EE, т.к. она требуется ВСЕГДА. В любом случае открытый ключ СА может быть инсталлирован в оборудовании конечного участника или аутентификация может быть основана на ключе начальной аутентификации.

    Замечание 2: процедура начальной регистрации / сертификации может быть безопасна, если сообщения от конечного участника аутентифицированы некоторыми внешними способами (например, непосредственным визитом).

    Расположение генератора ключа

    Будем считать, что "генерация ключа" происходит всякий раз, когда открытый или закрытый компоненты ключа впервые появляется в PKIMessage. Заметим, что это не препятствует централизованному сервису генерации ключа – реальная пара ключа может быть создана где-то еще и передана конечному участнику, RA или СА с использованием (собственного или стандартного) протокола запроса/ответа генератора ключа.

    Существует три возможных размещения "генератора ключа": конечный участник, RA или СА.

    Подтверждение успешной сертификации

    После создания начального сертификата для конечного участника дополнительная гарантия может быть достигнута тем, что конечный участник явно подтверждает успешное получение сообщения, содержащего сертификат или указывающего на его создание. Естественно, это подтверждающее сообщение должно быть защищено (с помощью ключа начальной аутентификации или другим способом).

    СА создает и передает конечному участнику данные активации – значения данных, отличные от ключей, необходимые для функционирования криптографических модулей, которые должны быть защищены (например, PIN, парольная фраза или разделяемый вручную ключ).

    Это дает две возможности: с подтверждением или без.

    Обязательные схемы

    Приведенная выше классификация применима для большого числа схем начальной регистрации / сертификации. Будем считать, что оборудование СА, оборудование RA и оборудование конечного участника должно поддерживать вторую схему, описанную ниже. По желанию любой участник может дополнительно поддерживать и другие схемы.

    Централизованная схема

    В терминах приведенной выше классификации данная схема является самой простой:

  • Инициализация осуществляется на сертифицирующем СА;
  • Никакой on-line аутентификации сообщения не требуется;
  • "Генерация ключа" происходит на сертифицирующем СА;
  • Никакого подтверждающего сообщения не требуется.
    •

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

    Базовая схема аутентификации

    В терминах приведенной выше классификации данная схема определяется следующим образом:

  • Инициализацию осуществляет конечный участник;
  • Аутентификация сообщения ТРЕБУЕТСЯ;
  • "Генерация ключа" осуществляется конечным участником;
  • Подтверждающее сообщение требуется.
    •

    В терминах потока сообщений базовая схема аутентификации будет следующей (см. рис.18.1).

    Если проверка подтверждающего сообщения не проходит, RA/CA должен отменить только что выпущенный сертификат, если он был опубликован или сделан доступным каким-либо еще способом.

    Доказательство обладания (Proof of Possession – РОР) закрытым ключом

    Для того чтобы предотвратить основные атаки и позволить CA/RA выполнить проверку соответствия конечного участника и пары ключей, определены операции управления PKI, которые дают конечному участнику возможность доказать, что он обладает закрытым ключом (и может использовать его), соответствующим открытому ключу, для которого запрошен сертификат. CA/RA самостоятельно выбирает, как выполнить РОР (например, с использованием внешних механизмов или специальных управляющих сообщений). Однако требуется, чтобы CAs/RАs выполняли РОР определенным способом, так как сейчас существует много не-PKI протоколов (в частности, протоколы e-mail), которые явно не проверяют связь между конечным участником и закрытым ключом. До тех пор, пока протоколы, которые выполняют проверку связывания (для пары ключей подписывания, шифрования и согласования ключа), используются не везде, предполагается, что такое связывание проверяется только CA/RA. Таким образом, если связывание не проверяется CA/RA, то сертификаты являются менее надежными.

    (рис 18.1) Базовая схема аутентификации

    POP выполняется различными способами, зависящими от типа ключа, для которого требуется сертификат. Если ключ может использоваться для нескольких целей (например, ключ RSA), то может применяться любой подходящий метод (например, ключ, который может быть задействован как для подписывания, так и для других целей, не должен посылаться CA/RA для доказательства обладания).

    Данная спецификация явно предназначена для случаев, когда конечный участник предоставляет соответствующее доказательство для RA, и RA затем сообщает СА, что доказательство получено (и проверено). Например, конечный участник, который хочет иметь сертифицированный ключ подписывания, может послать соответствующую подпись в RA, который затем уведомит СА, что конечный участник предоставил необходимое доказательство. Однако такая ситуация допустима не всегда (например, СА может допускать проверку POP только в течение сертификации ).

    Ключи подписывания

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

    Ключи шифрования

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

    Прямой метод состоит в том, что CA/RA создает случайный вызов, на который требуется немедленный ответ ЕЕ.

    Косвенный метод состоит в том, что выпускается сертификат, который шифруется для конечного участника (и конечный участник демонстрирует свою способность дешифровать сертификат в подтверждающем сообщении). Это позволяет СА выпускать сертификат в форме, которая может использоваться только соответствующим конечным участником.

    Рекомендуется задействовать косвенный метод, т.к. это не требует посылки дополнительных сообщений (т.е. доказательство может быть продемонстрировано с использованием трех сообщений {запрос, ответ, подтверждение}).

    Ключи согласования ключа

    Для ключей согласования ключа конечный участник и CA/RA должны установить разделяемый секретный ключ, чтобы доказать, что конечный участник обладает закрытым ключом.

    Заметим, что это накладывает определенные ограничения на ключи, которые могут быть сертифицированы данным СА – в частности, для ключей Диффи-Хеллмана конечный участник может свободно выбрать параметры алгоритма – предполагая, что СА в случае необходимости может создать короткую (или одноразовую) пару ключей с соответствующими параметрами.

    Изменение ключа корневого СА

    Данное обсуждение касается только САs, которые являются корневыми СА для некоторого конечного участника.

    Основа описанной здесь процедуры состоит в том, что СА защищает свой новый открытый ключ, используя предыдущий закрытый ключ, и наоборот. Таким образом, если СА изменяет свою пару ключей, он должен создать два дополнительных значения атрибута сертификата cACertificate, если сертификаты доступны с использованием Х.500 директории (всего четыре сертификата: OldWithOld; OldWithNew; NewWithOld; NewWithNew).

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

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

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

    Замечание 2: данная схема заставляет ЕЕ получать (внешними способами) новый открытый ключ СА по истечении срока действия последнего сертификата, с использованием которого был подписан старый закрытый ключ СА. Требуют ли этого операции изменения ключа и/или сертификата, зависит от оборудования ЕЕ.

    Действия оператора СА

    Для изменения ключа СА оператор СА должен сделать следующее:

  • Создать новую пару ключей;
  • Создать сертификат, содержащий старый открытый ключ, подписанный новым закрытым ключом ("старый с новым" сертификат);
  • Создать сертификат, содержащий новый открытый ключ СА, подписанный старым закрытым ключом ("новый со старым" сертификат);
  • Создать сертификат, содержащий новый открытый ключ СА, подписанный новым закрытым ключом ("новый с новым" сертификат).
  • Опубликовать эти новые сертификаты в директории и/или другими способами (возможно, с использованием CAKeyUpdAnn -сообщения);
  • Экспортировать новый открытый ключ СА так, чтобы конечные участники могли получить его, используя "внешний" механизм (если нужно).
    •

    Старый закрытый ключ СА более не требуется. Тем не менее старый открытый ключ еще некоторое время используется. Старый открытый ключ не будет требоваться, когда все конечные участники данного СА безопасно получат новый открытый ключ СА.

    Сертификат "старый с новым" должен иметь период действительности, начинающийся с момента создания новой пары ключей и кончающейся временем, когда все конечные участники данного СА безопасно получат новый открытый ключ СА (самое позднее – это дата истечения срока действия старого открытого ключа).

    Сертификат "новый с новым" должен иметь период действительности, начинающийся со времени создания новой пары ключей и заканчивающийся временем следующего изменения СА своей пары ключей.

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

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

    Выпуск нового сертификата СА
    Репозиторий содержит новый и старый открытые ключи Репозиторий содержит только старый открытый ключ (например, задержка опубликования)
    PSE содержит новый открытый ключ PSE содержит старый открытый ключ PSE содержит новый открытый ключ PSE содержит старый открытый ключ
    Сертификат подписавшего защищен с использованием нового открытого ключа

    Случай 1:

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

    Случай 3:

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

    Случай 5:

    Хотя оператор СА не изменил директорию, проверяющий может проверить сертификат непосредственно – аналогично случаю 1

    Случай 7:

    В этом случае оператор СА не изменил директорию, и проверка не проходит
    Сертификат подписавшего защищен с использованием старого открытого ключа

    Случай 2:

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

    Случай 4:

    В этом случае проверяющий может непосредственно проверить сертификат без использования репозитория

    Случай 6:

    Проверяющий думает, что это ситуация случая 2 и хочет получить доступ к директории; однако проверка не проходит

    Случай 8:

    Хотя оператор СА не изменил директорию, проверяющий может проверить сертификат непосредственно – случай аналогичен случаю 4

    Проверка в случаях 1, 4, 5 и 8

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

    Заметим, что случай 8 может возникнуть в промежуток времени, когда оператор СА создал новую пару ключей и сохранил в директории измененные атрибуты. Случай 5 может иметь место, если оператор СА выпустил как сертификат подписывающего, так и сертификат проверяющего в течение данного интервала (оператор СА должен избегать такой ситуации, т.к. это приводит к невозможности проверки, как описано выше).

    Проверка в случае 2

    В случае 2 проверяющий должен получить доступ к старому открытому ключу СА. Проверяющий делает следующее:

  • Смотрит атрибут caCertificate в директории и получает OldWithNew- сертификат (определяемый на основе периода действительности);
  • Проверяет, все ли в порядке, используя новый ключ СА (который он имеет локально);
  • Если все нормально, проверяет сертификат подписавшего, используя старый открытый ключ СА.
    •

    Случай 2 встречается, когда оператор СА выпустил сертификат подписывающего, затем изменил ключ и выпустил сертификат проверяющего; таким образом, это вполне типичный случай.

    Проверка в случае 3

    В случае 3 проверяющий должен получить доступ к новому открытому ключу СА. Проверяющий делает следующее:

  • Смотрит атрибут саCertificate в директории и получает NewWithOld- сертификат (определяемый на основе периода действительности);
  • Проверяет, корректен ли он, используя старый открытый ключ СА (который хранится локально);
  • В случае корректности проверяет сертификат подписавшего, используя новый открытый ключ СА.
    •

    Случай 3 имеет место, когда оператор СА выпускает сертификат проверяющего, затем изменяет ключ и выпускает сертификат подписавшего; таким образом, это вполне типичный случай.

    Неудачная проверка в случае 6

    В данном случае СА выпускает PSE проверяющего, содержащий новый ключ, без изменения атрибутов директории. Это означает, что проверяющий не может получить достоверную версию старого ключа СА, поэтому проверка не проходит.

    Заметим, что невозможность проверки является ошибкой оператора СА.

    Неудачная проверка в случае 7

    В данном случае СА выпускает сертификат подписывающего, защищенный новым ключом, без изменения атрибутов директории. Это означает, что проверяющий не имеет способов получить достоверную версию нового ключа СА, поэтому проверка не проходит.

    Заметим, что невозможность проверки также является ошибкой оператора.

    Отмена – изменение ключа СА

    Как показано выше, проверка сертификата становится более сложной, так как допускается изменение ключа СА. Это также верно для проверок отмены, поскольку СА может подписать CRL, используя более новый закрытый ключ, чем тот, который применялся для пользовательского PSE.

    Анализ возможных альтернатив аналогичен проверке сертификата.

    Кросс-сертификация

    Запрашивающий СА является СА, который станет субъектом кросс-сертификата ; отвечающий СА станет выпускающим (issuer) кросс-сертификата.

    Запрашивающий СА должен быть "up and running" до начала выполнения операции кросс-сертификации.

    Односторонняя схема запроса-ответа

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

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

    Кросс-сертификация инициируется одним СА, который называется отвечающим. Администратор отвечающего СА определяет СА, который он хочет кросс-сертифицировать, и оборудование отвечающего СА создает авторизационный код. Администратор отвечающего СА передает данный авторизационный код внешними способами администратору запрашивающего СА. Администратор запрашивающего СА вводит авторизационный код отвечающего СА, чтобы инициировать on-line обмен.

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

    Запрашивающий СА инициирует обмен созданием случайного числа (случайное число запрашивающего). Затем запрашивающий СА посылает отвечающему СА сообщение запроса кросс-сертификата ( ccr ). Поля в данном сообщении защищены от модификации с помощью МАС, основанного на авторизационном коде.

    При получении ccr сообщения отвечающий СА проверяет версию протокола, сохраняет случайное число запрашивающего, создает свое случайное число (случайное число отвечающего) и проверяет МАС. Затем он создает (и, если требуется, архивирует) новый сертификат запрашивающего, который содержит открытый ключ запрашивающего СА и подписан закрытым ключом подписывания отвечающего СА. Отвечающий СА посылает сообщение ответа кросс-сертификата ( сср ). Поля в данном сообщении защищены от модификации с помощью МАС, основанного на авторизационном коде.

    При получении срр сообщения запрашивающий СА должен убедиться, что его собственное системное время позднее системного времени отвечающего СА, проверяет полученные случайные числа и действительность МАС. Запрашивающий СА отвечает PKIConfirm -сообщением. Поля в данном сообщении защищены от модификации с использованием МАС, основанного на авторизационном коде. Запрашивающий СА записывает запрошенный сертификат в репозиторий.

    При получении PKIConfirm -сообщения отвечающий СА проверяет случайные числа и действительность МАС.

    Замечания:

  • Ccr сообщение должно содержать "завершенный" запрос сертификата, что означает, что все поля (включая расширения BasicConstraints ) должны быть указаны запрашивающим СА.
  • Срр сообщение должно содержать сертификат проверки отвечающего СА – если он присутствует, то запрашивающий СА должен затем проверить данный сертификат (например, с помощью внешнего механизма).
    •

    Запрос сертификата

    Инициализированный участник может в любое время запросить сертификат (как часть процедуры изменения для любой другой цели). Данный запрос будет сделан с использованием сообщения запроса сертификата ( cr ). Если конечный участник уже имеет пару ключей подписывания (с соответствующим сертификатом проверки), то данное cr сообщение обычно бывает защищено подписью участника. СА возвращает новый сертификат (если запрос успешен) в CertRepMessage.

    Изменение ключа

    Когда период действительности пары ключей истекает, соответствующий конечный участник может запросить изменение ключа – это означает, что он может сделать запрос на создание СА нового сертификата для новой пары ключей. Запрос может быть сделан с использованием сообщения запроса изменения ключа ( kur ). Если конечный участник уже имеет пару ключей подписывания (с соответствующим сертификатом проверки), то данное сообщение обычно бывает защищено цифровой подписью участника. СА возвращает новый сертификат (если запрос успешен) в сообщении ответа изменения ключа ( kup ), которое синтаксически идентично CertRepMessage.

    Структуры данных

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

    Полное сообщение PKI

    Все сообщения, используемые для управления PKI, имеют следующую структуру:

    PKIMessage ::= SEQUENCE {
  header         PKIHeader,
  body           PKIBody,
  protection [0] PKIProtection OPTIONAL,
  extraCerts [1] SEQUENCE SIZE (1..MAX) OF
                 Certificate OPTIONAL
}

    PKIHeader содержит информацию, которая является общей для многих сообщений PKI.

    PKIBody содержит информацию, специфичную для сообщения.

    PKIProtection, если используется, содержит биты, которые защищают сообщение PKI.

    Поле extraCerts может содержать сертификаты, которые могут использоваться получателем. Например, оно может применяться СА или RA для предоставления конечному участнику сертификатов, которые он должен проверить с использованием собственного нового сертификата (если, например, СА, который выпустил сертификат конечного участника, не является для него корневым СА). Заметим, что данное поле не обязательно должно содержать сертификационный путь – получатель может отсортировать, выбрать или каким-то другим образом обработать дополнительные сертификаты, чтобы иметь возможность использовать их.

    Заголовок сообщения PKI

    Все PKI-сообщения требуют определенной информации для возможности адресации и идентификации транзакций. Некоторая необходимая информация содержится в заголовке транспортного уровня; однако если PKI-сообщение защищено, то данная информация защищена тоже (например, безопасность транспортного уровня может не предполагаться).

    Для данной информации используется следующая структура данных:

    PKIHeader ::= SEQUENCE {
  pvno   INTEGER   { ietf-version2 (1) },
  sender GeneralName,  
  --  идентификация отправителя

  recipient   GeneralName,  
  --  идентификация ожидаемого получателя

  messageTime  [0] GeneralizedTime OPTIONAL,
  --  время создания данного сообщения 
  --  (используется, если отправитель 
  --  считает, что транспорт должен быть 
  --  "соответствующим", например, что для 
  --  получателя важно время)

  protectionAlg [1] AlgorithmIdentifier 
                    OPTIONAL,
  --  алгоритм, используемый для вычисления
  --  защищенных битов 

  senderKID    [2]  KeyIdentifier OPTIONAL,
  recipKID     [3]  KeyIdentifier OPTIONAL, 
  --  идентифицирует конкретные ключи, 
  --  используемые для защиты 

  transactionID [4] OCTET STRING OPTIONAL,
  --  идентифицирует транзакцию; должно быть
  --  одним и тем же соответственно в 
  --  сообщениях запроса, ответа и 
  --  подтверждения

  senderNonce   [5] OCTET STRING  OPTIONAL,
  recipNonce    [6] OCTET STRING  OPTIONAL, 
  --  nonces, используемые для защиты от 
  --  replay-атак, senderNonce вставляется
  --  создателем данного сообщения; 
  --  recipNonce является nonce, предвари-
  --  тельно вставленным в соответствующее
  --  сообщение ожидаемым получателем 
  --  данного сообщения 

  freeText    [7] PKIFreeText  OPTIONAL, 
  --  может быть использовано для указания 
  --  контекстно-зависимых инструкций

  generalInfo [8] SEQUENCE SIZE (1..MAX) OF
                 InfoTypeAndValue  OPTIONAL 
  --  может быть использовано для указания 
  --  контекстно-зависимой информации
}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF 
                UTF8String
  --  текст представлен как UTF-8 String 
  --  (замечание: каждый UTF8String должен 
  --  включать RFC 1766 language tag для
  --  указания языка, на котором 
  --  представлен текст)

    Поле pvno для данной версии спецификации фиксировано.

    Поле sender содержит имя отправителя PKIMessage.

    Данное имя (в сочетании с senderKID, если оно используется) должно применяться для проверки защиты сообщения. Если об отправителе ничего не известно (например, в сообщении начальной регистрации, когда конечный участник может не знать собственный DN, e-mail, IP адрес и т.д.), то поле sender должно содержать значение NULL ; это означает, что последовательность RDN имеет нулевую длину. В таком случае поле senderKID должно содержать идентификатор (например, номер), указывающий получателю на информацию о соответствующем разделяемом секрете, который используется для проверки сообщения.

    Поле recipient содержит имя получателя PKIMessage. Данное имя (в сочетании с recipKID, если он используется) должно применяться для проверки защиты сообщения.

    Поле protectionAlg указывает алгоритм, используемый для защиты сообщения. Если биты защиты не применяются (заметим, что PKIProtection является OPTIONAL ), то данное поле должно быть опущено; если биты защиты применяются, то данное поле также должно использоваться.

    SenderKID и recipKID используются для указания того, какие ключи были задействованы для защиты сообщения ( recipKID обычно требуется только в том случае, если для защиты сообщения используются ключи Диффи-Хеллмана).

    Поле transactionID в заголовке сообщения может использоваться для того, чтобы допускать корреляцию с предыдущим запросом. Например, в случае с RA может существовать много отложенных на данный момент запросов.

    Поля senderNonce и recipNonce защищают PKIMessage от replay-атак.

    В поле messageTime указывается время создания сообщения. Это помогает конечным участникам корректировать свое локальное время в соответствии с временем центральной системы.

    Поле freeText может использоваться для передачи получателю читаемого сообщения (на некотором языке). Первый язык используется для указания требуемого в ответе языка.

    Поле generalInfo может применяться для передачи получателю дополнительных данных для машинной обработки.

    Тело сообщения PKI

    PKIBody ::= CHOICE {   
  --  элементы, специфичные для конкретного сообщения
    ir [0] CertReqMessages,             --  Initialization Request
    ip [1] CertRepMessage,              --  Initialization Response
    cr [2] CertReqMessages,             --  Certification Request
    cp [3] CertRepMessage,              --  Certification Response
    p10cr  [4]  CertificationRequest,   --  PKCS #10 
                                        --  Certification Request
    popdecc [5] POPODecKeyChallContent, --  pop Challenge
    popdecr [6] POPODecKeyRespContent,  --  pop Response
    kur [7]  CertReqMessages,           --  Key Update Request
    kup [8]  CertRepMessage,            --  Key Update Response
    krr [9]  CertReqMessages,           --  Key Recovery Request
    krp [10]  KeyRecRepContent,         --  Key Recovery Response
    rr  [11]  RevReqContent,            --  Revocation Request
    rp  [12]  RevRepContent,            --  Revocation Response
    ccr [13]  CertReqMessages,          --  Cross-Cert. Request
    ccp [14]  CertRepMessage,           --  Cross-Cert. Response
    ckuann [15]  CAKeyUpdAnnContent,    --  CA Key Update Ann.
    cann   [16]  CertAnnContent,        --  Certificate Ann.
    rann   [17]  RevAnnContent,         --  Revocation Ann.
    crlann [18]  CRLAnnContent,         --  CRL Announcement
    conf   [19]  PKIConfirmContent,     --  Confirmation
    nested [20]  NestedMessageContent,  --  Nested Message
    genm   [21]  GenMsgContent,         --  General Message
    genp   [22]  GenRepContent,         --  General Response
    error  [23]  ErrorMsgContent        --  Error Message
}

    Конкретные типы будут описаны ниже.

    Синтаксис CertReqMessage

    Сообщение запроса сертификата состоит из запроса сертификата, необязательного поля доказательства обладания и необязательного поля регистрационной информации.

    CertReqMessages ::= SEQUENCE SIZE
  (1..MAX) OF CertReqMsg
CertReqMsg ::= SEQUENCE {
  certReq   CertRequest,
  pop       ProofOfPossession  OPTIONAL,
  -- содержание зависит от типа ключа 
  regInfo   SEQUENCE SIZE(1..MAX) of 
      AttributeTypeAndValue OPTIONAL }

    Поле доказательства обладания используется для демонстрации того, что участник, указанный в сертификате, действительно знает соответствующий закрытый ключ. Это поле может быть вычислено над содержимым поля certReq и может варьироваться в зависимости от типов алгоритма открытого ключа и режима выполнения.

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

    Информация, непосредственно относящаяся к содержимому сертификата, должна быть включена в содержимое certReq. Однако включение RAs дополнительного содержимого в certReq может привести к тому, что поле POP станет недействительным. Таким образом, данные, включаемые в содержимое сертификата, могут передаваться в regInfo.

    Защита сообщения PKI

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

    При применении защиты используется следующая структура:

    PKIProtection ::= BIT STRING

    Входом для вычисления PKIProtection является DER-представление следующей структуры данных:

    ProtectedPart ::=   SEQUENCE {
  header  PKIHeader,
  body    PKIBody
}

    Могут быть ситуации, когда PKIProtection BIT STRING сознательно не используется для защиты сообщения (т.е. это OPTIONAL поле опущено), т.к. применяется другая, внешняя по отношению к PKI, защита. Это явно допускается. Примерами такой внешней защиты являются PKCS #7 и Security Multiparts (RFC 1847) инкапсуляция PKIMessage (или просто PKIBody, если безопасность информации PKIHeader обеспечивается посредством внешних механизмов). Следует заметить, однако, что многие такие внешние механизмы требуют, чтобы конечный участник уже имел сертификат открытого ключа и/или DN и/или другую аналогичную относящуюся к инфраструктуре информацию. Таким образом, это может не соответствовать начальной регистрации, восстановлению ключа или другому процессу, характеризующемуся "начальной загрузкой". Для таких случаев может быть необходимо, чтобы использовались PKIProtection -параметры. В будущем, если внешние механизмы будут модифицированы таким образом, чтобы соответствовать сценариям начальной загрузки, использование PKIProtection станет более редким или вовсе необязательным.

    В зависимости от условий биты PKIProtection могут содержать МАС или подпись. Возможны следующие случаи:

  • Разделяемая секретная информация

    В данном случае отправитель и получатель разделяют секретную информацию (установленную внешними способами или полученную из предыдущих операций PKI). PKIProtection будет содержать значение МАС и protectionAlg будет следующим:

    PasswordBasedMac ::=
  OBJECT IDENTIFIER 
    --  {1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
  salt  OCTET STRING,
  owf   AlgorithmIdentifier,
    --  AlgId для односторонней
    --  функции OWF 
    --  (рекомендуется SHA-1)
  iterationCount     INTEGER,
    --  количество применений OWF 
  mac     AlgorithmIdentifier
    --  AlgId MAC (например,
    --  DES-MAC, Triple-DES-MAC, 
    --  или HMAC)
}

    В указанном выше protectionAlg значение salt присоединяется к разделяемому секрету. Затем OWF применяется iterationCount раз, где секрет с добавлением salt является входом в первую итерацию и вход каждой итерации является выходом предыдущей. Выход последней итерации (называемый BASEKEY ) используется для создания симметричного ключа. Если алгоритм МАС требует K -битного ключа и K < H, то используются младшие K бит BASEKEY. Если K > H, то весь BASEKEY используется для младших Н битов ключа, OWF ("2" || BASEKEY ) применяется для следующих Н битов ключа и т.д.

  • Пара ключей DH

    Когда отправитель и получатель имеют сертификаты Диффи-Хеллмана с совместимыми параметрами, для защиты сообщения конечный участник должен создать симметричный ключ, основываясь на значении своего закрытого ключа DH и открытом ключе DH получателя PKI-сообщения.

    PKIProtection будет содержать значение МАС с ключом, полученным из симметричного ключа и protectionAlg следующим образом:

    DHBasedMac ::= OBJECT IDENTIFIER 
    --  {1 2 840 113533 7 66 30}
DHBMParameter ::= SEQUENCE {
  owf     AlgorithmIdentifier,
    --   AlgId для односторонней
    --   функции (OWF) 
    --   (рекомендуется SHA-1)
  mac       AlgorithmIdentifier
    --   the MAC AlgId (например,
    --   DES-MAC, 
    --   Triple-DES-MAC или НМАС)
}

    protectionAlg OWF применяется к результату вычислений DH. Выход OWF (называемый BASEKEY ) используется для формирования симметричного ключа. Если алгоритм МАС требует K -битного ключа и K < H, то используются K младших битов BASEKEY. Если K > H, то используется весь BASEKEY для младших Н битов ключа, OWF ("1" || BASEKEY) применяется для следующих младших Н битов ключа и т.д.

  • Подпись

    Если отправитель имеет пару ключей подписывания, он может просто подписать PKI-сообщение. PKIProtection будет содержать значение подписи, protectionAlg будет определяться значением AlgorithnIdentifier.

  • Многократная защита

    В случае, когда конечный участник отправляет защищенное PKI-сообщение RA, RA может перенаправить данное сообщение СА, присоединив свою собственную защиту (которая может быть МАС или цифровой подписью, в зависимости от информации и сертификатов, разделяемых RA и СА). Это предполагает вложение всего сообщения, посылаемого конечным участником, в новое PKI-сообщение. Используется следующая структура.

    NestedMessageContent ::= PKIMessage
    •

    Общие структуры данных

    Перед тем как указывать типы, которые могут быть размещены в PKIBody, мы определим некоторые структуры данных, которые могут применяться.

    Содержимое запрашиваемого сертификата

    Различные управляющие сообщения PKI требуют, чтобы инициатор сообщения указал некоторые поля, которые должны присутствовать в сертификате. Структура CertTemplate позволяет конечному участнику или RA указать как можно больше того, что должен содержать сертификат. CertTemplate аналогична Certificate, но все поля являются необязательными.

    Заметим, что даже если инициатор полностью указал требуемое содержимое сертификата, СА имеет право модифицировать поля в сертификате, который он реально издает. Если модифицированный сертификат для запрашивающего неприемлем, можно задержать Confirmation -сообщение или послать Error -сообщение (с PKIStatus "rejection" ).

    Зашифрованные значения

    Когда в PKI сообщениях присутствуют зашифрованные значения (это могут быть либо закрытые ключи, либо сертификаты), используется структура данных EncryptedValue.

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

    Если получатель PKIMessage уже имеет закрытый ключ, используемый для дешифрования, поле encSymmKey может содержать ключ сессии, зашифрованный с использованием открытого ключа получателя.

    Коды статуса и информация о неудаче для PKI-сообщений

    Все сообщения ответа включают определенную информацию о статусе. Определены следующие значения:

    PKIStatus ::= INTEGER {
  Granted          (0),
      -- получено то, что запрашивалось
  grantedWithMods  (1),
      -- получено что-то подобное, что запрашивалось; 
	  -- запрашивающий несет ответственность за 
      -- установленные отличия 
  rejection        (2),
      -- не получено то, что запрашивалось,
	  -- более подробная информация в сообщении 
  waiting          (3),
      -- запрос не обработан,
      -- следует запросить позднее 
  revocationWarning  (4),
      -- данное сообщение содержит предупреждение, 
	  -- что скоро будет отмена 
  revocationNotification  (5),
      -- уведомление, что произошла отмена
  keyUpdateWarning   (6)
      -- изменение уже выполнено для oldCertId, 
      -- указанного в сообщении запроса изменения ключа
}

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

    PKIFailureInfo ::= BIT STRING {
    -- причин неудачи может быть много
    -- при необходимости в будущем могут 
	-- быть добавлены другие коды причин.
  badAlg  (0),
    -- нераспознанный или неподдерживаемый
    -- Идентификатор Алгоритма 
  badMessageCheck  (1),
    -- сбой в процессе проверки целостности
	-- (например, подпись не верифицирована)
  badRequest       (2),
    -- транзакция не разрешена или не поддерживается 
  badTime          (3),
    -- messageTime недостаточно точно
    -- соответствует системному времени,
	-- как определено локальной политикой 
  badCertId        (4),
    -- сертификат не может быть найден в
	-- соответствии с предоставленным критерием 
  badDataFormat    (5),
    -- переданные данные имеют
    -- неправильный формат 
  wrongAuthority   (6),
    -- уполномоченный орган, указанный 
	-- в запросе, отличается от того, 
	-- который определен в токене ответа
  incorrectData    (7),
    -- данные из запроса являются некорректными 
    -- (используется для сервисов нотариуса)
  missingTimeStamp (8),
    -- когда timestamp опущена, но
    -- должна присутствовать 
    -- (в соответствии с политикой) 
  badPOP           (9)
    -- упал РОР 
}
PKIStatusInfo ::= SEQUENCE {
  status PKIStatus,
  statusString PKIFreeText OPTIONAL,
  failInfo PKIFailureInfo OPTIONAL
}

    Идентификация сертификата

    Для идентификации конкретных сертификатов используется структура данных CertId.

    Каждый корневой СА должен иметь возможность опубликовать свой текущий открытый ключ посредством некоторых "внешних" механизмов. Хотя такие механизмы находятся вне рассматриваемой предметной области, мы определим структуры данных, которые могут ими поддерживаться.

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

    OOBCert ::= Certificate

    Поля в данном сертификате имеют следующие ограничения:

  • Сертификат должен быть самоподписанным (т.е. подпись должна проверяться с использованием поля SubjectPublicKeyInfo );
  • Поля subject и issuer должны быть идентичны;
  • Если поле subject является NULL, то оба расширения, subjectAltName и issuerAltName, должны присутствовать и иметь одно и то же значение;
  • Значения всех других расширений должны соответствовать самоподписанному сертификату (т.е. идентификаторы ключа для subject и issuer должны быть одни и те же).
    •  
    OOBCertHash ::= SEQUENCE {
  hashAlg [0] AlgorithmIdentifier
    OPTIONAL,
  certId [1] CertId OPTIONAL,
  hashVal BIT STRING
    -- hashVal вычисляется для
    -- самоподписанного 
    -- сертификата с идентификатором
    -- certID.}

    Смысл значения хэша состоит в том, чтобы любой, кто безопасно получил значение хэша (внешними способами), мог проверить самоподписанный сертификат данного СА.

    Опции архивации

    Запрашивающий может указать, что он хочет архивировать значение закрытого ключа, используя структуру PKIArchiveOptions.

    Публикуемая информация

    Запрашивающий может указать, что он хочет, чтобы PKI опубликовал сертификат, используя структуру PKIPublicationInfo.

    Структуры РОР

    Если запрос сертификата предназначен для пары ключей подписывания (т.е. запрос для верифицирующего сертификата), то доказательство обладания закрытым ключом подписывания демонстрируется с помощью структуры POPOSingingKey.

    POPOSigningKeyInput ::= SEQUENCE {
  authInfo     CHOICE {
    sender        [0] GeneralName,
    -- из PKIHeader (используется только в
	-- том случае, если аутентифицированная
    -- идентификация установлена 
    -- отправителем (например, DN из ранее
	-- выпущенного и действительного 
	-- в данный момент сертификата))
    publicKeyMAC  [1] PKMACValue
    -- используется, если в настоящий момент
	-- не существует аутентифицированного 
	-- GeneralName для отправителя; 
	-- publicKeyMAC содержит основанный на 
    -- пароле MAC (используя protectionAlg 
	-- AlgId из PKIHeader) для
    -- DER-представления publicKey
  },
  publicKey     SubjectPublicKeyInfo
    -- из CertTemplate
}

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

  • Включением закрытого ключа (шифрования) в CertRequest (в управляющей структуре PKIArchiveOptions ).
  • Тем, что СА возвращает не сертификат, а зашифрованный сертификат (например, сертификат зашифрован случайно созданным симметричным ключом и симметричный ключ зашифрован открытым ключом, для которого выпущен запрошенный сертификат) – это "непрямой" метод, описанный ранее. Конечный участник доказывает знание закрытого ключа дешифрования, посылая МАС сообщения PKIConirm, используя ключ, полученный из данного симметричного ключа. Заметим, что если более одного CertReqMsg включено в PKIMessage, то СА использует разные симметричные ключи для каждого CertReqMsg, и МАС задействует ключ, полученный из конкатенации всех этих ключей. Процедура вычисления МАС использует PasswordBasedMacAlgId, определенный выше.
  • Тем, что конечный участник обязан иметь что-то, что он указывает в протоколе вызов-ответ (используя сообщения POPODecKeyChall и POPODecKeyResp, см ниже) между CertReqMessages и CertRepMessages. Это "прямой" метод, как он определен выше. Данный метод обычно используется в окружении, в котором RA проверяет POP и затем осуществляет запрос сертификата у СА от имени конечного участника. В данном сценарии СА доверяет RA выполнять POP до того, как RA запросит сертификат для конечного участника. Полный протокол выглядит следующим образом (заметим, что req’ не обязательно должно инкапсулировать req в качестве вложенного сообщения):
    •

    Очевидно, что данный протокол является более длинным, но позволяет включать локальный RA, при этом сам сертификат реально не создается, пока не приведено доказательство обладания.

    Если запрос сертификата выполнен для пары ключей согласования ключа (Key Agreement Key – KAK), то POP может использовать любой из трех способов, описанных выше для пары ключей шифрования с учетом следующего:

  • Сертификат зашифрован с помощью симметричного ключа, полученного из закрытого KAK СА и открытого ключа, для которого выполнен запрос сертификата.
  • Вместо Challenge используется PreferredSymmAlg и симметричный ключ, полученный из закрытого KAK СА и открытого ключа, для которого выполнен запрос сертификата. В качестве альтернативы POP может использовать структуру POPOSigningKey, где поле alg есть DHBasedMAC и поле подписи есть МАС, в качестве четвертой альтернативы для демонстрации POP, если СА уже имеет D-H сертификат, который известен ЕЕ.
    •

    Сообщения вызова-ответа для доказательства обладания закрытым ключом шифрования определены следующим образом. Заметим, что обмен вызов-ответ связан с сообщением запроса сертификата (и тем самым с сообщениями ответа сертификата и подтверждением) с помощью nonces, используемых в PKIHeader, и защитой (МАС или подписыванием), примененной к PKIMessage.

    POPODecKeyChallContent ::= SEQUENCE OF Challenge
    -- один Challenge на запрос сертификата ключа 
    -- шифрования (в той же последовательности, что и 
    -- другие запросы, появляющиеся в CertReqMessages).
Challenge ::= SEQUENCE {
  owf       AlgorithmIdentifier  OPTIONAL,
    -- должен присутствовать в первом Challenge; может 
    -- быть опущен в любом следующем Challenge в 
    -- POPODecKeyChallContent (если опущен, то owf 
    -- используется в немедленно создаваемом Challenge).
  witness   OCTET STRING,
    -- результат применения односторонней функции (owf) 
    -- к случайно созданному целому A. Заметим, что для 
    -- каждого Challenge должны использоваться различные 
    -- целые.
  challenge   OCTET STRING
    -- шифрование (с использованием открытого ключа, для 
    -- которого выполнен запрос сертификата) Rand, где 
    -- Rand специфицирован как 
    --   Rand ::= SEQUENCE {
    --   int      INTEGER,
    --   – случайно созданное целое A (определено выше)
    --   sender   GeneralName
    --   – имя отправителя (как определено в PKIHeader)
    --   }
  }
POPODecKeyRespContent ::= SEQUENCE OF INTEGER
    -- один INTEGER на каждый запрос сертификата для 
    -- ключа шифрования (в порядке появления этих 
    -- запросов в CertReqMessages). Восстановленный 
    -- INTEGER A возвращается отправителю в 
    -- соответствующем Challenge.
    (рис 18.2) Полный протокол доказательства обладания закрытым ключем

    Структуры данных, используемые для каждой операции

    Запрос инициализации

    Сообщение запроса инициализации содержит в PKIBody структуру данных CertReqMessage, которая описывает запрашиваемые сертификаты. Обычно SubjectPubKeyInfo, KeyId и Validity являются шаблонными полями, которые заменяются для каждого затребованного сертификата. Считается, что данное сообщение используется для первой инициализации участника в PKI.

    Ответ инициализации

    Сообщение ответа инициализации в PKIBody структуру данных CertRepMessage, которая для каждого запрошенного сертификата имеет поле PKIStatusInfo, сертификат субъекта и, возможно, закрытый ключ (обычно зашифрованный ключом сессии, который сам зашифрован protocolEncKey ).

    Далее приводится синтаксис CertRepMessage. Заметим, что если защитой сообщения PKI является "разделяемая секретная информация", то любой сертификат, передаваемый в поле caPubs, может быть непосредственно доверенным как сертификат корневого СА инициатора.

    Запрос регистрации/сертификации

    Сообщение запроса регистрации / сертификации содержит в PKIBody структуру данных CertReqMessages, которая специфицирует запрошенные сертификаты. Считается, что данное сообщение используется для существующих в PKI участников, которые хотят получить дополнительные сертификаты.

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

    Ответ регистрации/сертификации

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

    CertRepMessage ::= SEQUENCE {
  CaPubs [1] SEQUENCE SIZE (1..MAX)
    OF Certificate OPTIONAL,
  Response  SEQUENCE OF CertResponse }
CertResponse ::= SEQUENCE {
  CertReqId  INTEGER,
    -- для установления соответствия между
	-- ответом и запросом – 1 используется,
    -- если certReqId в соответствующем 
	-- запросе не указан)
  status  PKIStatusInfo,
  certifiedKeyPair CertifiedKeyPair
    OPTIONAL,
  rspInfo OCTET STRING OPTIONAL
    -- аналогично id-regInfo-asciiPairs
    -- OCTET STRING, 
    -- определенной для regInfo
    -- в CertReqMsg 
}
CertifiedKeyPair ::= SEQUENCE {
  certOrEncCert CertOrEncCert,
  privateKey [0] EncryptedValue OPTIONAL,
  publicationInfo [1] PKIPublicationInfo
    OPTIONAL
}
CertOrEncCert ::= CHOICE {
  certificate     [0] Certificate,
  encryptedCert   [1] EncryptedValue
}

    Только одно из полей failInfo (в PKIStatusInfo ) и certificate (в CertifiedKeyPair ) может быть представлено в каждом CertResponse (в зависимости от статуса). Для некоторых значений статуса (например, waiting ) ни одно из дополнительных полей присутствовать не может.

    Сертификат может быть получен при наличии EncryptedCert и соответствующего ключа дешифрования. Это делается для того, чтобы позволить СА возвращать значение сертификата, но с тем ограничением, что только определенный получатель может получить настоящий сертификат. Преимущество данного подхода состоит в том, что СА может возвращать сертификат даже при отсутствии доказательства, что запрашивающий является конечным участником, который может использовать соответствующий закрытый ключ (заметим, что доказательство не представлено до тех пор, пока СА не получит PKIConfirm -сообщение). Таким образом, СА не будет отменять сертификат до тех пор, пока не получит неправильное доказательство обладания.

    Содержимое запроса изменения ключа

    Для запросов изменения ключа используется синтаксис CertReqMessages. Обычно SubjectPublicKeyInfo, KeyId и Validity являются шаблонными полями, которые заполняются для каждого изменяемого ключа. Считается, что данное сообщение применяется для запроса изменения существующих (не отмененных и не истекших) сертификатов.

    Содержимое ответа изменения ключа

    Для ответов об изменении ключа используется синтаксис CertRepMessage. Ответ идентичен ответу инициализации.

    Синтаксис CertRepMessage описан выше.

    Содержимое запроса восстановления ключа

    Для запросов восстановления ключа используется синтаксис, идентичный запросу инициализации CertReqMesages. Обычно SubjectPublicKeyInfo и KeyId являются шаблонными полями, которые могут применяться для указания открытого ключа подписи, для которого был запрошен сертификат.

    Содержимое ответа восстановления ключа

    Для ответов восстановления ключа используется следующий синтаксис. Для некоторых значений статуса (например, waiting ) могут присутствовать дополнительные поля.

    KeyRecRepContent ::= SEQUENCE { status
  PKIStatusInfo,
  newSigCert [0] Certificate OPTIONAL,
  caCerts [1] SEQUENCE SIZE (1..MAX) OF 
      Certificate OPTIONAL,
  keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
      CertifiedKeyPair OPTIONAL
}

    Содержимое запроса отмены

    При запросе отмены сертификата (или нескольких сертификатов) используется следующая структура данных. Имя запрашивающего присутствует в PKIHeader -структуре.

    RevReqContent ::= SEQUENCE OF RevDetails
  RevDetails ::= SEQUENCE {
  certDetails     CertTemplate,
  -- позволяет запрашивающему указать
  -- как можно больше 
  -- сведений о сертификате,
  -- для которого требуется отмена 
  -- (например, для случаев, когда
  -- serialNumber недоступен)
  revocationReason ReasonFlags OPTIONAL,
  -- причина запроса отмены 
  badSinceDate GeneralizedTime OPTIONAL,
  -- указывает максимальные знания
  -- отправителя 
  crlEntryDetails Extensions OPTIONAL
  -- запрошенные crlEntryExtensions
}

    Содержимое ответа отмены

    Ответ на предыдущее сообщение. Если отмена произведена, то данное сообщение посылается запрашивающему. Отдельное уведомление об отмене может быть послано субъекту сертификата, для которого запрошена отмена.

    RevRepContent ::= SEQUENCE {
  status SEQUENCE SIZE (1..MAX)
    OF PKIStatusInfo,
    -- в той же последовательности,
    -- как было послано в RevReqContent
  revCerts [0] SEQUENCE SIZE
    (1..MAX) OF CertId OPTIONAL,
    -- Ids, для которых запрошена отмена
    -- (тот же порядок, что и status)
  crls [1] SEQUENCE SIZE (1..MAX)
    OF CertificateList OPTIONAL
    -- результирующие CRLs (может
    -- быть более одного)
}

    Содержимое запроса кросс-сертификации

    Запросы кросс-сертификации используют тот же самый синтаксис ( CertReqMessages ), что и обычные запросы сертификации, с тем лишь ограничением, что пара ключей должна быть создана запрашивающим СА, и закрытый ключ не должен быть послан отвечающему СА.

    Содержимое ответа кросс-сертификации

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

    Содержимое оповещения об изменении ключа СА

    Когда СА изменяет собственную пару ключей, для оповещения может использоваться следующая структура данных.

    CAKeyUpdAnnContent ::= SEQUENCE {
  OldWithNew Certificate, 
    -- старый pub, подписанный новым priv
  NewWithOld Certificate, 
    -- новый pub, подписанный старым priv
  NewWithNew Certificate 
    -- новый pub, подписанный новым priv
}

    Оповещение сертификата

    Данная структура может использоваться для оповещения о существовании сертификатов.

    Считается, что данное сообщение будет использоваться в тех ситуациях (если они возникнут), когда не существует методов для опубликования сертификатов; не считается, что она будет использоваться, например, в том случае, если для опубликования сертификатов используется директория.

    CertAnnContent ::= Certificate

    Оповещение об отмене

    При выполнении СА отмены или предположении отмены может быть выпущен специальный сертификат для оповещения об этом событии.

    RevAnnContent ::= SEQUENCE {
  status PKIStatus,
  certId CertId,
  willBeRevokedAt GeneralizedTime,
  badSinceDate GeneralizedTime,
  crlDetails Extensions OPTIONAL
    -- детали extra CRL (например,
    -- crl number, reason, location, etc.)
}

    СА может использовать такое оповещение для уведомления субъекта о том, что его сертификат отменен или его предполагается отменить. Это обычно используется в тех случаях, когда запрос отмены приходит не от того субъекта, которого он касается.

    Поле willBeRevokedAt содержит время, когда новая запись будет добавлена в соответствующие CRLs.

    Оповещение о CRL

    Когда СА выпускает новый CRL (или множество CRLs), для оповещения о данном событии может использоваться следующая структура данных.

    CRLAnnContent ::= SEQUENCE
  OF CertificateList

    Содержимое подтверждения PKI

    Данная структура данных используется при трехстороннем протоколе в качестве заключительного PKIMessage. Его содержимое является одним и тем же во всех случаях – на самом деле оно не имеет содержимого, т.к. PKIHeader уже содержит всю необходимую информацию.

    PKIConfirmContent ::= NULL

    Содержимое общего сообщения PKI

    InfoTypeAndValue ::= SEQUENCE {
  infoType       OBJECT IDENTIFIER,
  infoValue       ANY DEFINED BY infoType  OPTIONAL
}
-- пример содержимого InfoTypeAndValue включает, но не 
-- ограничивается :
-- { CAProtEncCert       = {id-it 1}, Certificate       }
-- { SignKeyPairTypes     = {id-it 2}, SEQUENCE OF 
-- AlgorithmIdentifier }
-- { EncKeyPairTypes     = {id-it 3}, SEQUENCE OF 
-- AlgorithmIdentifier }
-- { PreferredSymmAlg   = {id-it 4}, AlgorithmIdentifier  }
-- { CAKeyUpdateInfo     = {id-it 5}, CAKeyUpdAnnContent  }
-- { CurrentCRL         = {id-it 6}, CertificateList   }
-- где {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
-- данная конструкция может также использоваться для 
-- определения новых сообщений запроса и ответа PKIX 
-- Certificate Management Protocol, или для сообщений, 
-- используемых для общих целей, которые могут 
-- понадобиться в будущем в конкретных окружениях.
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
  -- Может быть послано EE, RА или СA (в зависимости от 
  -- содержимого сообщения). Параметр OPTIONAL infoValue 
  -- для InfoTypeAndValue для примеров, приведенных 
  -- ниже, обычно опущен. Получатель может игнорировать 
  -- все, что содержит OBJ.IDs, которые не распознаны. 
  -- Если посылается от EE к CA, то пустое множество 
  -- указывает, что СA может послать всю/любую 
  -- интересующую информацию.

    Содержимое общего ответа PKI

    GenRepContent ::= SEQUENCE OF
  InfoTypeAndValue
  -- Получатель может игнорировать
  -- любое содержимое 
  -- OBJ.IDs, которое он не распознает.

    Содержимое сообщения об ошибках

    ErrorMsgContent ::= SEQUENCE {
  pKIStatusInfo PKIStatusInfo,
  errorCode INTEGER OPTIONAL,
  -- конкретные для реализации
  -- коды ошибок 
  errorDetails PKIFreeText OPTIONAL
  -- конкретные для реализации
  -- детали ошибок }

    Синтаксис CertRequest

    Синтаксис CertRequest состоит из запроса идентификатора, шаблона содержимого сертификата и дополнительной последовательности управляющей информации.

    CertRequest ::= SEQUENCE {
  certReqId INTEGER,  
  -- ID для обеспечения соответствия
  -- между запросом и ответом
  certTemplate CertTemplate,  
  -- поля из сертификата, который
  -- должен быть выпущен 
  controls Controls OPTIONAL  
  -- атрибуты, используемые при
  -- выпуске сертификата 
}
CertTemplate ::= SEQUENCE {
  version [0] Version OPTIONAL,
  serialNumber [1] INTEGER OPTIONAL,
  signingAlg   [2] AlgorithmIdentifier OPTIONAL,
  issuer   [3] Name OPTIONAL,
  validity [4] OptionalValidity OPTIONAL,
  subject [5] Name OPTIONAL,
  publicKey [6] SubjectPublicKeyInfo OPTIONAL,
  issuerUID [7] UniqueIdentifier OPTIONAL,
  subjectUID [8] UniqueIdentifier OPTIONAL,
  extensions [9] Extensions OPTIONAL 
}
OptionalValidity ::= SEQUENCE {
  notBefore [0] Time OPTIONAL,
  notAfter [1] Time OPTIONAL 
} 
  -- по крайней мере, одно должно быть
  -- представлено 
Time ::= CHOICE {
  utcTime UTCTime,
  generalTime GeneralizedTime 
}

    Синтаксис доказательства обладания

    ProofOfPossession ::= CHOICE {
  raVerified      [0] NULL,
    -- используется, если RA уже убедился, что 
    -- запрашивающий обладает закрытым ключом   
  signature       [1] POPOSigningKey,
  keyEncipherment [2] POPOPrivKey,
  keyAgreement    [3] POPOPrivKey 
}    
POPOSigningKey ::= SEQUENCE {
  poposkInput     [0] POPOSigningKeyInput OPTIONAL,
  algorithmIdentifier AlgorithmIdentifier,
  signature           BIT STRING 
    -- Подпись (используя "algorithmIdentifier") является 
    -- значением в DER-представлении poposkInput. 
    -- Замечание: если CertReqMsg certReq CertTemplate 
    -- содержит значения subject и publicKey, то poposkInput 
    -- должно быть опущено и подпись должна быть вычислена 
    -- для DER-представления значения CertReqMsg certReq. 
    -- Если CertReqMsg certReq CertTemplate не содержит 
    -- значения открытого ключа и субъекта, то poposkInput 
    -- должно присутствовать и должно быть подписано. Данная 
    -- стратегия гарантирует, что открытый ключ не 
    -- присутствует в полях poposkInput и CertReqMsg certReq 
    -- CertTemplate.
}
POPOSigningKeyInput ::= SEQUENCE {
  authInfo CHOICE {
  sender        [0] GeneralName,
    -- используется только если установлена 
    -- аутентифицированная идентификация для отправителя 
    -- (т.е. DN из ранее выпущенного или действительного 
    -- в настоящий момент сертификата)
  publicKeyMAC  PKMACValue },
    -- используется, если в настоящий момент нет 
    -- аутентифицированного GeneralName отправителя; 
    -- publicKeyMAC содержит MAC, основанный на пароле, 
    -- в DER-представлении значения publicKey
  publicKey     SubjectPublicKeyInfo  -- из CertTemplate
}
PKMACValue ::= SEQUENCE {
  algId  AlgorithmIdentifier,
    -- значение алгоритма должно быть PasswordBasedMac 
    -- {1 2 840 113533 7 66 13}, значение параметра есть 
    -- значение PBMParameter BIT STRING
}
POPOPrivKey ::= CHOICE {
  thisMessage       [0] BIT STRING,
    -- доказательство, представленное в данном сообщении 
    -- (содержит сам закрытый ключ, зашифрованный для СА)
  subsequentMessage [1] SubsequentMessage,
    -- доказательство приведено в следующем сообщении
dhMAC               [2] BIT STRING 
    -- для keyAgreement (только) доказательство 
    -- приведено в данном сообщении, которое содержит 
    -- MAC (для значения DER-представления параметра 
    -- certReq в CertReqMsg, которое должно включать и 
    -- subject, и publicKey), основываясь на ключе, 
    -- полученном из закрытого ключа DH конечного 
    -- участника и открытого ключа DH СА.
}
SubsequentMessage ::= INTEGER {
  encrCert (0),
    -- запросы, при которых результирующий сертификат 
    -- зашифрован для конечного участника (при этом POP 
    -- будет выполнен в подтверждающем сообщении)
  challengeResp (1) 
    -- запросы, при которых CA/RA обязан выполнить обмен 
    -- вызов-ответ с конечным участником, чтобы доказать, 
    -- что ему известен закрытый ключ
}

    Считается, что протоколы должны включать подтверждающее сообщение для сообщения вызов-ответ.

    Использование МАС, основанного на пароле

    Следующий алгоритм должен применяться при использовании publicKeyMAC в POPOSigningKeyInput для доказательства аутентичности запроса.

    PBMParameter ::= SEQUENCE {
  salt OCTET STRING,
  owf AlgorithmIdentifier,
    -- AlgId для One-Way Function
    -- (SHA-1 рекомендуется)
  iterationCount INTEGER,
    -- сколько раз применяется OWF 
  mac AlgorithmIdentifier
    -- the MAC AlgId (например,
    -- DES-MAC, Triple-DES-MAC,
    -- или HMAC) }

    Процесс, использующий PBMParameter вычисления publicKeyMAC и тем самым аутентифицирующий исходный запрос сертификата открытого ключа, состоит из двух стадий. Первая стадия использует разделяемую секретную информацию для создания ключа МАС. На второй стадии вычисляются MACs открытых ключей, с помощью данного ключа МАС для создания аутентифицирующего значения.

    Инициализация первой стадии алгоритма предполагает существование разделяемого секрета, полученного надежным способом CA/RA и конечным участником. Значение salt присоединяется к разделяемому секрету, и односторонняя функция ( owf ) применяется iterationCount раз, где секрет и salt являются входом в первую итерацию, и для каждой следующей итерации вход есть множество выходов предыдущей итерации, включая ключ K.

    На второй стадии K и открытый ключ являются входами в НМАС, в результате чего создается значение для publicKeyMAC следующим образом:

    publicKeyMAC = Hash( K XOR opad,
  Hash( K XOR ipad, public key) )

    где ipad и opad определены в RFC 2104.

    Управление публикуемой информацией

    Управление pkiPublicationInfo необходимо подписчикам для управления опубликованием СА сертификата. Определен следующий синтаксис:

    PKIPublicationInfo ::= SEQUENCE {
  action INTEGER {
    dontPublish (0),
    pleasePublish 1) },
  pubInfos SEQUENCE SIZE (1..MAX)
    OF SinglePubInfo OPTIONAL }
  -- pubInfos не должно присутствовать,
  -- если действие есть "dontPublish" 
  -- (если действие есть 
  -- "pleasePublish" и pubInfos опущено,
  -- предполагается "dontCare")
SinglePubInfo ::= SEQUENCE {
  pubMethod    INTEGER {
    dontCare       (0),
    x500           (1),
    web           (2),
    ldap           (3) },
  pubLocation   GeneralName OPTIONAL }

    Если выбрана опция dontPublish, запрашивающий указывает, что PKI не должно публиковать сертификат (это может означать, что запрашивающий сам опубликует сертификат).

    Если выбран метод dontCare или если управление PKIPublicationInfo в запросе опущено, запрашивающий указывает, что PKI может опубликовать сертификат, используя любой выбранный им способ.

    Если запрашивающему нужно, чтобы сертификат появился, по крайней мере, в некоторых местах и при этом он хочет допустить, чтобы СА сделал сертификат доступным для других репозиториев, следует установить два значения SinglePubInfo для pubInfos: одно со значением x500, web или ldap, и другое – с dontCare.

    Поле pubLocation, если имеется, указывает, где запрашивающий хочет разместить сертификат (заметим, что CHOICE в GeneralName включает, например, URL и IP адрес).

    Управление опциями архивирования

    Управление pkiArchiveOptions дает подписчикам возможность указать информацию, необходимую для установления архивирования закрытого ключа, соответствующего открытому ключу из запроса сертификата. Это определяется следующим синтаксисом:

    PKIArchiveOptions ::= CHOICE {
  encryptedPrivKey [0] EncryptedKey,
    -- реальное значение закрытого ключа

  keyGenParameters [1] KeyGenParameters,
    -- параметры, которые допускают
    -- перегенерацию закрытого ключа 

  archiveRemGenPrivKey [2] BOOLEAN 
    -- установлено в TRUE, если отправитель
    -- хочет, чтобы получатель архивировал
    -- закрытый ключ или пару ключей,
    -- которые создал получатель в ответ
    -- на данный запрос; 
    -- установлено в FALSE, если архивация 
    -- не предполагается.
}
EncryptedKey ::= CHOICE {
  encryptedValue EncryptedValue,
  envelopedData [0] EnvelopedData 
    -- зашифрованный закрытый ключ должен
    -- быть размещен в 
    -- envelopedData encryptedContentInfo
    -- encryptedContent 
    -- OCTET STRING.
}
EncryptedValue ::= SEQUENCE {
  intendedAlg [0] AlgorithmIdentifier OPTIONAL,
    -- предполагаемый алгоритм, для
    -- которого будет 
    -- использоваться значение 

  symmAlg [1] AlgorithmIdentifier OPTIONAL,
    -- симметричный алгоритм, используемый
    -- для шифрования значения 

  encSymmKey [2] BIT STRING  OPTIONAL,
    -- (зашифрованный) симметричный ключ,
    -- используемый для шифрования значения

  keyAlg [3] AlgorithmIdentifier OPTIONAL,
    -- алгоритм, используемый для
    -- шифрования симметричного ключа 

  valueHint [4] OCTET STRING OPTIONAL,
    -- краткое описание или идентификатор
    -- содержимого encValue (может иметь 
    -- значение только для посылающего и
    -- использоваться только если 
    -- EncryptedValue должно перепроверяться
    -- посылающим в будущем)

  encValue BIT STRING 
}
KeyGenParameters ::= OCTET STRING

    Альтернативой посылки ключа является посылка информации о том, как заново создать ключ, используя выбор KeyGenParameters (например, для многих реализаций RSA можно послать первое случайное простое число).

    Схема LDAPv2 для инфраструктуры открытого ключа Х.509

    Рассматриваемая схема является минимальной схемой для поддержки PKI для протокола LDAPv2. Определим только компоненты, относящиеся к PKI. LDAP-серверы, функционирующие как репозитории PKI, должны поддерживать вспомогательные классы объектов и соответствующим образом интегрировать спецификацию данной схемы с общей схемой и другими схемами, специфичными для других приложений.

    LDAPv2 является одним из протоколов для доступа к репозиторию PKI. Также определены другие протоколы, такие как HTTP. Если LDAP-сервер, доступный по LDAPv2, используется в качестве репозитория, минимальное требование состоит в том, что репозиторий должен поддерживать дополнительные записи каталога для сертификатов Х.509.

    Определим атрибуты и классы объектов, используемые LDAP-серверами, функционирующими в качестве репозиториев PKI, которые должны понимать клиенты LDAP, взаимодействующие с этими репозиториями для запроса, добавления, модификации и удаления информации PKI.

    Объекты репозитория PKI

    Объектами, представленными в репозитории, являются:

  • Конечные участники.
  • СА.
    •

    Следующий вспомогательный класс объекта может использоваться для представления субъектов сертификата:

    pkiUser OBJECT-CLASS ::= {
  SUBCLASS OF { top}
  KIND auxiliary
  MAY CONTAIN {userCertificate}
  ID joint-iso-ccitt(2) ds(5)
    objectClass(6) pkiUser(21)
}
userCertificate ATTRIBUTE ::=  {
  WITH SYNTAX Certificate
  EQUALITY MATCHING RULE
    certificateExactMatch
  ID  joint-iso-ccitt(2) ds(5)
    attributeType(4) 
    userCertificate(36) 
}

    Конечный участник может получить один или более сертификатов от одного или более СAs. Атрибут userCertificate должен использоваться для представления этих сертификатов в записи каталога , относящейся к данному пользователю.

    Следующий вспомогательный класс объекта может применяться для представления CAs:

    pkiCA OBJECT-CLASS ::= {
  SUBCLASS OF { top}
  KIND auxiliary
  MAY CONTAIN {cACertificate |
      certificateRevocationList |
      authorityRevocationList |
      crossCertificatePair }
  ID   joint-iso-ccitt(2) ds(5)
    objectClass(6) pkiCA(22)
}
cACertificate ATTRIBUTE ::=  {
  WITH SYNTAX Certificate
  EQUALITY MATCHING RULE
    certificateExactMatch
  ID joint-iso-ccitt(2) ds(5)
     attributeType(4) 
     cACertificate(37) 
}
crossCertificatePairATTRIBUTE::={
  WITH SYNTAX   CertificatePair
  EQUALITY MATCHING RULE
    certificatePairExactMatch
  ID joint-iso-ccitt(2) ds(5)
     attributeType(4) 
     crossCertificatePair(40)
}

    Атрибут cACertificate записи каталога СА должен использоваться для хранения самоподписанных сертификатов (если они есть) и сертификатов, выпущенных для данного СА САs из той же области, что и данный СА.

    Forward -элементы crossCertificatePair -атрибута записи каталога СА должны использоваться для хранения всех сертификатов, выпущенных данным СА за исключением самоподписанных сертификатов. Дополнительно reverse элементы crossCertificatePair -атрибута записи каталога СА могут содержать подмножество сертификатов, выпущенных данным СА для других CAs. Когда присутствуют оба элемента, forward и reverse, в значении одного атрибута, имя выпускающего в одном сертификате должно соответствовать имени субъекта в другом и наоборот, и открытый ключ субъекта в одном сертификате должен иметь возможность проверять подпись в другом сертификате и наоборот.

    Если присутствует элемент reverse, значение forward -элемента и значение reverse -элемента не обязательно должны являться значениями одного о того же атрибута; другими словами они могут являться значениями как одного атрибута, так и значениями двух атрибутов.

    В случае v3 сертификатов ни один из перечисленных выше сертификатов не должен включать расширение basicConstraints со значением сА, установленным в FALSE.

    Определение области относится исключительно к локальной политике.

    certificateRevocationListATTRIBUTE::={
    WITH SYNTAX  CertificateList
    EQUALITY MATCHING RULE
      certificateListExactMatch
    ID joint-iso-ccitt(2) ds(5)
      attributeType(4)
      certificateRevocationList(39)
}

    Атрибут certificateRevocationList, если присутствует в конкретной записи СА, содержит CRL(s).

    authorityRevocationListATTRIBUTE::={
    WITH SYNTAX   CertificateList
    EQUALITY MATCHING RULE
      certificateListExactMatch
    ID joint-iso-ccitt(2) ds(5)
      attributeType(4)
    authorityRevocationList(38)
}

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

    Точки распространения CRL являются дополнительным механизмом, который может использоваться для распространения информации об отмене.

    Если СА решает задействовать точки распространения CRL, для этого используется следующий класс объектов.

    cRLDistributionPoint OBJECT-CLASS::= {
  SUBCLASS OF { top }
  KIND structural
  MUST CONTAIN { commonName }
  MAY CONTAIN {
     certificateRevocationList |
     authorityRevocationList |
     deltaRevocationList }
  ID joint-iso-ccitt(2) ds(5)
     objectClass(6) 
     cRLDistributionPoint(19) }

    Атрибуты certificateRevocationList и authorityRevocationList определены выше.

    Атрибут commonName и атрибуты deltaRevocationList, определенные в Х.509, продублированы ниже.

    commonName   ATTRIBUTE::={
  SUBTYPE OF name
  WITH SYNTAX DirectoryString
  ID joint-iso-ccitt(2) ds(5)
    attributeType(4) 
    commonName(3) 
}
deltaRevocationList ATTRIBUTE ::= {
  WITH SYNTAX CertificateList
  EQUALITY MATCHING RULE
    certificateListExactMatch
  ID joint-iso-ccitt(2) ds(5)
    attributeType(4)
    deltaRevocationList(53) }

    Дельта CRLs является дополнительным механизмом, который может применяться для осуществления распределения информации об отмене.

    Если СА выбирает использование дельта CRLs, применяется представленный здесь класс объекта.

    deltaCRL OBJECT-CLASS ::= {
  SUBCLASS OF { top }
  KIND auxiliary
  MAY CONTAIN { deltaRevocationList }
  ID joint-iso-ccitt(2) ds(5)
    objectClass(6) deltaCRL(23) 
}

    Возможный транспорт

    Транспортные протоколы, описанные ниже, позволяют конечным участникам, RAs и CАs передавать друг другу PKI-сообщения. Не существует требований относительно применения конкретных механизмов безопасности на данном уровне, если сообщения PKI соответствующем образом защищены (это так, если используется OPTIONAL PKIProtection параметр, как определено для каждого сообщения).

    Протокол управления на основе файла

    Файл, содержащий сообщение PKI, должен содержать только DER- представление одного PKI-сообщения, например, там не должно быть внешнего заголовка или информации в конце данного файла.

    Такие файлы могут применяться для передачи PKI-сообщений, с помощью, например, FTP.

    Протокол управления, основанный на ТСР

    Используется следующий простой протокол, основанный на ТСР, для передачи PKI-сообщений. Данный протокол соответствует случаям, когда конечный участник (или RA) инициирует транзакцию и может принимать результаты.

    Если транзакция инициируется PKI-участником (RA или СА), то конечный участник должен либо задействовать listener-процесс, либо иметь соответствующую ссылку, которая позволяет получать PKI-сообщения от компонента управления PKI.

    Протокол предполагает существование listener-процесса на RA или СА, который может принимать PKI-сообщения на определенный порт (номер порта 829). Обычно инициатор связывается с данным портом и передает начальное PKI-сообщение для данного ID транзакции. Отвечающий передает PKI-сообщение и/или номер ссылки, который будет использоваться позднее для получения реального PKI- сообщения ответа.

    Если на данный запрос получено несколько PKI-сообщений ответа (возможно, если некоторая часть запроса обрабатывается быстрее, чем остальные), то также возвращается новая ссылка.

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

    Инициатор транзакции посылает получателю <<direct TCP-based PKI message>>. Получатель отвечает аналогичным сообщением.

    <<direct TCP-based PKI message>> состоит из:

    length (32 бита), flag (8 бит), value

    Протокол управления по e-mail

    Данный раздел описывает способы для пересылки сообщений в представлении ASN.1 для обменов, рассмотренных в предыдущем разделе, с помощью e-mail.

    Простой MIME объект определяется следующим образом.

    Content-Type: application/pkixcmp
Content-Transfer-Encoding: base64
<<the ASN.1 DER-encoded PKIX-CMP
   message, base64-encoded>>

    Данный объект MIME может быть послан или получен с использованием общего MIME, предоставляя простой почтовый транспорт для PKIX-CMP сообщений. Реализации могут также распознавать и задействовать MIME-тип application/x-pkixcmp (определенный в более ранних версиях), чтобы обеспечить обратную совместимость.

    Протокол управления по НТТР

    Данный подраздел описывает способы для пересылки сообщений в ASN.1 представлении для обменов, описанных в предыдущем разделе, с помощью НТТР.

    Простой MIME объект описывается следующим образом.

    Content-Type: application/pkixcmp
<<the ASN.1 DER-encoded
    PKIX-CMP message>>

    Данный MIME-объект может быть послан или получен с использованием НТТР, используя простой браузер-ориентированный транспорт для PKIX-CMP сообщений. Реализации могут также распознавать и использовать тип MIME application/x-pkixcmp (определенный в более ранних версиях), для обеспечения обратной совместимости.

    Протоколы управления по LDAP v2

    Данный протокол предназначен для предоставления доступа к репозиториям PKI для получения информации и управления этой информацией. Протокол основан на LDAP v2, определенном в RFC 1777.

    Рассмотрим требования для получения информации PKI X.509 из репозитория, включая сертификаты и CRLs.

    Конечные участники и САs, используя подмножество протокола LDAPv2, получают информацию PKI из репозитория.

    САs помещает информацию PKI в репозиторий, также используя подмножество протокола LDAPv2.

    Рассмотрим получение информации PKI из репозитория и управление информацией PKI в нем. Опишем профиль протокола LDAPv2 для выполнения этих функций.

    Приведем требования для получения информации PKI (сертификат, CRL или другая представляющая интерес информация) из записи в репозитории, когда данная запись (либо конечного участника, либо СА) имеет известное имя. При этом используется термин "чтение репозитория".

    Рассмотрим требования, когда имя записи неизвестно, но может использоваться некоторая другая информация для фильтрации записей в репозитории. При этом используется термин "поиск в репозитории".

    Рассмотрим требования для САs для добавления, удаления и модификации информации PKI (сертификат, CRL или другая представляющая интерес информация) в репозитории. При этом используется термин "модификация репозитория".

    Далее описано подмножество LDAPv2 поддержки каждой из этих функций. Заметим, что сервис поиска в репозитории является более общим относительно сервиса чтения репозитория в терминах функциональности LDAPv2.

    LDAP чтение репозитория

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

    BindRequest (и BindResponse)
SearchRequest (и SearchResponse)
UnbindRequest

    Bind Request

    Приложение, предоставляющее LDAP сервис чтения репозитория, должно реализовать следующее подмножество данной операции:

    BindRequest ::= [APPLICATION 0] SEQUENCE {
    version  INTEGER (2),
    name     LDAPDN, 
     -- должен приниматься NULL LDAPDN
    simpleauth [0] OCTET STRING 
     -- должен приниматься NULL simple }

    Приложение, предоставляющее сервис чтения репозитория, может также реализовать другие возможности BindRequest.

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

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

    Bind Response

    Приложение, предоставляющее сервис чтения репозитория, должно полностью реализовать данный элемент протокола, при этом могут возвращаться только следующие коды ошибок при выполнении операции Bind:

    success                   (0),
operationsError           (1),
  protocolError           (2),
  authMethodNotSupported  (7),
  noSuchObject            (32),
  invalidDNSyntax         (34),
  inappropriateAuthentication (48),
  invalidCredentials      (49),
  busy                    (51),
  unavailable             (52),
  unwillingToPerform      (53),
  other                   (80)

    Search Request

    Приложение, предоставляющее LDAP сервис чтения репозитория, должно реализовывать следующее подмножество SearchRequest:

    SearchRequest ::= [APPLICATION 3] SEQUENCE {
  baseObject  LDAPDN,
  scope       ENUMERATED {baseObject (0), },
  derefAliases ENUMERATED {
     neverDerefAliases (0),
  },
  sizeLimit  INTEGER (0),
  timeLimit  INTEGER (0),
  attrsOnly  BOOLEAN, -- FALSE only
  filter     Filter,
  attributes SEQUENCE OF AttributeType
}
Filter ::= CHOICE {
  present [7] AttributeType,
   -- только "objectСlass"
}

    Данное подмножество LDAPv2 SearchRequest обеспечивает операцию " read " LDAPv2: поиск объекта с использованием фильтра для проверки существования атрибута objectClass.

    Приложение, предоставляющее сервис чтения репозитория, может также реализовать другие возможности SearchRequest.

    Search Response

    Приложение, предоставляющее LDAP сервис поиска в репозитории, должно полностью реализовать SearchResponse.

    Заметим, что в том случае, когда атрибут имеет несколько значений, например, userCertificate, SearchResponse содержит все значения, предполагая, что запрашивающий имеет достаточно прав доступа. У приложения или доверяющей группы может возникнуть необходимость выбрать для использования соответствующее значение. Заметим также, что получение сертификата из именованной записи не гарантирует, что сертификат будет включать то же самое DN, и в некоторых случаях subjectDN в сертификате может быть NULL.

    LDAP поиск в репозитории

    Для поиска в репозитории записи, содержащей сертификат, CRL или другую интересующую информацию, с использованием произвольного критерия, необходимо подмножество следующих трех операций LDAP:

    BindRequest (и BindResponse), 
SearchRequest (и SearchResponse)
UnbindRequest

    Далее приведено требуемое подмножество для каждой операции.

    Search Request

    Приложение, предоставляющее сервис поиска в репозитории LDAP, должно реализовать следующее подмножество протокола SearchRequest.

    SearchRequest ::= [APPLICATION 3] SEQUENCE {
  baseObject   LDAPDN,
  scope ENUMERATED {
    baseObject   (0),
    singleLevel  (1),
    wholeSubtree (2)
  },
  
  derefAliases   ENUMERATED {
    neverDerefAliases (0),
  },
  
  sizeLimit INTEGER (0 .. maxInt),
  timeLimit INTEGER (0 .. maxInt),
  attrsOnly BOOLEAN,  -- FALSE only
  filter Filter,
  attributes SEQUENCE OF
  AttributeType 
}

    Должны поддерживаться все аспекты SearchRequest, за исключением следующего:

  • Необходимо поддерживать только значение neverDeferAliases для deferAliases.
  • Необходимо поддерживать только значение FALSE для attrsOnly.
    •

    Данное подмножество предоставляет более общие возможности поиска. Это надмножество подмножества SearchRequest, определенного выше. Элементами, добавляемыми в данный сервис, являются:

  • Должна поддерживаться область singleLevel и wholeSubtree.
  • Включен sizeLimit.
  • Включен timeLimit.
  • Существует возможность фильтрации.
    •

    Приложение, предоставляющее сервис поиска в репозитории LDAP, может также реализовывать и другие аспекты SearchRequest.

    LDAP модификация репозитория

    Для добавления, удаления и модификации PKI информации в репозитории требуется подмножество следующих операций LDAP:

    BindRequest (и BindResponse), 
ModifyRequest (и ModifyResponse), 
AddRequest (и AddResponse)
DelRequest (и DelResponse),
UnbindRequest

    Далее определяется требуемое подмножество для каждой операции.

    Bind

    Приложение, предоставляющее сервис модификации репозитория LDAP, должно реализовывать следующее подмножество операций:

    BindRequest ::= [APPLICATION 0] SEQUENCE {
  version INTEGER (2),
  name    LDAPDN,
  simpleauth [0] OCTET STRING }

    Сервис модификации репозитория LDAP должен реализовывать аутентифицированный доступ.

    Необходимые подмножества BindResponse являются теми же, что были описаны выше.

    ModifyRequest

    Приложение, предоставляющее сервис модификации в репозитории LDAP, должно реализовывать следующее подмножество протокола ModifyRequest.

    ModifyRequest ::= [APPLICATION 6] SEQUENCE {
  object LDAPDN,
  modification SEQUENCE OF SEQUENCE {
    operation ENUMERATED   {
      add (0),
      delete (1)
    },
    modification SEQUENCE {
      type AttributeType,
      values SET OF
      AttributeValue
    }
  }
}

    Необходимо поддерживать только значения add и delete для ModifyRequest.

    Страницы:

    Протоколы PKI управления сертификатом

    Введение

    В этой лекции будут рассматриваться управляющие протоколы PKI.

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

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

    Протоколы управления требуются для поддержки on-line взаимодействия между компонентами PKI. Например, протокол управления должен использоваться между СА и системой клиента, с которым связана пара ключей, или между двумя САs, которые выпустили кросс-сертификаты друг для друга.

    Все конечные участники требуют локального безопасного доступа к некоторой информации – как минимум к своему собственному имени и закрытому ключу, имени СА, который является доверенным для данного участника, и открытому ключу СА (или дайджесту открытого ключа, если допустима самосертифицированная версия). Может использоваться локальное безопасное хранение и для большего количества информации (например, сертификата конечного участника или информации, относящейся к приложению). Форма хранения также может быть различной – от файлов до неподделываемых криптографических токенов. Такое локальное доверенное хранение мы будем определять как персональное безопасное окружение (Personal Security Environment – PSE) конечного участника.

    Хотя форматы PSE находятся вне рассматриваемой предметной области (в частности, они очень зависят от оборудования), здесь мы определим общий формат обмена для PSEs.

    Требования к управлению PKI

    Рассматриваемые протоколы должны удовлетворять следующим требованиям к управлению PKI.

  • Управление PKI должно соответствовать стандарту ISO 9594-8 и связанным с ним расширениям сертификата.
  • Управление PKI должно соответствовать остальным частям стандарта Х.509 v3.
  • Должна быть возможность регулярного изменения любой пары ключей без влияния на какую-либо другую пару ключей.
  • Использование сервисов, обеспечивающих конфиденциальность, в протоколах управления PKI должно быть сведено к минимуму, чтобы уменьшить связанные с этим проблемы.
  • Протоколы управления PKI должны допускать использование различных криптографических алгоритмов, являющихся промышленными стандартами (специально включая только RSA, DSA, MD5, SHA-1). Это означает, что данный СА, RA или конечный участник могут в принципе использовать для своей пары ключей любой набор алгоритмов.
  • Протоколы управления PKI не должны препятствовать созданию пары ключей как конечным участником, так и RA или СА –ключ может создаваться где-то еще, но в целях управления PKI мы можем предполагать, что генерация ключа происходит в тот момент, когда он впервые передан конечному участнику, RA или СА.
  • Протоколы управления PKI должны поддерживать опубликование сертификатов, относящихся к конечным участникам, RA или СА.
  • Протоколы управления PKI должны поддерживать создание CRLs, позволяя сертифицированным конечным участникам посылать запросы на отмену сертификатов – это должно быть организовано так, чтобы невозможно было предпринять DoS-атаку.
  • Протоколы управления PKI должны использоваться поверх различных транспортных механизмов, включая LDAP, SMTP, HTTP, TCP/IP и FTP.
  • Конечным уполномоченным органом при создании сертификата является СА; предполагается, что оборудование ни конечного участника, ни RA не может выпустить сертификат – СА может изменить значения полей сертификата или может добавить, удалить или изменить расширения в соответствии со своей политикой функционирования. Например, СА может уменьшить запрошенный период действительности. Заметим, что политика может определять, что СА не должен публиковать или каким-то другим образом распределять сертификат, пока участник не просмотрит и не получит заново созданный сертификат (обычно с использованием PKIConfirm -сообщения).
  • Должна поддерживаться возможность гибкого изменения от одной нескомпрометированной пары ключей СА к следующей (заметим, что если ключ СА скомпрометирован, переинициализация должна выполняться для всех участников в домене данного СА). Конечный участник, чей PSE содержит новый открытый ключ СА (следуя изменению ключа СА ) должен также иметь возможность проверять сертификаты, с использованием старого открытого ключа. Конечные участники, которые непосредственно доверяют старой паре ключей СА, должны также иметь возможность проверять сертификаты, подписанные с использованием нового закрытого ключа СА. (Обычно это требуется в ситуациях, когда старый открытый ключ СА "встроен" в криптографическое оборудование конечного участника.)
  • Функции RA в некоторых реализациях или окружениях выполняются самим СА. Протоколы должны быть разработаны так, чтобы конечные участники могли использовать тот же протокол (но, конечно, не тот же ключ!) независимо от существующей взаимосвязи RA или СА.
  • При запросе конечным участником сертификата, содержащего данное значение открытого ключа, конечный участник должен быть готов продемонстрировать обладание соответствующим значением закрытого ключа. Это можно организовать по-разному, в зависимости от типа алгоритма открытого ключа.
    •

    Операции управления PKI

    Множество операций, для которых определены управляющие сообщения, могут быть сгруппированы следующим образом.

  • Инициализация СА: при инициализации нового СА должны выполняться определенные шаги, такие как создание начальных CRLs, экспорт открытого ключа СА и т.п.
  • Инициализация конечного участника; данная операция включает импорт открытого ключа корневого СА и запрошенной информации об опциях, поддерживаемых управляющим участником PKI.
  • Сертификация: множество операций, в результате которых создается новый сертификат.
  • Начальная регистрация / сертификация – это процесс, в результате которого конечный участник впервые сообщает о себе СА или RA, до того как СА выпустит сертификат или сертификаты для данного конечного участника. Конечным результатом данного процесса (если он успешен) является выпуск сертификата для открытого ключа участника и возврат этого сертификата конечному участнику и/или помещение его в открытый репозиторий. Данный процесс может включать (и обычно включает) несколько "шагов", таких как инициализация оборудования конечного участника. Например, оборудование конечного участника может быть безопасно инициализировано открытым ключом СА, который будет использоваться для проверки действительности сертификационных путей. Более того, конечному участнику обычно бывает необходима инициализация собственной пары ключей.
  • Изменение пары ключей: каждая пара ключей должна регулярно изменяться (замещаться новой парой), и должен выпускаться новый сертификат.
  • Изменение сертификата: после того, как срок действительности сертификата истек, он может быть обновлен, если было соответствующее уведомление.
  • Изменение пары ключей СА: как и в случае конечных участников пара ключей СА должна регулярно изменяться; при этом требуются различные механизмы, позволяющие в течение некоторого времени использовать как новый, так и старый открытые ключи СА.
  • Запрос кросс-сертификации: один СА запрашивает выпуск кросс-сертификата у другого СА. В данном стандарте определены следующие термины. Кросс-сертификат – это сертификат, в котором subject CA и issuer CA различны, и SubjectPublicKeyInfo содержит ключ проверки (например, сертификат выпущен для пары ключей подписывания subject CA). Когда необходимо более тонкое различие, могут использоваться следующие термины: кросс-сертификат называется междоменным кросс-сертификатом, если subject и issuer CA принадлежат различным административным доменам; в противном случае он называется внутридоменным кросс-сертификатом.

    Замечание 1. Во многих окружениях термин "кросс-сертификат", если не будет дальнейшего уточнения, обычно считается синонимом "междоменного кросс-сертификата ".

    Замечание 2. Выпуск кросс-сертификатов может быть взаимным; это означает, что два СА могут выпустить кросс-сертификаты друг для друга, но также возможна ситуация, когда только один СА выпускает кросс-сертификат для другого СА.

  • Изменение кросс-сертификата: происходит аналогично обычному изменению сертификата, но операция относится к кросс-сертификату.
    •
  • Операции опубликования сертификата и/или CRL: результатом некоторых операций управления PKI является опубликование сертификатов или CRLs:
  • Опубликование сертификата: способы включают использование определенных сообщений или применение конкретного протокола (LDAP, например).
  • Опубликование CRL аналогично опубликованию сертификата.
  • Операции восстановления: определенные операции управления PKI используются при потере конечным участником своего PSE.
  • Восстановление пары ключей: в качестве дополнительной возможности материал ключа пользователя (например, закрытый ключ пользователя, применяемый для шифрования) может быть сохранен СА, RA или системой архивирования, связанной с СА или RA. Если данный материал ключа необходимо восстановить (например, был забыт пароль или потерян файл ключей), может потребоваться протокол для поддержки такого восстановления.
  • Операции отмены: результатом определенных операций PKI является создание новых записей CRL и/или новых CRLs.
  • Запрос отмены: авторизованная личность оповещает СА об исключительной ситуации, требующей отмены сертификата.
  • PSE операции: хотя определение операций PSE (например, пересылка PSE, цепочка PIN и т.д.) находится вне данной предметной области, определено специальное сообщение, которое может служить основой для таких операций.

    • Заметим, что on-line протоколы являются не единственным способом реализации перечисленных выше операций. Для всех операций существуют off-line методы, с помощью которых можно добиться того же самого результата, и в принципе никто не требует задействовать исключительно on-line протоколы. Например, если используется аппаратный токен, многие операции могут быть получены как часть физической доставки токена.

    Далее определим множество стандартных сообщений, поддерживающих перечисленные выше операции. Также определим протоколы для доставки этих сообщений в различных окружениях (на основе различных протоколов).

    Инициализация конечного участника

    Первым действием конечного участника является запрос информации о поддерживаемых функциях PKI и безопасное получение открытого ключа (ключей) соответствующего корневого СА.

    Начальная регистрация/сертификация

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

    Однако можно классифицировать схемы начальной регистрации / сертификации, которые могут поддерживаться. Заметим, что слово "начальная" является ключевым – мы имеем дело с ситуацией, когда конечный участник ранее не имел контакта с PKI. Если конечный участник уже обладает сертифицированными ключами, то возможны некоторые упрощения или альтернативы.

    Составив классификацию схем, мы определим некоторые из них как обязательные и некоторые – как дополнительные. Обязательные схемы должны охватывать достаточное количество реальных случаев, в то время как дополнительные схемы применяются в исключительных случаях, которые возникают реже. Таким образом можно добиться баланса между гибкостью и легкостью реализации.

    Рассмотрим классификацию схем начальной регистрации / сертификации.

    Используемые классификации схем

    Инициализация регистрации/сертификации

    Пользуясь терминами создаваемых сообщений PKI, можно сказать, что инициализация начальных обменов регистрации / сертификации происходит в момент создания конечным участником первого сообщения. Заметим, что в реальном мире инициализация процедуры регистрации / сертификации может происходить как-то еще (например, по телефону).

    Начальная аутентификация сообщения конечного участника

    On-line сообщения, созданные конечным участником, запрашивающим сертификат, могут быть как аутентифицированы, так и нет. Требованием является аутентификация подлинности любых сообщений от конечного участника к PKI (CA/RA).

    Подобная аутентификация может обеспечиваться следующим образом: PKI (CA/RA) передает конечному участнику секретное значение (ключ начальной аутентификации) и справочное значение (используемое для идентификации транзакции) некоторыми внешними способами. Ключ начальной аутентификации может затем использоваться для защиты соответствующих значений PKI.

    Мы можем таким образом классифицировать схемы начальной регистрации / сертификации в соответствии с тем, аутентифицированы on-line сообщения EE к PKI или нет.

    Замечание 1: мы не рассматриваем аутентификацию сообщений PKI к EE, т.к. она требуется ВСЕГДА. В любом случае открытый ключ СА может быть инсталлирован в оборудовании конечного участника или аутентификация может быть основана на ключе начальной аутентификации.

    Замечание 2: процедура начальной регистрации / сертификации может быть безопасна, если сообщения от конечного участника аутентифицированы некоторыми внешними способами (например, непосредственным визитом).

    Расположение генератора ключа

    Будем считать, что "генерация ключа" происходит всякий раз, когда открытый или закрытый компоненты ключа впервые появляется в PKIMessage. Заметим, что это не препятствует централизованному сервису генерации ключа – реальная пара ключа может быть создана где-то еще и передана конечному участнику, RA или СА с использованием (собственного или стандартного) протокола запроса/ответа генератора ключа.

    Существует три возможных размещения "генератора ключа": конечный участник, RA или СА.

    Подтверждение успешной сертификации

    После создания начального сертификата для конечного участника дополнительная гарантия может быть достигнута тем, что конечный участник явно подтверждает успешное получение сообщения, содержащего сертификат или указывающего на его создание. Естественно, это подтверждающее сообщение должно быть защищено (с помощью ключа начальной аутентификации или другим способом).

    СА создает и передает конечному участнику данные активации – значения данных, отличные от ключей, необходимые для функционирования криптографических модулей, которые должны быть защищены (например, PIN, парольная фраза или разделяемый вручную ключ).

    Это дает две возможности: с подтверждением или без.

    Обязательные схемы

    Приведенная выше классификация применима для большого числа схем начальной регистрации / сертификации. Будем считать, что оборудование СА, оборудование RA и оборудование конечного участника должно поддерживать вторую схему, описанную ниже. По желанию любой участник может дополнительно поддерживать и другие схемы.

    Централизованная схема

    В терминах приведенной выше классификации данная схема является самой простой:

  • Инициализация осуществляется на сертифицирующем СА;
  • Никакой on-line аутентификации сообщения не требуется;
  • "Генерация ключа" происходит на сертифицирующем СА;
  • Никакого подтверждающего сообщения не требуется.
    •

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

    Базовая схема аутентификации

    В терминах приведенной выше классификации данная схема определяется следующим образом:

  • Инициализацию осуществляет конечный участник;
  • Аутентификация сообщения ТРЕБУЕТСЯ;
  • "Генерация ключа" осуществляется конечным участником;
  • Подтверждающее сообщение требуется.
    •

    В терминах потока сообщений базовая схема аутентификации будет следующей (см. рис.18.1).

    Если проверка подтверждающего сообщения не проходит, RA/CA должен отменить только что выпущенный сертификат, если он был опубликован или сделан доступным каким-либо еще способом.

    Доказательство обладания (Proof of Possession – РОР) закрытым ключом

    Для того чтобы предотвратить основные атаки и позволить CA/RA выполнить проверку соответствия конечного участника и пары ключей, определены операции управления PKI, которые дают конечному участнику возможность доказать, что он обладает закрытым ключом (и может использовать его), соответствующим открытому ключу, для которого запрошен сертификат. CA/RA самостоятельно выбирает, как выполнить РОР (например, с использованием внешних механизмов или специальных управляющих сообщений). Однако требуется, чтобы CAs/RАs выполняли РОР определенным способом, так как сейчас существует много не-PKI протоколов (в частности, протоколы e-mail), которые явно не проверяют связь между конечным участником и закрытым ключом. До тех пор, пока протоколы, которые выполняют проверку связывания (для пары ключей подписывания, шифрования и согласования ключа), используются не везде, предполагается, что такое связывание проверяется только CA/RA. Таким образом, если связывание не проверяется CA/RA, то сертификаты являются менее надежными.

    (рис 18.1) Базовая схема аутентификации

    POP выполняется различными способами, зависящими от типа ключа, для которого требуется сертификат. Если ключ может использоваться для нескольких целей (например, ключ RSA), то может применяться любой подходящий метод (например, ключ, который может быть задействован как для подписывания, так и для других целей, не должен посылаться CA/RA для доказательства обладания).

    Данная спецификация явно предназначена для случаев, когда конечный участник предоставляет соответствующее доказательство для RA, и RA затем сообщает СА, что доказательство получено (и проверено). Например, конечный участник, который хочет иметь сертифицированный ключ подписывания, может послать соответствующую подпись в RA, который затем уведомит СА, что конечный участник предоставил необходимое доказательство. Однако такая ситуация допустима не всегда (например, СА может допускать проверку POP только в течение сертификации ).

    Ключи подписывания

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

    Ключи шифрования

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

    Прямой метод состоит в том, что CA/RA создает случайный вызов, на который требуется немедленный ответ ЕЕ.

    Косвенный метод состоит в том, что выпускается сертификат, который шифруется для конечного участника (и конечный участник демонстрирует свою способность дешифровать сертификат в подтверждающем сообщении). Это позволяет СА выпускать сертификат в форме, которая может использоваться только соответствующим конечным участником.

    Рекомендуется задействовать косвенный метод, т.к. это не требует посылки дополнительных сообщений (т.е. доказательство может быть продемонстрировано с использованием трех сообщений {запрос, ответ, подтверждение}).

    Ключи согласования ключа

    Для ключей согласования ключа конечный участник и CA/RA должны установить разделяемый секретный ключ, чтобы доказать, что конечный участник обладает закрытым ключом.

    Заметим, что это накладывает определенные ограничения на ключи, которые могут быть сертифицированы данным СА – в частности, для ключей Диффи-Хеллмана конечный участник может свободно выбрать параметры алгоритма – предполагая, что СА в случае необходимости может создать короткую (или одноразовую) пару ключей с соответствующими параметрами.

    Изменение ключа корневого СА

    Данное обсуждение касается только САs, которые являются корневыми СА для некоторого конечного участника.

    Основа описанной здесь процедуры состоит в том, что СА защищает свой новый открытый ключ, используя предыдущий закрытый ключ, и наоборот. Таким образом, если СА изменяет свою пару ключей, он должен создать два дополнительных значения атрибута сертификата cACertificate, если сертификаты доступны с использованием Х.500 директории (всего четыре сертификата: OldWithOld; OldWithNew; NewWithOld; NewWithNew).

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

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

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

    Замечание 2: данная схема заставляет ЕЕ получать (внешними способами) новый открытый ключ СА по истечении срока действия последнего сертификата, с использованием которого был подписан старый закрытый ключ СА. Требуют ли этого операции изменения ключа и/или сертификата, зависит от оборудования ЕЕ.

    Действия оператора СА

    Для изменения ключа СА оператор СА должен сделать следующее:

  • Создать новую пару ключей;
  • Создать сертификат, содержащий старый открытый ключ, подписанный новым закрытым ключом ("старый с новым" сертификат);
  • Создать сертификат, содержащий новый открытый ключ СА, подписанный старым закрытым ключом ("новый со старым" сертификат);
  • Создать сертификат, содержащий новый открытый ключ СА, подписанный новым закрытым ключом ("новый с новым" сертификат).
  • Опубликовать эти новые сертификаты в директории и/или другими способами (возможно, с использованием CAKeyUpdAnn -сообщения);
  • Экспортировать новый открытый ключ СА так, чтобы конечные участники могли получить его, используя "внешний" механизм (если нужно).
    •

    Старый закрытый ключ СА более не требуется. Тем не менее старый открытый ключ еще некоторое время используется. Старый открытый ключ не будет требоваться, когда все конечные участники данного СА безопасно получат новый открытый ключ СА.

    Сертификат "старый с новым" должен иметь период действительности, начинающийся с момента создания новой пары ключей и кончающейся временем, когда все конечные участники данного СА безопасно получат новый открытый ключ СА (самое позднее – это дата истечения срока действия старого открытого ключа).

    Сертификат "новый с новым" должен иметь период действительности, начинающийся со времени создания новой пары ключей и заканчивающийся временем следующего изменения СА своей пары ключей.

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

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

    Выпуск нового сертификата СА
    Репозиторий содержит новый и старый открытые ключи Репозиторий содержит только старый открытый ключ (например, задержка опубликования)
    PSE содержит новый открытый ключ PSE содержит старый открытый ключ PSE содержит новый открытый ключ PSE содержит старый открытый ключ
    Сертификат подписавшего защищен с использованием нового открытого ключа

    Случай 1:

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

    Случай 3:

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

    Случай 5:

    Хотя оператор СА не изменил директорию, проверяющий может проверить сертификат непосредственно – аналогично случаю 1

    Случай 7:

    В этом случае оператор СА не изменил директорию, и проверка не проходит
    Сертификат подписавшего защищен с использованием старого открытого ключа

    Случай 2:

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

    Случай 4:

    В этом случае проверяющий может непосредственно проверить сертификат без использования репозитория

    Случай 6:

    Проверяющий думает, что это ситуация случая 2 и хочет получить доступ к директории; однако проверка не проходит

    Случай 8:

    Хотя оператор СА не изменил директорию, проверяющий может проверить сертификат непосредственно – случай аналогичен случаю 4

    Проверка в случаях 1, 4, 5 и 8

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

    Заметим, что случай 8 может возникнуть в промежуток времени, когда оператор СА создал новую пару ключей и сохранил в директории измененные атрибуты. Случай 5 может иметь место, если оператор СА выпустил как сертификат подписывающего, так и сертификат проверяющего в течение данного интервала (оператор СА должен избегать такой ситуации, т.к. это приводит к невозможности проверки, как описано выше).

    Проверка в случае 2

    В случае 2 проверяющий должен получить доступ к старому открытому ключу СА. Проверяющий делает следующее:

  • Смотрит атрибут caCertificate в директории и получает OldWithNew- сертификат (определяемый на основе периода действительности);
  • Проверяет, все ли в порядке, используя новый ключ СА (который он имеет локально);
  • Если все нормально, проверяет сертификат подписавшего, используя старый открытый ключ СА.
    •

    Случай 2 встречается, когда оператор СА выпустил сертификат подписывающего, затем изменил ключ и выпустил сертификат проверяющего; таким образом, это вполне типичный случай.

    Проверка в случае 3

    В случае 3 проверяющий должен получить доступ к новому открытому ключу СА. Проверяющий делает следующее:

  • Смотрит атрибут саCertificate в директории и получает NewWithOld- сертификат (определяемый на основе периода действительности);
  • Проверяет, корректен ли он, используя старый открытый ключ СА (который хранится локально);
  • В случае корректности проверяет сертификат подписавшего, используя новый открытый ключ СА.
    •

    Случай 3 имеет место, когда оператор СА выпускает сертификат проверяющего, затем изменяет ключ и выпускает сертификат подписавшего; таким образом, это вполне типичный случай.

    Неудачная проверка в случае 6

    В данном случае СА выпускает PSE проверяющего, содержащий новый ключ, без изменения атрибутов директории. Это означает, что проверяющий не может получить достоверную версию старого ключа СА, поэтому проверка не проходит.

    Заметим, что невозможность проверки является ошибкой оператора СА.

    Неудачная проверка в случае 7

    В данном случае СА выпускает сертификат подписывающего, защищенный новым ключом, без изменения атрибутов директории. Это означает, что проверяющий не имеет способов получить достоверную версию нового ключа СА, поэтому проверка не проходит.

    Заметим, что невозможность проверки также является ошибкой оператора.

    Отмена – изменение ключа СА

    Как показано выше, проверка сертификата становится более сложной, так как допускается изменение ключа СА. Это также верно для проверок отмены, поскольку СА может подписать CRL, используя более новый закрытый ключ, чем тот, который применялся для пользовательского PSE.

    Анализ возможных альтернатив аналогичен проверке сертификата.

    Кросс-сертификация

    Запрашивающий СА является СА, который станет субъектом кросс-сертификата ; отвечающий СА станет выпускающим (issuer) кросс-сертификата.

    Запрашивающий СА должен быть "up and running" до начала выполнения операции кросс-сертификации.

    Односторонняя схема запроса-ответа

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

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

    Кросс-сертификация инициируется одним СА, который называется отвечающим. Администратор отвечающего СА определяет СА, который он хочет кросс-сертифицировать, и оборудование отвечающего СА создает авторизационный код. Администратор отвечающего СА передает данный авторизационный код внешними способами администратору запрашивающего СА. Администратор запрашивающего СА вводит авторизационный код отвечающего СА, чтобы инициировать on-line обмен.

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

    Запрашивающий СА инициирует обмен созданием случайного числа (случайное число запрашивающего). Затем запрашивающий СА посылает отвечающему СА сообщение запроса кросс-сертификата ( ccr ). Поля в данном сообщении защищены от модификации с помощью МАС, основанного на авторизационном коде.

    При получении ccr сообщения отвечающий СА проверяет версию протокола, сохраняет случайное число запрашивающего, создает свое случайное число (случайное число отвечающего) и проверяет МАС. Затем он создает (и, если требуется, архивирует) новый сертификат запрашивающего, который содержит открытый ключ запрашивающего СА и подписан закрытым ключом подписывания отвечающего СА. Отвечающий СА посылает сообщение ответа кросс-сертификата ( сср ). Поля в данном сообщении защищены от модификации с помощью МАС, основанного на авторизационном коде.

    При получении срр сообщения запрашивающий СА должен убедиться, что его собственное системное время позднее системного времени отвечающего СА, проверяет полученные случайные числа и действительность МАС. Запрашивающий СА отвечает PKIConfirm -сообщением. Поля в данном сообщении защищены от модификации с использованием МАС, основанного на авторизационном коде. Запрашивающий СА записывает запрошенный сертификат в репозиторий.

    При получении PKIConfirm -сообщения отвечающий СА проверяет случайные числа и действительность МАС.

    Замечания:

  • Ccr сообщение должно содержать "завершенный" запрос сертификата, что означает, что все поля (включая расширения BasicConstraints ) должны быть указаны запрашивающим СА.
  • Срр сообщение должно содержать сертификат проверки отвечающего СА – если он присутствует, то запрашивающий СА должен затем проверить данный сертификат (например, с помощью внешнего механизма).
    •

    Запрос сертификата

    Инициализированный участник может в любое время запросить сертификат (как часть процедуры изменения для любой другой цели). Данный запрос будет сделан с использованием сообщения запроса сертификата ( cr ). Если конечный участник уже имеет пару ключей подписывания (с соответствующим сертификатом проверки), то данное cr сообщение обычно бывает защищено подписью участника. СА возвращает новый сертификат (если запрос успешен) в CertRepMessage.

    Изменение ключа

    Когда период действительности пары ключей истекает, соответствующий конечный участник может запросить изменение ключа – это означает, что он может сделать запрос на создание СА нового сертификата для новой пары ключей. Запрос может быть сделан с использованием сообщения запроса изменения ключа ( kur ). Если конечный участник уже имеет пару ключей подписывания (с соответствующим сертификатом проверки), то данное сообщение обычно бывает защищено цифровой подписью участника. СА возвращает новый сертификат (если запрос успешен) в сообщении ответа изменения ключа ( kup ), которое синтаксически идентично CertRepMessage.

    Структуры данных

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

    Полное сообщение PKI

    Все сообщения, используемые для управления PKI, имеют следующую структуру:

    PKIMessage ::= SEQUENCE {
  header         PKIHeader,
  body           PKIBody,
  protection [0] PKIProtection OPTIONAL,
  extraCerts [1] SEQUENCE SIZE (1..MAX) OF
                 Certificate OPTIONAL
}

    PKIHeader содержит информацию, которая является общей для многих сообщений PKI.

    PKIBody содержит информацию, специфичную для сообщения.

    PKIProtection, если используется, содержит биты, которые защищают сообщение PKI.

    Поле extraCerts может содержать сертификаты, которые могут использоваться получателем. Например, оно может применяться СА или RA для предоставления конечному участнику сертификатов, которые он должен проверить с использованием собственного нового сертификата (если, например, СА, который выпустил сертификат конечного участника, не является для него корневым СА). Заметим, что данное поле не обязательно должно содержать сертификационный путь – получатель может отсортировать, выбрать или каким-то другим образом обработать дополнительные сертификаты, чтобы иметь возможность использовать их.

    Заголовок сообщения PKI

    Все PKI-сообщения требуют определенной информации для возможности адресации и идентификации транзакций. Некоторая необходимая информация содержится в заголовке транспортного уровня; однако если PKI-сообщение защищено, то данная информация защищена тоже (например, безопасность транспортного уровня может не предполагаться).

    Для данной информации используется следующая структура данных:

    PKIHeader ::= SEQUENCE {
  pvno   INTEGER   { ietf-version2 (1) },
  sender GeneralName,  
  --  идентификация отправителя

  recipient   GeneralName,  
  --  идентификация ожидаемого получателя

  messageTime  [0] GeneralizedTime OPTIONAL,
  --  время создания данного сообщения 
  --  (используется, если отправитель 
  --  считает, что транспорт должен быть 
  --  "соответствующим", например, что для 
  --  получателя важно время)

  protectionAlg [1] AlgorithmIdentifier 
                    OPTIONAL,
  --  алгоритм, используемый для вычисления
  --  защищенных битов 

  senderKID    [2]  KeyIdentifier OPTIONAL,
  recipKID     [3]  KeyIdentifier OPTIONAL, 
  --  идентифицирует конкретные ключи, 
  --  используемые для защиты 

  transactionID [4] OCTET STRING OPTIONAL,
  --  идентифицирует транзакцию; должно быть
  --  одним и тем же соответственно в 
  --  сообщениях запроса, ответа и 
  --  подтверждения

  senderNonce   [5] OCTET STRING  OPTIONAL,
  recipNonce    [6] OCTET STRING  OPTIONAL, 
  --  nonces, используемые для защиты от 
  --  replay-атак, senderNonce вставляется
  --  создателем данного сообщения; 
  --  recipNonce является nonce, предвари-
  --  тельно вставленным в соответствующее
  --  сообщение ожидаемым получателем 
  --  данного сообщения 

  freeText    [7] PKIFreeText  OPTIONAL, 
  --  может быть использовано для указания 
  --  контекстно-зависимых инструкций

  generalInfo [8] SEQUENCE SIZE (1..MAX) OF
                 InfoTypeAndValue  OPTIONAL 
  --  может быть использовано для указания 
  --  контекстно-зависимой информации
}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF 
                UTF8String
  --  текст представлен как UTF-8 String 
  --  (замечание: каждый UTF8String должен 
  --  включать RFC 1766 language tag для
  --  указания языка, на котором 
  --  представлен текст)

    Поле pvno для данной версии спецификации фиксировано.

    Поле sender содержит имя отправителя PKIMessage.

    Данное имя (в сочетании с senderKID, если оно используется) должно применяться для проверки защиты сообщения. Если об отправителе ничего не известно (например, в сообщении начальной регистрации, когда конечный участник может не знать собственный DN, e-mail, IP адрес и т.д.), то поле sender должно содержать значение NULL ; это означает, что последовательность RDN имеет нулевую длину. В таком случае поле senderKID должно содержать идентификатор (например, номер), указывающий получателю на информацию о соответствующем разделяемом секрете, который используется для проверки сообщения.

    Поле recipient содержит имя получателя PKIMessage. Данное имя (в сочетании с recipKID, если он используется) должно применяться для проверки защиты сообщения.

    Поле protectionAlg указывает алгоритм, используемый для защиты сообщения. Если биты защиты не применяются (заметим, что PKIProtection является OPTIONAL ), то данное поле должно быть опущено; если биты защиты применяются, то данное поле также должно использоваться.

    SenderKID и recipKID используются для указания того, какие ключи были задействованы для защиты сообщения ( recipKID обычно требуется только в том случае, если для защиты сообщения используются ключи Диффи-Хеллмана).

    Поле transactionID в заголовке сообщения может использоваться для того, чтобы допускать корреляцию с предыдущим запросом. Например, в случае с RA может существовать много отложенных на данный момент запросов.

    Поля senderNonce и recipNonce защищают PKIMessage от replay-атак.

    В поле messageTime указывается время создания сообщения. Это помогает конечным участникам корректировать свое локальное время в соответствии с временем центральной системы.

    Поле freeText может использоваться для передачи получателю читаемого сообщения (на некотором языке). Первый язык используется для указания требуемого в ответе языка.

    Поле generalInfo может применяться для передачи получателю дополнительных данных для машинной обработки.

    Тело сообщения PKI

    PKIBody ::= CHOICE {   
  --  элементы, специфичные для конкретного сообщения
    ir [0] CertReqMessages,             --  Initialization Request
    ip [1] CertRepMessage,              --  Initialization Response
    cr [2] CertReqMessages,             --  Certification Request
    cp [3] CertRepMessage,              --  Certification Response
    p10cr  [4]  CertificationRequest,   --  PKCS #10 
                                        --  Certification Request
    popdecc [5] POPODecKeyChallContent, --  pop Challenge
    popdecr [6] POPODecKeyRespContent,  --  pop Response
    kur [7]  CertReqMessages,           --  Key Update Request
    kup [8]  CertRepMessage,            --  Key Update Response
    krr [9]  CertReqMessages,           --  Key Recovery Request
    krp [10]  KeyRecRepContent,         --  Key Recovery Response
    rr  [11]  RevReqContent,            --  Revocation Request
    rp  [12]  RevRepContent,            --  Revocation Response
    ccr [13]  CertReqMessages,          --  Cross-Cert. Request
    ccp [14]  CertRepMessage,           --  Cross-Cert. Response
    ckuann [15]  CAKeyUpdAnnContent,    --  CA Key Update Ann.
    cann   [16]  CertAnnContent,        --  Certificate Ann.
    rann   [17]  RevAnnContent,         --  Revocation Ann.
    crlann [18]  CRLAnnContent,         --  CRL Announcement
    conf   [19]  PKIConfirmContent,     --  Confirmation
    nested [20]  NestedMessageContent,  --  Nested Message
    genm   [21]  GenMsgContent,         --  General Message
    genp   [22]  GenRepContent,         --  General Response
    error  [23]  ErrorMsgContent        --  Error Message
}

    Конкретные типы будут описаны ниже.

    Синтаксис CertReqMessage

    Сообщение запроса сертификата состоит из запроса сертификата, необязательного поля доказательства обладания и необязательного поля регистрационной информации.

    CertReqMessages ::= SEQUENCE SIZE
  (1..MAX) OF CertReqMsg
CertReqMsg ::= SEQUENCE {
  certReq   CertRequest,
  pop       ProofOfPossession  OPTIONAL,
  -- содержание зависит от типа ключа 
  regInfo   SEQUENCE SIZE(1..MAX) of 
      AttributeTypeAndValue OPTIONAL }

    Поле доказательства обладания используется для демонстрации того, что участник, указанный в сертификате, действительно знает соответствующий закрытый ключ. Это поле может быть вычислено над содержимым поля certReq и может варьироваться в зависимости от типов алгоритма открытого ключа и режима выполнения.

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

    Информация, непосредственно относящаяся к содержимому сертификата, должна быть включена в содержимое certReq. Однако включение RAs дополнительного содержимого в certReq может привести к тому, что поле POP станет недействительным. Таким образом, данные, включаемые в содержимое сертификата, могут передаваться в regInfo.

    Защита сообщения PKI

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

    При применении защиты используется следующая структура:

    PKIProtection ::= BIT STRING

    Входом для вычисления PKIProtection является DER-представление следующей структуры данных:

    ProtectedPart ::=   SEQUENCE {
  header  PKIHeader,
  body    PKIBody
}

    Могут быть ситуации, когда PKIProtection BIT STRING сознательно не используется для защиты сообщения (т.е. это OPTIONAL поле опущено), т.к. применяется другая, внешняя по отношению к PKI, защита. Это явно допускается. Примерами такой внешней защиты являются PKCS #7 и Security Multiparts (RFC 1847) инкапсуляция PKIMessage (или просто PKIBody, если безопасность информации PKIHeader обеспечивается посредством внешних механизмов). Следует заметить, однако, что многие такие внешние механизмы требуют, чтобы конечный участник уже имел сертификат открытого ключа и/или DN и/или другую аналогичную относящуюся к инфраструктуре информацию. Таким образом, это может не соответствовать начальной регистрации, восстановлению ключа или другому процессу, характеризующемуся "начальной загрузкой". Для таких случаев может быть необходимо, чтобы использовались PKIProtection -параметры. В будущем, если внешние механизмы будут модифицированы таким образом, чтобы соответствовать сценариям начальной загрузки, использование PKIProtection станет более редким или вовсе необязательным.

    В зависимости от условий биты PKIProtection могут содержать МАС или подпись. Возможны следующие случаи:

  • Разделяемая секретная информация

    В данном случае отправитель и получатель разделяют секретную информацию (установленную внешними способами или полученную из предыдущих операций PKI). PKIProtection будет содержать значение МАС и protectionAlg будет следующим:

    PasswordBasedMac ::=
  OBJECT IDENTIFIER 
    --  {1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
  salt  OCTET STRING,
  owf   AlgorithmIdentifier,
    --  AlgId для односторонней
    --  функции OWF 
    --  (рекомендуется SHA-1)
  iterationCount     INTEGER,
    --  количество применений OWF 
  mac     AlgorithmIdentifier
    --  AlgId MAC (например,
    --  DES-MAC, Triple-DES-MAC, 
    --  или HMAC)
}

    В указанном выше protectionAlg значение salt присоединяется к разделяемому секрету. Затем OWF применяется iterationCount раз, где секрет с добавлением salt является входом в первую итерацию и вход каждой итерации является выходом предыдущей. Выход последней итерации (называемый BASEKEY ) используется для создания симметричного ключа. Если алгоритм МАС требует K -битного ключа и K < H, то используются младшие K бит BASEKEY. Если K > H, то весь BASEKEY используется для младших Н битов ключа, OWF ("2" || BASEKEY ) применяется для следующих Н битов ключа и т.д.

  • Пара ключей DH

    Когда отправитель и получатель имеют сертификаты Диффи-Хеллмана с совместимыми параметрами, для защиты сообщения конечный участник должен создать симметричный ключ, основываясь на значении своего закрытого ключа DH и открытом ключе DH получателя PKI-сообщения.

    PKIProtection будет содержать значение МАС с ключом, полученным из симметричного ключа и protectionAlg следующим образом:

    DHBasedMac ::= OBJECT IDENTIFIER 
    --  {1 2 840 113533 7 66 30}
DHBMParameter ::= SEQUENCE {
  owf     AlgorithmIdentifier,
    --   AlgId для односторонней
    --   функции (OWF) 
    --   (рекомендуется SHA-1)
  mac       AlgorithmIdentifier
    --   the MAC AlgId (например,
    --   DES-MAC, 
    --   Triple-DES-MAC или НМАС)
}

    protectionAlg OWF применяется к результату вычислений DH. Выход OWF (называемый BASEKEY ) используется для формирования симметричного ключа. Если алгоритм МАС требует K -битного ключа и K < H, то используются K младших битов BASEKEY. Если K > H, то используется весь BASEKEY для младших Н битов ключа, OWF ("1" || BASEKEY) применяется для следующих младших Н битов ключа и т.д.

  • Подпись

    Если отправитель имеет пару ключей подписывания, он может просто подписать PKI-сообщение. PKIProtection будет содержать значение подписи, protectionAlg будет определяться значением AlgorithnIdentifier.

  • Многократная защита

    В случае, когда конечный участник отправляет защищенное PKI-сообщение RA, RA может перенаправить данное сообщение СА, присоединив свою собственную защиту (которая может быть МАС или цифровой подписью, в зависимости от информации и сертификатов, разделяемых RA и СА). Это предполагает вложение всего сообщения, посылаемого конечным участником, в новое PKI-сообщение. Используется следующая структура.

    NestedMessageContent ::= PKIMessage
    •

    Общие структуры данных

    Перед тем как указывать типы, которые могут быть размещены в PKIBody, мы определим некоторые структуры данных, которые могут применяться.

    Содержимое запрашиваемого сертификата

    Различные управляющие сообщения PKI требуют, чтобы инициатор сообщения указал некоторые поля, которые должны присутствовать в сертификате. Структура CertTemplate позволяет конечному участнику или RA указать как можно больше того, что должен содержать сертификат. CertTemplate аналогична Certificate, но все поля являются необязательными.

    Заметим, что даже если инициатор полностью указал требуемое содержимое сертификата, СА имеет право модифицировать поля в сертификате, который он реально издает. Если модифицированный сертификат для запрашивающего неприемлем, можно задержать Confirmation -сообщение или послать Error -сообщение (с PKIStatus "rejection" ).

    Зашифрованные значения

    Когда в PKI сообщениях присутствуют зашифрованные значения (это могут быть либо закрытые ключи, либо сертификаты), используется структура данных EncryptedValue.

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

    Если получатель PKIMessage уже имеет закрытый ключ, используемый для дешифрования, поле encSymmKey может содержать ключ сессии, зашифрованный с использованием открытого ключа получателя.

    Коды статуса и информация о неудаче для PKI-сообщений

    Все сообщения ответа включают определенную информацию о статусе. Определены следующие значения:

    PKIStatus ::= INTEGER {
  Granted          (0),
      -- получено то, что запрашивалось
  grantedWithMods  (1),
      -- получено что-то подобное, что запрашивалось; 
	  -- запрашивающий несет ответственность за 
      -- установленные отличия 
  rejection        (2),
      -- не получено то, что запрашивалось,
	  -- более подробная информация в сообщении 
  waiting          (3),
      -- запрос не обработан,
      -- следует запросить позднее 
  revocationWarning  (4),
      -- данное сообщение содержит предупреждение, 
	  -- что скоро будет отмена 
  revocationNotification  (5),
      -- уведомление, что произошла отмена
  keyUpdateWarning   (6)
      -- изменение уже выполнено для oldCertId, 
      -- указанного в сообщении запроса изменения ключа
}

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

    PKIFailureInfo ::= BIT STRING {
    -- причин неудачи может быть много
    -- при необходимости в будущем могут 
	-- быть добавлены другие коды причин.
  badAlg  (0),
    -- нераспознанный или неподдерживаемый
    -- Идентификатор Алгоритма 
  badMessageCheck  (1),
    -- сбой в процессе проверки целостности
	-- (например, подпись не верифицирована)
  badRequest       (2),
    -- транзакция не разрешена или не поддерживается 
  badTime          (3),
    -- messageTime недостаточно точно
    -- соответствует системному времени,
	-- как определено локальной политикой 
  badCertId        (4),
    -- сертификат не может быть найден в
	-- соответствии с предоставленным критерием 
  badDataFormat    (5),
    -- переданные данные имеют
    -- неправильный формат 
  wrongAuthority   (6),
    -- уполномоченный орган, указанный 
	-- в запросе, отличается от того, 
	-- который определен в токене ответа
  incorrectData    (7),
    -- данные из запроса являются некорректными 
    -- (используется для сервисов нотариуса)
  missingTimeStamp (8),
    -- когда timestamp опущена, но
    -- должна присутствовать 
    -- (в соответствии с политикой) 
  badPOP           (9)
    -- упал РОР 
}
PKIStatusInfo ::= SEQUENCE {
  status PKIStatus,
  statusString PKIFreeText OPTIONAL,
  failInfo PKIFailureInfo OPTIONAL
}

    Идентификация сертификата

    Для идентификации конкретных сертификатов используется структура данных CertId.

    Каждый корневой СА должен иметь возможность опубликовать свой текущий открытый ключ посредством некоторых "внешних" механизмов. Хотя такие механизмы находятся вне рассматриваемой предметной области, мы определим структуры данных, которые могут ими поддерживаться.

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

    OOBCert ::= Certificate

    Поля в данном сертификате имеют следующие ограничения:

  • Сертификат должен быть самоподписанным (т.е. подпись должна проверяться с использованием поля SubjectPublicKeyInfo );
  • Поля subject и issuer должны быть идентичны;
  • Если поле subject является NULL, то оба расширения, subjectAltName и issuerAltName, должны присутствовать и иметь одно и то же значение;
  • Значения всех других расширений должны соответствовать самоподписанному сертификату (т.е. идентификаторы ключа для subject и issuer должны быть одни и те же).
    •  
    OOBCertHash ::= SEQUENCE {
  hashAlg [0] AlgorithmIdentifier
    OPTIONAL,
  certId [1] CertId OPTIONAL,
  hashVal BIT STRING
    -- hashVal вычисляется для
    -- самоподписанного 
    -- сертификата с идентификатором
    -- certID.}

    Смысл значения хэша состоит в том, чтобы любой, кто безопасно получил значение хэша (внешними способами), мог проверить самоподписанный сертификат данного СА.

    Опции архивации

    Запрашивающий может указать, что он хочет архивировать значение закрытого ключа, используя структуру PKIArchiveOptions.

    Публикуемая информация

    Запрашивающий может указать, что он хочет, чтобы PKI опубликовал сертификат, используя структуру PKIPublicationInfo.

    Структуры РОР

    Если запрос сертификата предназначен для пары ключей подписывания (т.е. запрос для верифицирующего сертификата), то доказательство обладания закрытым ключом подписывания демонстрируется с помощью структуры POPOSingingKey.

    POPOSigningKeyInput ::= SEQUENCE {
  authInfo     CHOICE {
    sender        [0] GeneralName,
    -- из PKIHeader (используется только в
	-- том случае, если аутентифицированная
    -- идентификация установлена 
    -- отправителем (например, DN из ранее
	-- выпущенного и действительного 
	-- в данный момент сертификата))
    publicKeyMAC  [1] PKMACValue
    -- используется, если в настоящий момент
	-- не существует аутентифицированного 
	-- GeneralName для отправителя; 
	-- publicKeyMAC содержит основанный на 
    -- пароле MAC (используя protectionAlg 
	-- AlgId из PKIHeader) для
    -- DER-представления publicKey
  },
  publicKey     SubjectPublicKeyInfo
    -- из CertTemplate
}

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

  • Включением закрытого ключа (шифрования) в CertRequest (в управляющей структуре PKIArchiveOptions ).
  • Тем, что СА возвращает не сертификат, а зашифрованный сертификат (например, сертификат зашифрован случайно созданным симметричным ключом и симметричный ключ зашифрован открытым ключом, для которого выпущен запрошенный сертификат) – это "непрямой" метод, описанный ранее. Конечный участник доказывает знание закрытого ключа дешифрования, посылая МАС сообщения PKIConirm, используя ключ, полученный из данного симметричного ключа. Заметим, что если более одного CertReqMsg включено в PKIMessage, то СА использует разные симметричные ключи для каждого CertReqMsg, и МАС задействует ключ, полученный из конкатенации всех этих ключей. Процедура вычисления МАС использует PasswordBasedMacAlgId, определенный выше.
  • Тем, что конечный участник обязан иметь что-то, что он указывает в протоколе вызов-ответ (используя сообщения POPODecKeyChall и POPODecKeyResp, см ниже) между CertReqMessages и CertRepMessages. Это "прямой" метод, как он определен выше. Данный метод обычно используется в окружении, в котором RA проверяет POP и затем осуществляет запрос сертификата у СА от имени конечного участника. В данном сценарии СА доверяет RA выполнять POP до того, как RA запросит сертификат для конечного участника. Полный протокол выглядит следующим образом (заметим, что req’ не обязательно должно инкапсулировать req в качестве вложенного сообщения):
    •

    Очевидно, что данный протокол является более длинным, но позволяет включать локальный RA, при этом сам сертификат реально не создается, пока не приведено доказательство обладания.

    Если запрос сертификата выполнен для пары ключей согласования ключа (Key Agreement Key – KAK), то POP может использовать любой из трех способов, описанных выше для пары ключей шифрования с учетом следующего:

  • Сертификат зашифрован с помощью симметричного ключа, полученного из закрытого KAK СА и открытого ключа, для которого выполнен запрос сертификата.
  • Вместо Challenge используется PreferredSymmAlg и симметричный ключ, полученный из закрытого KAK СА и открытого ключа, для которого выполнен запрос сертификата. В качестве альтернативы POP может использовать структуру POPOSigningKey, где поле alg есть DHBasedMAC и поле подписи есть МАС, в качестве четвертой альтернативы для демонстрации POP, если СА уже имеет D-H сертификат, который известен ЕЕ.
    •

    Сообщения вызова-ответа для доказательства обладания закрытым ключом шифрования определены следующим образом. Заметим, что обмен вызов-ответ связан с сообщением запроса сертификата (и тем самым с сообщениями ответа сертификата и подтверждением) с помощью nonces, используемых в PKIHeader, и защитой (МАС или подписыванием), примененной к PKIMessage.

    POPODecKeyChallContent ::= SEQUENCE OF Challenge
    -- один Challenge на запрос сертификата ключа 
    -- шифрования (в той же последовательности, что и 
    -- другие запросы, появляющиеся в CertReqMessages).
Challenge ::= SEQUENCE {
  owf       AlgorithmIdentifier  OPTIONAL,
    -- должен присутствовать в первом Challenge; может 
    -- быть опущен в любом следующем Challenge в 
    -- POPODecKeyChallContent (если опущен, то owf 
    -- используется в немедленно создаваемом Challenge).
  witness   OCTET STRING,
    -- результат применения односторонней функции (owf) 
    -- к случайно созданному целому A. Заметим, что для 
    -- каждого Challenge должны использоваться различные 
    -- целые.
  challenge   OCTET STRING
    -- шифрование (с использованием открытого ключа, для 
    -- которого выполнен запрос сертификата) Rand, где 
    -- Rand специфицирован как 
    --   Rand ::= SEQUENCE {
    --   int      INTEGER,
    --   – случайно созданное целое A (определено выше)
    --   sender   GeneralName
    --   – имя отправителя (как определено в PKIHeader)
    --   }
  }
POPODecKeyRespContent ::= SEQUENCE OF INTEGER
    -- один INTEGER на каждый запрос сертификата для 
    -- ключа шифрования (в порядке появления этих 
    -- запросов в CertReqMessages). Восстановленный 
    -- INTEGER A возвращается отправителю в 
    -- соответствующем Challenge.
    (рис 18.2) Полный протокол доказательства обладания закрытым ключем

    Структуры данных, используемые для каждой операции

    Запрос инициализации

    Сообщение запроса инициализации содержит в PKIBody структуру данных CertReqMessage, которая описывает запрашиваемые сертификаты. Обычно SubjectPubKeyInfo, KeyId и Validity являются шаблонными полями, которые заменяются для каждого затребованного сертификата. Считается, что данное сообщение используется для первой инициализации участника в PKI.

    Ответ инициализации

    Сообщение ответа инициализации в PKIBody структуру данных CertRepMessage, которая для каждого запрошенного сертификата имеет поле PKIStatusInfo, сертификат субъекта и, возможно, закрытый ключ (обычно зашифрованный ключом сессии, который сам зашифрован protocolEncKey ).

    Далее приводится синтаксис CertRepMessage. Заметим, что если защитой сообщения PKI является "разделяемая секретная информация", то любой сертификат, передаваемый в поле caPubs, может быть непосредственно доверенным как сертификат корневого СА инициатора.

    Запрос регистрации/сертификации

    Сообщение запроса регистрации / сертификации содержит в PKIBody структуру данных CertReqMessages, которая специфицирует запрошенные сертификаты. Считается, что данное сообщение используется для существующих в PKI участников, которые хотят получить дополнительные сертификаты.

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

    Ответ регистрации/сертификации

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

    CertRepMessage ::= SEQUENCE {
  CaPubs [1] SEQUENCE SIZE (1..MAX)
    OF Certificate OPTIONAL,
  Response  SEQUENCE OF CertResponse }
CertResponse ::= SEQUENCE {
  CertReqId  INTEGER,
    -- для установления соответствия между
	-- ответом и запросом – 1 используется,
    -- если certReqId в соответствующем 
	-- запросе не указан)
  status  PKIStatusInfo,
  certifiedKeyPair CertifiedKeyPair
    OPTIONAL,
  rspInfo OCTET STRING OPTIONAL
    -- аналогично id-regInfo-asciiPairs
    -- OCTET STRING, 
    -- определенной для regInfo
    -- в CertReqMsg 
}
CertifiedKeyPair ::= SEQUENCE {
  certOrEncCert CertOrEncCert,
  privateKey [0] EncryptedValue OPTIONAL,
  publicationInfo [1] PKIPublicationInfo
    OPTIONAL
}
CertOrEncCert ::= CHOICE {
  certificate     [0] Certificate,
  encryptedCert   [1] EncryptedValue
}

    Только одно из полей failInfo (в PKIStatusInfo ) и certificate (в CertifiedKeyPair ) может быть представлено в каждом CertResponse (в зависимости от статуса). Для некоторых значений статуса (например, waiting ) ни одно из дополнительных полей присутствовать не может.

    Сертификат может быть получен при наличии EncryptedCert и соответствующего ключа дешифрования. Это делается для того, чтобы позволить СА возвращать значение сертификата, но с тем ограничением, что только определенный получатель может получить настоящий сертификат. Преимущество данного подхода состоит в том, что СА может возвращать сертификат даже при отсутствии доказательства, что запрашивающий является конечным участником, который может использовать соответствующий закрытый ключ (заметим, что доказательство не представлено до тех пор, пока СА не получит PKIConfirm -сообщение). Таким образом, СА не будет отменять сертификат до тех пор, пока не получит неправильное доказательство обладания.

    Содержимое запроса изменения ключа

    Для запросов изменения ключа используется синтаксис CertReqMessages. Обычно SubjectPublicKeyInfo, KeyId и Validity являются шаблонными полями, которые заполняются для каждого изменяемого ключа. Считается, что данное сообщение применяется для запроса изменения существующих (не отмененных и не истекших) сертификатов.

    Содержимое ответа изменения ключа

    Для ответов об изменении ключа используется синтаксис CertRepMessage. Ответ идентичен ответу инициализации.

    Синтаксис CertRepMessage описан выше.

    Содержимое запроса восстановления ключа

    Для запросов восстановления ключа используется синтаксис, идентичный запросу инициализации CertReqMesages. Обычно SubjectPublicKeyInfo и KeyId являются шаблонными полями, которые могут применяться для указания открытого ключа подписи, для которого был запрошен сертификат.

    Содержимое ответа восстановления ключа

    Для ответов восстановления ключа используется следующий синтаксис. Для некоторых значений статуса (например, waiting ) могут присутствовать дополнительные поля.

    KeyRecRepContent ::= SEQUENCE { status
  PKIStatusInfo,
  newSigCert [0] Certificate OPTIONAL,
  caCerts [1] SEQUENCE SIZE (1..MAX) OF 
      Certificate OPTIONAL,
  keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
      CertifiedKeyPair OPTIONAL
}

    Содержимое запроса отмены

    При запросе отмены сертификата (или нескольких сертификатов) используется следующая структура данных. Имя запрашивающего присутствует в PKIHeader -структуре.

    RevReqContent ::= SEQUENCE OF RevDetails
  RevDetails ::= SEQUENCE {
  certDetails     CertTemplate,
  -- позволяет запрашивающему указать
  -- как можно больше 
  -- сведений о сертификате,
  -- для которого требуется отмена 
  -- (например, для случаев, когда
  -- serialNumber недоступен)
  revocationReason ReasonFlags OPTIONAL,
  -- причина запроса отмены 
  badSinceDate GeneralizedTime OPTIONAL,
  -- указывает максимальные знания
  -- отправителя 
  crlEntryDetails Extensions OPTIONAL
  -- запрошенные crlEntryExtensions
}

    Содержимое ответа отмены

    Ответ на предыдущее сообщение. Если отмена произведена, то данное сообщение посылается запрашивающему. Отдельное уведомление об отмене может быть послано субъекту сертификата, для которого запрошена отмена.

    RevRepContent ::= SEQUENCE {
  status SEQUENCE SIZE (1..MAX)
    OF PKIStatusInfo,
    -- в той же последовательности,
    -- как было послано в RevReqContent
  revCerts [0] SEQUENCE SIZE
    (1..MAX) OF CertId OPTIONAL,
    -- Ids, для которых запрошена отмена
    -- (тот же порядок, что и status)
  crls [1] SEQUENCE SIZE (1..MAX)
    OF CertificateList OPTIONAL
    -- результирующие CRLs (может
    -- быть более одного)
}

    Содержимое запроса кросс-сертификации

    Запросы кросс-сертификации используют тот же самый синтаксис ( CertReqMessages ), что и обычные запросы сертификации, с тем лишь ограничением, что пара ключей должна быть создана запрашивающим СА, и закрытый ключ не должен быть послан отвечающему СА.

    Содержимое ответа кросс-сертификации

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

    Содержимое оповещения об изменении ключа СА

    Когда СА изменяет собственную пару ключей, для оповещения может использоваться следующая структура данных.

    CAKeyUpdAnnContent ::= SEQUENCE {
  OldWithNew Certificate, 
    -- старый pub, подписанный новым priv
  NewWithOld Certificate, 
    -- новый pub, подписанный старым priv
  NewWithNew Certificate 
    -- новый pub, подписанный новым priv
}

    Оповещение сертификата

    Данная структура может использоваться для оповещения о существовании сертификатов.

    Считается, что данное сообщение будет использоваться в тех ситуациях (если они возникнут), когда не существует методов для опубликования сертификатов; не считается, что она будет использоваться, например, в том случае, если для опубликования сертификатов используется директория.

    CertAnnContent ::= Certificate

    Оповещение об отмене

    При выполнении СА отмены или предположении отмены может быть выпущен специальный сертификат для оповещения об этом событии.

    RevAnnContent ::= SEQUENCE {
  status PKIStatus,
  certId CertId,
  willBeRevokedAt GeneralizedTime,
  badSinceDate GeneralizedTime,
  crlDetails Extensions OPTIONAL
    -- детали extra CRL (например,
    -- crl number, reason, location, etc.)
}

    СА может использовать такое оповещение для уведомления субъекта о том, что его сертификат отменен или его предполагается отменить. Это обычно используется в тех случаях, когда запрос отмены приходит не от того субъекта, которого он касается.

    Поле willBeRevokedAt содержит время, когда новая запись будет добавлена в соответствующие CRLs.

    Оповещение о CRL

    Когда СА выпускает новый CRL (или множество CRLs), для оповещения о данном событии может использоваться следующая структура данных.

    CRLAnnContent ::= SEQUENCE
  OF CertificateList

    Содержимое подтверждения PKI

    Данная структура данных используется при трехстороннем протоколе в качестве заключительного PKIMessage. Его содержимое является одним и тем же во всех случаях – на самом деле оно не имеет содержимого, т.к. PKIHeader уже содержит всю необходимую информацию.

    PKIConfirmContent ::= NULL

    Содержимое общего сообщения PKI

    InfoTypeAndValue ::= SEQUENCE {
  infoType       OBJECT IDENTIFIER,
  infoValue       ANY DEFINED BY infoType  OPTIONAL
}
-- пример содержимого InfoTypeAndValue включает, но не 
-- ограничивается :
-- { CAProtEncCert       = {id-it 1}, Certificate       }
-- { SignKeyPairTypes     = {id-it 2}, SEQUENCE OF 
-- AlgorithmIdentifier }
-- { EncKeyPairTypes     = {id-it 3}, SEQUENCE OF 
-- AlgorithmIdentifier }
-- { PreferredSymmAlg   = {id-it 4}, AlgorithmIdentifier  }
-- { CAKeyUpdateInfo     = {id-it 5}, CAKeyUpdAnnContent  }
-- { CurrentCRL         = {id-it 6}, CertificateList   }
-- где {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
-- данная конструкция может также использоваться для 
-- определения новых сообщений запроса и ответа PKIX 
-- Certificate Management Protocol, или для сообщений, 
-- используемых для общих целей, которые могут 
-- понадобиться в будущем в конкретных окружениях.
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
  -- Может быть послано EE, RА или СA (в зависимости от 
  -- содержимого сообщения). Параметр OPTIONAL infoValue 
  -- для InfoTypeAndValue для примеров, приведенных 
  -- ниже, обычно опущен. Получатель может игнорировать 
  -- все, что содержит OBJ.IDs, которые не распознаны. 
  -- Если посылается от EE к CA, то пустое множество 
  -- указывает, что СA может послать всю/любую 
  -- интересующую информацию.

    Содержимое общего ответа PKI

    GenRepContent ::= SEQUENCE OF
  InfoTypeAndValue
  -- Получатель может игнорировать
  -- любое содержимое 
  -- OBJ.IDs, которое он не распознает.

    Содержимое сообщения об ошибках

    ErrorMsgContent ::= SEQUENCE {
  pKIStatusInfo PKIStatusInfo,
  errorCode INTEGER OPTIONAL,
  -- конкретные для реализации
  -- коды ошибок 
  errorDetails PKIFreeText OPTIONAL
  -- конкретные для реализации
  -- детали ошибок }

    Синтаксис CertRequest

    Синтаксис CertRequest состоит из запроса идентификатора, шаблона содержимого сертификата и дополнительной последовательности управляющей информации.

    CertRequest ::= SEQUENCE {
  certReqId INTEGER,  
  -- ID для обеспечения соответствия
  -- между запросом и ответом
  certTemplate CertTemplate,  
  -- поля из сертификата, который
  -- должен быть выпущен 
  controls Controls OPTIONAL  
  -- атрибуты, используемые при
  -- выпуске сертификата 
}
CertTemplate ::= SEQUENCE {
  version [0] Version OPTIONAL,
  serialNumber [1] INTEGER OPTIONAL,
  signingAlg   [2] AlgorithmIdentifier OPTIONAL,
  issuer   [3] Name OPTIONAL,
  validity [4] OptionalValidity OPTIONAL,
  subject [5] Name OPTIONAL,
  publicKey [6] SubjectPublicKeyInfo OPTIONAL,
  issuerUID [7] UniqueIdentifier OPTIONAL,
  subjectUID [8] UniqueIdentifier OPTIONAL,
  extensions [9] Extensions OPTIONAL 
}
OptionalValidity ::= SEQUENCE {
  notBefore [0] Time OPTIONAL,
  notAfter [1] Time OPTIONAL 
} 
  -- по крайней мере, одно должно быть
  -- представлено 
Time ::= CHOICE {
  utcTime UTCTime,
  generalTime GeneralizedTime 
}

    Синтаксис доказательства обладания

    ProofOfPossession ::= CHOICE {
  raVerified      [0] NULL,
    -- используется, если RA уже убедился, что 
    -- запрашивающий обладает закрытым ключом   
  signature       [1] POPOSigningKey,
  keyEncipherment [2] POPOPrivKey,
  keyAgreement    [3] POPOPrivKey 
}    
POPOSigningKey ::= SEQUENCE {
  poposkInput     [0] POPOSigningKeyInput OPTIONAL,
  algorithmIdentifier AlgorithmIdentifier,
  signature           BIT STRING 
    -- Подпись (используя "algorithmIdentifier") является 
    -- значением в DER-представлении poposkInput. 
    -- Замечание: если CertReqMsg certReq CertTemplate 
    -- содержит значения subject и publicKey, то poposkInput 
    -- должно быть опущено и подпись должна быть вычислена 
    -- для DER-представления значения CertReqMsg certReq. 
    -- Если CertReqMsg certReq CertTemplate не содержит 
    -- значения открытого ключа и субъекта, то poposkInput 
    -- должно присутствовать и должно быть подписано. Данная 
    -- стратегия гарантирует, что открытый ключ не 
    -- присутствует в полях poposkInput и CertReqMsg certReq 
    -- CertTemplate.
}
POPOSigningKeyInput ::= SEQUENCE {
  authInfo CHOICE {
  sender        [0] GeneralName,
    -- используется только если установлена 
    -- аутентифицированная идентификация для отправителя 
    -- (т.е. DN из ранее выпущенного или действительного 
    -- в настоящий момент сертификата)
  publicKeyMAC  PKMACValue },
    -- используется, если в настоящий момент нет 
    -- аутентифицированного GeneralName отправителя; 
    -- publicKeyMAC содержит MAC, основанный на пароле, 
    -- в DER-представлении значения publicKey
  publicKey     SubjectPublicKeyInfo  -- из CertTemplate
}
PKMACValue ::= SEQUENCE {
  algId  AlgorithmIdentifier,
    -- значение алгоритма должно быть PasswordBasedMac 
    -- {1 2 840 113533 7 66 13}, значение параметра есть 
    -- значение PBMParameter BIT STRING
}
POPOPrivKey ::= CHOICE {
  thisMessage       [0] BIT STRING,
    -- доказательство, представленное в данном сообщении 
    -- (содержит сам закрытый ключ, зашифрованный для СА)
  subsequentMessage [1] SubsequentMessage,
    -- доказательство приведено в следующем сообщении
dhMAC               [2] BIT STRING 
    -- для keyAgreement (только) доказательство 
    -- приведено в данном сообщении, которое содержит 
    -- MAC (для значения DER-представления параметра 
    -- certReq в CertReqMsg, которое должно включать и 
    -- subject, и publicKey), основываясь на ключе, 
    -- полученном из закрытого ключа DH конечного 
    -- участника и открытого ключа DH СА.
}
SubsequentMessage ::= INTEGER {
  encrCert (0),
    -- запросы, при которых результирующий сертификат 
    -- зашифрован для конечного участника (при этом POP 
    -- будет выполнен в подтверждающем сообщении)
  challengeResp (1) 
    -- запросы, при которых CA/RA обязан выполнить обмен 
    -- вызов-ответ с конечным участником, чтобы доказать, 
    -- что ему известен закрытый ключ
}

    Считается, что протоколы должны включать подтверждающее сообщение для сообщения вызов-ответ.

    Использование МАС, основанного на пароле

    Следующий алгоритм должен применяться при использовании publicKeyMAC в POPOSigningKeyInput для доказательства аутентичности запроса.

    PBMParameter ::= SEQUENCE {
  salt OCTET STRING,
  owf AlgorithmIdentifier,
    -- AlgId для One-Way Function
    -- (SHA-1 рекомендуется)
  iterationCount INTEGER,
    -- сколько раз применяется OWF 
  mac AlgorithmIdentifier
    -- the MAC AlgId (например,
    -- DES-MAC, Triple-DES-MAC,
    -- или HMAC) }

    Процесс, использующий PBMParameter вычисления publicKeyMAC и тем самым аутентифицирующий исходный запрос сертификата открытого ключа, состоит из двух стадий. Первая стадия использует разделяемую секретную информацию для создания ключа МАС. На второй стадии вычисляются MACs открытых ключей, с помощью данного ключа МАС для создания аутентифицирующего значения.

    Инициализация первой стадии алгоритма предполагает существование разделяемого секрета, полученного надежным способом CA/RA и конечным участником. Значение salt присоединяется к разделяемому секрету, и односторонняя функция ( owf ) применяется iterationCount раз, где секрет и salt являются входом в первую итерацию, и для каждой следующей итерации вход есть множество выходов предыдущей итерации, включая ключ K.

    На второй стадии K и открытый ключ являются входами в НМАС, в результате чего создается значение для publicKeyMAC следующим образом:

    publicKeyMAC = Hash( K XOR opad,
  Hash( K XOR ipad, public key) )

    где ipad и opad определены в RFC 2104.

    Управление публикуемой информацией

    Управление pkiPublicationInfo необходимо подписчикам для управления опубликованием СА сертификата. Определен следующий синтаксис:

    PKIPublicationInfo ::= SEQUENCE {
  action INTEGER {
    dontPublish (0),
    pleasePublish 1) },
  pubInfos SEQUENCE SIZE (1..MAX)
    OF SinglePubInfo OPTIONAL }
  -- pubInfos не должно присутствовать,
  -- если действие есть "dontPublish" 
  -- (если действие есть 
  -- "pleasePublish" и pubInfos опущено,
  -- предполагается "dontCare")
SinglePubInfo ::= SEQUENCE {
  pubMethod    INTEGER {
    dontCare       (0),
    x500           (1),
    web           (2),
    ldap           (3) },
  pubLocation   GeneralName OPTIONAL }

    Если выбрана опция dontPublish, запрашивающий указывает, что PKI не должно публиковать сертификат (это может означать, что запрашивающий сам опубликует сертификат).

    Если выбран метод dontCare или если управление PKIPublicationInfo в запросе опущено, запрашивающий указывает, что PKI может опубликовать сертификат, используя любой выбранный им способ.

    Если запрашивающему нужно, чтобы сертификат появился, по крайней мере, в некоторых местах и при этом он хочет допустить, чтобы СА сделал сертификат доступным для других репозиториев, следует установить два значения SinglePubInfo для pubInfos: одно со значением x500, web или ldap, и другое – с dontCare.

    Поле pubLocation, если имеется, указывает, где запрашивающий хочет разместить сертификат (заметим, что CHOICE в GeneralName включает, например, URL и IP адрес).

    Управление опциями архивирования

    Управление pkiArchiveOptions дает подписчикам возможность указать информацию, необходимую для установления архивирования закрытого ключа, соответствующего открытому ключу из запроса сертификата. Это определяется следующим синтаксисом:

    PKIArchiveOptions ::= CHOICE {
  encryptedPrivKey [0] EncryptedKey,
    -- реальное значение закрытого ключа

  keyGenParameters [1] KeyGenParameters,
    -- параметры, которые допускают
    -- перегенерацию закрытого ключа 

  archiveRemGenPrivKey [2] BOOLEAN 
    -- установлено в TRUE, если отправитель
    -- хочет, чтобы получатель архивировал
    -- закрытый ключ или пару ключей,
    -- которые создал получатель в ответ
    -- на данный запрос; 
    -- установлено в FALSE, если архивация 
    -- не предполагается.
}
EncryptedKey ::= CHOICE {
  encryptedValue EncryptedValue,
  envelopedData [0] EnvelopedData 
    -- зашифрованный закрытый ключ должен
    -- быть размещен в 
    -- envelopedData encryptedContentInfo
    -- encryptedContent 
    -- OCTET STRING.
}
EncryptedValue ::= SEQUENCE {
  intendedAlg [0] AlgorithmIdentifier OPTIONAL,
    -- предполагаемый алгоритм, для
    -- которого будет 
    -- использоваться значение 

  symmAlg [1] AlgorithmIdentifier OPTIONAL,
    -- симметричный алгоритм, используемый
    -- для шифрования значения 

  encSymmKey [2] BIT STRING  OPTIONAL,
    -- (зашифрованный) симметричный ключ,
    -- используемый для шифрования значения

  keyAlg [3] AlgorithmIdentifier OPTIONAL,
    -- алгоритм, используемый для
    -- шифрования симметричного ключа 

  valueHint [4] OCTET STRING OPTIONAL,
    -- краткое описание или идентификатор
    -- содержимого encValue (может иметь 
    -- значение только для посылающего и
    -- использоваться только если 
    -- EncryptedValue должно перепроверяться
    -- посылающим в будущем)

  encValue BIT STRING 
}
KeyGenParameters ::= OCTET STRING

    Альтернативой посылки ключа является посылка информации о том, как заново создать ключ, используя выбор KeyGenParameters (например, для многих реализаций RSA можно послать первое случайное простое число).

    Схема LDAPv2 для инфраструктуры открытого ключа Х.509

    Рассматриваемая схема является минимальной схемой для поддержки PKI для протокола LDAPv2. Определим только компоненты, относящиеся к PKI. LDAP-серверы, функционирующие как репозитории PKI, должны поддерживать вспомогательные классы объектов и соответствующим образом интегрировать спецификацию данной схемы с общей схемой и другими схемами, специфичными для других приложений.

    LDAPv2 является одним из протоколов для доступа к репозиторию PKI. Также определены другие протоколы, такие как HTTP. Если LDAP-сервер, доступный по LDAPv2, используется в качестве репозитория, минимальное требование состоит в том, что репозиторий должен поддерживать дополнительные записи каталога для сертификатов Х.509.

    Определим атрибуты и классы объектов, используемые LDAP-серверами, функционирующими в качестве репозиториев PKI, которые должны понимать клиенты LDAP, взаимодействующие с этими репозиториями для запроса, добавления, модификации и удаления информации PKI.

    Объекты репозитория PKI

    Объектами, представленными в репозитории, являются:

  • Конечные участники.
  • СА.
    •

    Следующий вспомогательный класс объекта может использоваться для представления субъектов сертификата:

    pkiUser OBJECT-CLASS ::= {
  SUBCLASS OF { top}
  KIND auxiliary
  MAY CONTAIN {userCertificate}
  ID joint-iso-ccitt(2) ds(5)
    objectClass(6) pkiUser(21)
}
userCertificate ATTRIBUTE ::=  {
  WITH SYNTAX Certificate
  EQUALITY MATCHING RULE
    certificateExactMatch
  ID  joint-iso-ccitt(2) ds(5)
    attributeType(4) 
    userCertificate(36) 
}

    Конечный участник может получить один или более сертификатов от одного или более СAs. Атрибут userCertificate должен использоваться для представления этих сертификатов в записи каталога , относящейся к данному пользователю.

    Следующий вспомогательный класс объекта может применяться для представления CAs:

    pkiCA OBJECT-CLASS ::= {
  SUBCLASS OF { top}
  KIND auxiliary
  MAY CONTAIN {cACertificate |
      certificateRevocationList |
      authorityRevocationList |
      crossCertificatePair }
  ID   joint-iso-ccitt(2) ds(5)
    objectClass(6) pkiCA(22)
}
cACertificate ATTRIBUTE ::=  {
  WITH SYNTAX Certificate
  EQUALITY MATCHING RULE
    certificateExactMatch
  ID joint-iso-ccitt(2) ds(5)
     attributeType(4) 
     cACertificate(37) 
}
crossCertificatePairATTRIBUTE::={
  WITH SYNTAX   CertificatePair
  EQUALITY MATCHING RULE
    certificatePairExactMatch
  ID joint-iso-ccitt(2) ds(5)
     attributeType(4) 
     crossCertificatePair(40)
}

    Атрибут cACertificate записи каталога СА должен использоваться для хранения самоподписанных сертификатов (если они есть) и сертификатов, выпущенных для данного СА САs из той же области, что и данный СА.

    Forward -элементы crossCertificatePair -атрибута записи каталога СА должны использоваться для хранения всех сертификатов, выпущенных данным СА за исключением самоподписанных сертификатов. Дополнительно reverse элементы crossCertificatePair -атрибута записи каталога СА могут содержать подмножество сертификатов, выпущенных данным СА для других CAs. Когда присутствуют оба элемента, forward и reverse, в значении одного атрибута, имя выпускающего в одном сертификате должно соответствовать имени субъекта в другом и наоборот, и открытый ключ субъекта в одном сертификате должен иметь возможность проверять подпись в другом сертификате и наоборот.

    Если присутствует элемент reverse, значение forward -элемента и значение reverse -элемента не обязательно должны являться значениями одного о того же атрибута; другими словами они могут являться значениями как одного атрибута, так и значениями двух атрибутов.

    В случае v3 сертификатов ни один из перечисленных выше сертификатов не должен включать расширение basicConstraints со значением сА, установленным в FALSE.

    Определение области относится исключительно к локальной политике.

    certificateRevocationListATTRIBUTE::={
    WITH SYNTAX  CertificateList
    EQUALITY MATCHING RULE
      certificateListExactMatch
    ID joint-iso-ccitt(2) ds(5)
      attributeType(4)
      certificateRevocationList(39)
}

    Атрибут certificateRevocationList, если присутствует в конкретной записи СА, содержит CRL(s).

    authorityRevocationListATTRIBUTE::={
    WITH SYNTAX   CertificateList
    EQUALITY MATCHING RULE
      certificateListExactMatch
    ID joint-iso-ccitt(2) ds(5)
      attributeType(4)
    authorityRevocationList(38)
}

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

    Точки распространения CRL являются дополнительным механизмом, который может использоваться для распространения информации об отмене.

    Если СА решает задействовать точки распространения CRL, для этого используется следующий класс объектов.

    cRLDistributionPoint OBJECT-CLASS::= {
  SUBCLASS OF { top }
  KIND structural
  MUST CONTAIN { commonName }
  MAY CONTAIN {
     certificateRevocationList |
     authorityRevocationList |
     deltaRevocationList }
  ID joint-iso-ccitt(2) ds(5)
     objectClass(6) 
     cRLDistributionPoint(19) }

    Атрибуты certificateRevocationList и authorityRevocationList определены выше.

    Атрибут commonName и атрибуты deltaRevocationList, определенные в Х.509, продублированы ниже.

    commonName   ATTRIBUTE::={
  SUBTYPE OF name
  WITH SYNTAX DirectoryString
  ID joint-iso-ccitt(2) ds(5)
    attributeType(4) 
    commonName(3) 
}
deltaRevocationList ATTRIBUTE ::= {
  WITH SYNTAX CertificateList
  EQUALITY MATCHING RULE
    certificateListExactMatch
  ID joint-iso-ccitt(2) ds(5)
    attributeType(4)
    deltaRevocationList(53) }

    Дельта CRLs является дополнительным механизмом, который может применяться для осуществления распределения информации об отмене.

    Если СА выбирает использование дельта CRLs, применяется представленный здесь класс объекта.

    deltaCRL OBJECT-CLASS ::= {
  SUBCLASS OF { top }
  KIND auxiliary
  MAY CONTAIN { deltaRevocationList }
  ID joint-iso-ccitt(2) ds(5)
    objectClass(6) deltaCRL(23) 
}

    Возможный транспорт

    Транспортные протоколы, описанные ниже, позволяют конечным участникам, RAs и CАs передавать друг другу PKI-сообщения. Не существует требований относительно применения конкретных механизмов безопасности на данном уровне, если сообщения PKI соответствующем образом защищены (это так, если используется OPTIONAL PKIProtection параметр, как определено для каждого сообщения).

    Протокол управления на основе файла

    Файл, содержащий сообщение PKI, должен содержать только DER- представление одного PKI-сообщения, например, там не должно быть внешнего заголовка или информации в конце данного файла.

    Такие файлы могут применяться для передачи PKI-сообщений, с помощью, например, FTP.

    Протокол управления, основанный на ТСР

    Используется следующий простой протокол, основанный на ТСР, для передачи PKI-сообщений. Данный протокол соответствует случаям, когда конечный участник (или RA) инициирует транзакцию и может принимать результаты.

    Если транзакция инициируется PKI-участником (RA или СА), то конечный участник должен либо задействовать listener-процесс, либо иметь соответствующую ссылку, которая позволяет получать PKI-сообщения от компонента управления PKI.

    Протокол предполагает существование listener-процесса на RA или СА, который может принимать PKI-сообщения на определенный порт (номер порта 829). Обычно инициатор связывается с данным портом и передает начальное PKI-сообщение для данного ID транзакции. Отвечающий передает PKI-сообщение и/или номер ссылки, который будет использоваться позднее для получения реального PKI- сообщения ответа.

    Если на данный запрос получено несколько PKI-сообщений ответа (возможно, если некоторая часть запроса обрабатывается быстрее, чем остальные), то также возвращается новая ссылка.

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

    Инициатор транзакции посылает получателю <<direct TCP-based PKI message>>. Получатель отвечает аналогичным сообщением.

    <<direct TCP-based PKI message>> состоит из:

    length (32 бита), flag (8 бит), value

    Протокол управления по e-mail

    Данный раздел описывает способы для пересылки сообщений в представлении ASN.1 для обменов, рассмотренных в предыдущем разделе, с помощью e-mail.

    Простой MIME объект определяется следующим образом.

    Content-Type: application/pkixcmp
Content-Transfer-Encoding: base64
<<the ASN.1 DER-encoded PKIX-CMP
   message, base64-encoded>>

    Данный объект MIME может быть послан или получен с использованием общего MIME, предоставляя простой почтовый транспорт для PKIX-CMP сообщений. Реализации могут также распознавать и задействовать MIME-тип application/x-pkixcmp (определенный в более ранних версиях), чтобы обеспечить обратную совместимость.

    Протокол управления по НТТР

    Данный подраздел описывает способы для пересылки сообщений в ASN.1 представлении для обменов, описанных в предыдущем разделе, с помощью НТТР.

    Простой MIME объект описывается следующим образом.

    Content-Type: application/pkixcmp
<<the ASN.1 DER-encoded
    PKIX-CMP message>>

    Данный MIME-объект может быть послан или получен с использованием НТТР, используя простой браузер-ориентированный транспорт для PKIX-CMP сообщений. Реализации могут также распознавать и использовать тип MIME application/x-pkixcmp (определенный в более ранних версиях), для обеспечения обратной совместимости.

    Протоколы управления по LDAP v2

    Данный протокол предназначен для предоставления доступа к репозиториям PKI для получения информации и управления этой информацией. Протокол основан на LDAP v2, определенном в RFC 1777.

    Рассмотрим требования для получения информации PKI X.509 из репозитория, включая сертификаты и CRLs.

    Конечные участники и САs, используя подмножество протокола LDAPv2, получают информацию PKI из репозитория.

    САs помещает информацию PKI в репозиторий, также используя подмножество протокола LDAPv2.

    Рассмотрим получение информации PKI из репозитория и управление информацией PKI в нем. Опишем профиль протокола LDAPv2 для выполнения этих функций.

    Приведем требования для получения информации PKI (сертификат, CRL или другая представляющая интерес информация) из записи в репозитории, когда данная запись (либо конечного участника, либо СА) имеет известное имя. При этом используется термин "чтение репозитория".

    Рассмотрим требования, когда имя записи неизвестно, но может использоваться некоторая другая информация для фильтрации записей в репозитории. При этом используется термин "поиск в репозитории".

    Рассмотрим требования для САs для добавления, удаления и модификации информации PKI (сертификат, CRL или другая представляющая интерес информация) в репозитории. При этом используется термин "модификация репозитория".

    Далее описано подмножество LDAPv2 поддержки каждой из этих функций. Заметим, что сервис поиска в репозитории является более общим относительно сервиса чтения репозитория в терминах функциональности LDAPv2.

    LDAP чтение репозитория

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

    BindRequest (и BindResponse)
SearchRequest (и SearchResponse)
UnbindRequest

    Bind Request

    Приложение, предоставляющее LDAP сервис чтения репозитория, должно реализовать следующее подмножество данной операции:

    BindRequest ::= [APPLICATION 0] SEQUENCE {
    version  INTEGER (2),
    name     LDAPDN, 
     -- должен приниматься NULL LDAPDN
    simpleauth [0] OCTET STRING 
     -- должен приниматься NULL simple }

    Приложение, предоставляющее сервис чтения репозитория, может также реализовать другие возможности BindRequest.

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

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

    Bind Response

    Приложение, предоставляющее сервис чтения репозитория, должно полностью реализовать данный элемент протокола, при этом могут возвращаться только следующие коды ошибок при выполнении операции Bind:

    success                   (0),
operationsError           (1),
  protocolError           (2),
  authMethodNotSupported  (7),
  noSuchObject            (32),
  invalidDNSyntax         (34),
  inappropriateAuthentication (48),
  invalidCredentials      (49),
  busy                    (51),
  unavailable             (52),
  unwillingToPerform      (53),
  other                   (80)

    Search Request

    Приложение, предоставляющее LDAP сервис чтения репозитория, должно реализовывать следующее подмножество SearchRequest:

    SearchRequest ::= [APPLICATION 3] SEQUENCE {
  baseObject  LDAPDN,
  scope       ENUMERATED {baseObject (0), },
  derefAliases ENUMERATED {
     neverDerefAliases (0),
  },
  sizeLimit  INTEGER (0),
  timeLimit  INTEGER (0),
  attrsOnly  BOOLEAN, -- FALSE only
  filter     Filter,
  attributes SEQUENCE OF AttributeType
}
Filter ::= CHOICE {
  present [7] AttributeType,
   -- только "objectСlass"
}

    Данное подмножество LDAPv2 SearchRequest обеспечивает операцию " read " LDAPv2: поиск объекта с использованием фильтра для проверки существования атрибута objectClass.

    Приложение, предоставляющее сервис чтения репозитория, может также реализовать другие возможности SearchRequest.

    Search Response

    Приложение, предоставляющее LDAP сервис поиска в репозитории, должно полностью реализовать SearchResponse.

    Заметим, что в том случае, когда атрибут имеет несколько значений, например, userCertificate, SearchResponse содержит все значения, предполагая, что запрашивающий имеет достаточно прав доступа. У приложения или доверяющей группы может возникнуть необходимость выбрать для использования соответствующее значение. Заметим также, что получение сертификата из именованной записи не гарантирует, что сертификат будет включать то же самое DN, и в некоторых случаях subjectDN в сертификате может быть NULL.

    LDAP поиск в репозитории

    Для поиска в репозитории записи, содержащей сертификат, CRL или другую интересующую информацию, с использованием произвольного критерия, необходимо подмножество следующих трех операций LDAP:

    BindRequest (и BindResponse), 
SearchRequest (и SearchResponse)
UnbindRequest

    Далее приведено требуемое подмножество для каждой операции.

    Search Request

    Приложение, предоставляющее сервис поиска в репозитории LDAP, должно реализовать следующее подмножество протокола SearchRequest.

    SearchRequest ::= [APPLICATION 3] SEQUENCE {
  baseObject   LDAPDN,
  scope ENUMERATED {
    baseObject   (0),
    singleLevel  (1),
    wholeSubtree (2)
  },
  
  derefAliases   ENUMERATED {
    neverDerefAliases (0),
  },
  
  sizeLimit INTEGER (0 .. maxInt),
  timeLimit INTEGER (0 .. maxInt),
  attrsOnly BOOLEAN,  -- FALSE only
  filter Filter,
  attributes SEQUENCE OF
  AttributeType 
}

    Должны поддерживаться все аспекты SearchRequest, за исключением следующего:

  • Необходимо поддерживать только значение neverDeferAliases для deferAliases.
  • Необходимо поддерживать только значение FALSE для attrsOnly.
    •

    Данное подмножество предоставляет более общие возможности поиска. Это надмножество подмножества SearchRequest, определенного выше. Элементами, добавляемыми в данный сервис, являются:

  • Должна поддерживаться область singleLevel и wholeSubtree.
  • Включен sizeLimit.
  • Включен timeLimit.
  • Существует возможность фильтрации.
    •

    Приложение, предоставляющее сервис поиска в репозитории LDAP, может также реализовывать и другие аспекты SearchRequest.

    LDAP модификация репозитория

    Для добавления, удаления и модификации PKI информации в репозитории требуется подмножество следующих операций LDAP:

    BindRequest (и BindResponse), 
ModifyRequest (и ModifyResponse), 
AddRequest (и AddResponse)
DelRequest (и DelResponse),
UnbindRequest

    Далее определяется требуемое подмножество для каждой операции.

    Bind

    Приложение, предоставляющее сервис модификации репозитория LDAP, должно реализовывать следующее подмножество операций:

    BindRequest ::= [APPLICATION 0] SEQUENCE {
  version INTEGER (2),
  name    LDAPDN,
  simpleauth [0] OCTET STRING }

    Сервис модификации репозитория LDAP должен реализовывать аутентифицированный доступ.

    Необходимые подмножества BindResponse являются теми же, что были описаны выше.

    ModifyRequest

    Приложение, предоставляющее сервис модификации в репозитории LDAP, должно реализовывать следующее подмножество протокола ModifyRequest.

    ModifyRequest ::= [APPLICATION 6] SEQUENCE {
  object LDAPDN,
  modification SEQUENCE OF SEQUENCE {
    operation ENUMERATED   {
      add (0),
      delete (1)
    },
    modification SEQUENCE {
      type AttributeType,
      values SET OF
      AttributeValue
    }
  }
}

    Необходимо поддерживать только значения add и delete для ModifyRequest.

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^