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

Общие структуры данных

Перед тем как указывать типы, которые могут быть размещены в PKIBody, мы определим некоторые структуры данных, которые могут применяться.

Содержимое запрашиваемого сертификата

Различные управляющие сообщения PKI требуют, чтобы инициатор сообщения указал некоторые поля, которые должны присутствовать в сертификате. Структура CertTemplate позволяет конечному участнику или RA указать как можно больше того, что должен содержать сертификат. CertTemplate аналогична Certificate, но все поля являются необязательными.

Заметим, что даже если инициатор полностью указал требуемое содержимое сертификата, СА имеет право модифицировать поля в сертификате, который он реально издает. Если модифицированный сертификат для запрашивающего неприемлем, можно задержать Confirmation -сообщение или послать Error -сообщение (с PKIStatus "rejection" ).

Зашифрованные значения

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

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

Если получатель PKIMessage уже имеет закрытый ключ, используемый для дешифрования, поле encSymmKey может содержать ключ сессии, зашифрованный с использованием открытого ключа получателя.

Коды статуса и информация о неудаче для PKI-сообщений

Все сообщения ответа включают определенную информацию о статусе. Определены следующие значения:

PKIStatus ::= INTEGER {
  Granted          (0),
      -- получено то, что запрашивалось
  grantedWithMods  (1),
      -- получено что-то подобное, что запрашивалось; 
	  -- запрашивающий несет ответственность за 
      -- установленные отличия 
  rejection        (2),
      -- не получено то, что запрашивалось,
	  -- более подробная информация в сообщении 
  waiting          (3),
      -- запрос не обработан,
      -- следует запросить позднее 
  revocationWarning  (4),
      -- данное сообщение содержит предупреждение, 
	  -- что скоро будет отмена 
  revocationNotification  (5),
      -- уведомление, что произошла отмена
  keyUpdateWarning   (6)
      -- изменение уже выполнено для oldCertId, 
      -- указанного в сообщении запроса изменения ключа
}

Отвечающий может использовать следующий синтаксис для предоставления более подробной информации о причинах неудачи.

PKIFailureInfo ::= BIT STRING {
    -- причин неудачи может быть много
    -- при необходимости в будущем могут 
	-- быть добавлены другие коды причин.
  badAlg  (0),
    -- нераспознанный или неподдерживаемый
    -- Идентификатор Алгоритма 
  badMessageCheck  (1),
    -- сбой в процессе проверки целостности
	-- (например, подпись не верифицирована)
  badRequest       (2),
    -- транзакция не разрешена или не поддерживается 
  badTime          (3),
    -- messageTime недостаточно точно
    -- соответствует системному времени,
	-- как определено локальной политикой 
  badCertId        (4),
    -- сертификат не может быть найден в
	-- соответствии с предоставленным критерием 
  badDataFormat    (5),
    -- переданные данные имеют
    -- неправильный формат 
  wrongAuthority   (6),
    -- уполномоченный орган, указанный 
	-- в запросе, отличается от того, 
	-- который определен в токене ответа
  incorrectData    (7),
    -- данные из запроса являются некорректными 
    -- (используется для сервисов нотариуса)
  missingTimeStamp (8),
    -- когда timestamp опущена, но
    -- должна присутствовать 
    -- (в соответствии с политикой) 
  badPOP           (9)
    -- упал РОР 
}
PKIStatusInfo ::= SEQUENCE {
  status PKIStatus,
  statusString PKIFreeText OPTIONAL,
  failInfo PKIFailureInfo OPTIONAL
}

Идентификация сертификата

Для идентификации конкретных сертификатов используется структура данных CertId.

Каждый корневой СА должен иметь возможность опубликовать свой текущий открытый ключ посредством некоторых "внешних" механизмов. Хотя такие механизмы находятся вне рассматриваемой предметной области, мы определим структуры данных, которые могут ими поддерживаться.

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

OOBCert ::= Certificate

Поля в данном сертификате имеют следующие ограничения:

• Сертификат должен быть самоподписанным (т.е. подпись должна проверяться с использованием поля SubjectPublicKeyInfo );
• Поля subject и issuer должны быть идентичны;
• Если поле subject является NULL, то оба расширения, subjectAltName и issuerAltName, должны присутствовать и иметь одно и то же значение;
• Значения всех других расширений должны соответствовать самоподписанному сертификату (т.е. идентификаторы ключа для subject и issuer должны быть одни и те же).

OOBCertHash ::= SEQUENCE {
  hashAlg [0] AlgorithmIdentifier
    OPTIONAL,
  certId [1] CertId OPTIONAL,
  hashVal BIT STRING
    -- hashVal вычисляется для
    -- самоподписанного 
    -- сертификата с идентификатором
    -- certID.}

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

Опции архивации

Запрашивающий может указать, что он хочет архивировать значение закрытого ключа, используя структуру PKIArchiveOptions.

Публикуемая информация

Запрашивающий может указать, что он хочет, чтобы PKI опубликовал сертификат, используя структуру PKIPublicationInfo.

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

Если запрос сертификата предназначен для пары ключей подписывания (т.е. запрос для верифицирующего сертификата), то доказательство обладания закрытым ключом подписывания демонстрируется с помощью структуры 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.

POPODecKeyChallContent ::= SEQUENCE OF Challenge
    -- один Challenge на запрос сертификата ключа 
    -- шифрования (в той же последовательности, что и 
    -- другие запросы, появляющиеся в CertReqMessages).
Challenge ::= SEQUENCE {
  owf       AlgorithmIdentifier  OPTIONAL,
    -- должен присутствовать в первом Challenge; может 
    -- быть опущен в любом следующем Challenge в 
    -- POPODecKeyChallContent (если опущен, то owf 
    -- используется в немедленно создаваемом Challenge).
  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.2. Полный протокол доказательства обладания закрытым ключем