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

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

Транспортные протоколы, описанные ниже, позволяют конечным участникам, 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.