Протокол запроса ресурсов PKI

Протокол запроса ресурсов PKI ( PRQP ) — это Интернет-протокол, используемый для получения информации об услугах, связанных с X.509 центром сертификации . Это описано RFC   7030 опубликован 23 октября 2013 года. PRQP направлен на улучшение проблем совместимости и удобства использования между PKI, помогая находить сервисы и хранилища данных, связанные с центром сертификации. Сообщения, передаваемые через PRQP, кодируются в ASN.1 и обычно передаются через HTTP .

Фон

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

Связанные методы

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

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

Чтобы предоставить указатели на опубликованные данные, центр сертификации может использовать доступ к информации органов власти (AIA) и Расширения доступа к информации о субъекте (SIA), как подробно описано в РФК   3280 . Первый может предоставить информацию об эмитенте сертификата, а второй последний содержит информацию (внутри сертификатов CA) о предлагаемых услугах. Расширение доступа к информации о субъекте может содержать URI, указывающий на хранилища сертификатов и услуги временных меток. Следовательно, это расширение позволяет получать доступ к сервисам по нескольким различным протоколам. (например , HTTP , FTP , LDAP или SMTP ).

Хотя использование расширений AIA и SIA приветствуется, оно до сих пор не получило широкого распространения. Для этого есть две основные причины. Во-первых, это отсутствие поддержки подобных расширений в доступных клиентах. Вторая причина заключается в том, что расширения статичны, т.е. не поддаются изменению. Действительно, чтобы изменить или добавить новые расширения, чтобы пользователи и приложения быть в курсе новых услуг или их увольнения, справка необходимо переиздать.

Это было бы невозможно для сертификатов конечных объектов (EE), за исключением случаев, когда периодический перевыпуск, но это было бы возможно и для самого сертификата ЦС. Центр сертификации может сохранить тот же открытый ключ и имя и просто добавлять новые значения в расширение AIA в новом сертификате. Если пользователи будут регулярно получать сертификат CA, а не кэшировать его, это позволит им узнать о новых услугах. Хотя это возможно, почти все доступные клиенты не ищут центры сертификации. сертификаты, если они уже хранятся в локальной базе данных клиентов.

В любом случае, поскольку URL-адреса имеют тенденцию меняться довольно часто, пока сертификаты сохраняются. для более длительных периодов времени опыт показывает, что эти продления неизменно указать на URL-адреса, которые больше не существуют. Более того, учитывая тот факт, что организация, выдающая сертификаты и тот, кто управляет услугами, может быть другим, невозможно, чтобы выдающий центр сертификации перевыпустит все свои сертификаты в случае изменения URL-адреса сервера. Поэтому неразумно полагаться на использование расширений AIA или SIA для поиск доступных сервисов и репозиториев.

Записи службы DNS

указатели . Считается, что запись SRV или запись службы DNS предоставляют к серверам непосредственно в DNS (RFC 1035). Как определено в RFC 2782, введение этого типа записей позволяет администраторам для выполнения операций, весьма похожих на те, которые необходимы для решения проблемных адресов PRQP, т.е. легко настраиваемая служба обнаружения PKI.

Основная идея состоит в том, чтобы клиент запросил в DNS конкретную запись SRV. Например, если клиент LDAP с поддержкой SRV хочет обнаружить сервер LDAP для определенного домена, он выполняет поиск DNS для _ldap._tcp.example.com. ( _tcp означает, что клиент запрашивает TCP сервер с поддержкой LDAP- ). Возвращенная запись содержит информацию о приоритете, весе, порте и цель службы в этом домене.

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

Атрибуты DC используются для указания компонентов домена DNS-имени. например, доменное имя example.com может быть представлено с помощью dc=com, dc= формат примера. Если бы в предметной области ЦС использовался такой формат, поле «Эмитент» позволит клиентским приложениям выполнять поиск DNS для предоставленный домен, где может храниться информация о репозиториях и сервисах.

Однако в настоящее время практика совсем другая. На самом деле клиенту чрезвычайно сложно сопоставить цифровые сертификаты. к записям DNS, поскольку формат DC не получил широкого распространения в существующих центрах сертификации. Например, только один сертификат из хранилища сертификатов IE7/Outlook использует домен. компоненты для обеспечения сопоставления между сертификатом и доменом Интернета.