3ae90dbb

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


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

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

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

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


    Это "прямой" метод, как он определен выше. Данный метод обычно используется в окружении, в котором 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.

Листинг 18.4. Сообщения вызова-ответа для доказательства обладания закрытым ключом (html, txt)


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



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.4. Сообщения вызова-ответа для доказательства обладания закрытым ключом


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


Содержание раздела