RFC: 4306
Оригинал: Internet Key Exchange (IKEv2) Protocol
Другие версии: RFC 2407, RFC 2408, RFC 2409, RFC 5996
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 4306, Страница 44 из 62

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

Элемент Certificate Request (CERTREQ) обеспечивает возможность запросить предпочитаемые сертификаты через IKE и может появляться в откликах IKE_INIT_SA и запросах IKE_AUTH. Элементы Certificate Request могут включаться в обмен, когда отправителю нужен сертификат получателя. При наличии множества доверенных CA, если поле C Cert Encoding не разрешает список, следует передавать множество элементов Certificate Request.

Элемент Certificate Request содержит следующие поля:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert Encoding !                                               !
+-+-+-+-+-+-+-+-+                                               !
~                    Certification Authority                    ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 13: Формат запроса сертификата
  • Certificate Encoding (1 октет) — задает тип представления запрашиваемого сертификата. Возможные значения перечислены в параграфе 3.6.
  • Certification Authority (переменный размер) — указывает подходящий удостоверяющий центр для запрашиваемого типа сертификата.

Идентификатор типа для элемента данных Certificate Request имеет значение 38.

Поле Certificate Encoding имеет такие же значения, как описано в параграфе 3.6. Поле Certification Authority содержит индикатор удостоверяющего центра для данного типа сертификата. Значение Certification Authority представляет собой конкатенацию хэш-значений SHA-1 для открытых ключей удостоверяющих центров (CA). Каждое значение представляет собой хэш SHA-1 для элемента Subject Public Key Info (см. параграф 4.1.2.7 работы [RFC3280]) из каждого сертификата Trust Anchor. Двадцатиоктетные хэш-значения объединяются (конкатенация) и помещаются в поле без дополнительного форматирования.

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

Элемент Certificate Request обрабатывается путем проверки поля Cert Encoding для определения наличия у обрабатывающего сертификатов этого типа. Если такие сертификаты имеются, проверяется поле Certification Authority для проверки наличия у обрабатывающего сертификатов, которые могут быть проверены в одном из указанных удостоверяющих центров. Это может быть цепочка сертификатов.

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

  • настроен на использование идентификации по сертификатам;
  • имеет разрешение на передачу элемента CERT;
  • имеет соответствующую политику доверия к CA для текущего согласования;
  • имеет по крайней мере один действующий (time-wise) и подходящий сертификат конечного объекта, связанный с CA из CERTREQ.

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

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

Страница 44 из 62

2007 - 2022 © Русские переводы RFC, IETF, ISOC.