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




Структуры РОР - часть 2


Это "прямой" метод, как он определен выше. Данный метод обычно используется в окружении, в котором RA проверяет POP и затем осуществляет запрос сертификата у СА от имени конечного участника. В данном сценарии СА доверяет RA выполнять POP до того, как RA запросит сертификат для конечного участника. Полный протокол выглядит следующим образом (заметим, что req’ не обязательно должно инкапсулировать req в качестве вложенного сообщения):

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

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

  1. Сертификат зашифрован с помощью симметричного ключа, полученного из закрытого KAK СА и открытого ключа, для которого выполнен запрос сертификата.
  2. Вместо 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).




Содержание  Назад  Вперед