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

Синтаксис CertReqMessage

Сообщение запроса сертификата состоит из запроса сертификата, необязательного поля доказательства обладания и необязательного поля регистрационной информации.

CertReqMessages ::= SEQUENCE SIZE
  (1..MAX) OF CertReqMsg
CertReqMsg ::= SEQUENCE {
  certReq   CertRequest,
  pop       ProofOfPossession  OPTIONAL,
  -- содержание зависит от типа ключа 
  regInfo   SEQUENCE SIZE(1..MAX) of 
      AttributeTypeAndValue OPTIONAL }

Поле доказательства обладания используется для демонстрации того, что участник, указанный в сертификате, действительно знает соответствующий закрытый ключ. Это поле может быть вычислено над содержимым поля certReq и может варьироваться в зависимости от типов алгоритма открытого ключа и режима выполнения.

Поле regInfo должно содержать только дополнительную информацию, относящуюся к контексту запроса сертификата, когда такая информация требуется для выполнения запроса сертификата. Данная информация может включать контактную информацию подписчика, сведения о счете или другую служебную информацию, необходимую для выполнения запроса сертификата.

Информация, непосредственно относящаяся к содержимому сертификата, должна быть включена в содержимое certReq. Однако включение RAs дополнительного содержимого в certReq может привести к тому, что поле POP станет недействительным. Таким образом, данные, включаемые в содержимое сертификата, могут передаваться в regInfo.

Защита сообщения PKI

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

При применении защиты используется следующая структура:

PKIProtection ::= BIT STRING

Входом для вычисления PKIProtection является DER-представление следующей структуры данных:

ProtectedPart ::=   SEQUENCE {
  header  PKIHeader,
  body    PKIBody
}

Могут быть ситуации, когда PKIProtection BIT STRING сознательно не используется для защиты сообщения (т.е. это OPTIONAL поле опущено), т.к. применяется другая, внешняя по отношению к PKI, защита. Это явно допускается. Примерами такой внешней защиты являются PKCS #7 и Security Multiparts (RFC 1847) инкапсуляция PKIMessage (или просто PKIBody, если безопасность информации PKIHeader обеспечивается посредством внешних механизмов). Следует заметить, однако, что многие такие внешние механизмы требуют, чтобы конечный участник уже имел сертификат открытого ключа и/или DN и/или другую аналогичную относящуюся к инфраструктуре информацию. Таким образом, это может не соответствовать начальной регистрации, восстановлению ключа или другому процессу, характеризующемуся "начальной загрузкой". Для таких случаев может быть необходимо, чтобы использовались PKIProtection -параметры. В будущем, если внешние механизмы будут модифицированы таким образом, чтобы соответствовать сценариям начальной загрузки, использование PKIProtection станет более редким или вовсе необязательным.

В зависимости от условий биты PKIProtection могут содержать МАС или подпись. Возможны следующие случаи:

1. Разделяемая секретная информация

   В данном случае отправитель и получатель разделяют секретную информацию (установленную внешними способами или полученную из предыдущих операций PKI). PKIProtection будет содержать значение МАС и protectionAlg будет следующим:

   PasswordBasedMac ::=
     OBJECT IDENTIFIER 
       --  {1 2 840 113533 7 66 13}
   PBMParameter ::= SEQUENCE {
     salt  OCTET STRING,
     owf   AlgorithmIdentifier,
       --  AlgId для односторонней
       --  функции OWF 
       --  (рекомендуется SHA-1)
     iterationCount     INTEGER,
       --  количество применений OWF 
     mac     AlgorithmIdentifier
       --  AlgId MAC (например,
       --  DES-MAC, Triple-DES-MAC, 
       --  или HMAC)
   }

   В указанном выше protectionAlg значение salt присоединяется к разделяемому секрету. Затем OWF применяется iterationCount раз, где секрет с добавлением salt является входом в первую итерацию и вход каждой итерации является выходом предыдущей. Выход последней итерации (называемый BASEKEY ) используется для создания симметричного ключа. Если алгоритм МАС требует K -битного ключа и K < H, то используются младшие K бит BASEKEY. Если K > H, то весь BASEKEY используется для младших Н битов ключа, OWF ("2" || BASEKEY ) применяется для следующих Н битов ключа и т.д.
2. Пара ключей DH

   Когда отправитель и получатель имеют сертификаты Диффи-Хеллмана с совместимыми параметрами, для защиты сообщения конечный участник должен создать симметричный ключ, основываясь на значении своего закрытого ключа DH и открытом ключе DH получателя PKI-сообщения.

   PKIProtection будет содержать значение МАС с ключом, полученным из симметричного ключа и protectionAlg следующим образом:

   DHBasedMac ::= OBJECT IDENTIFIER 
       --  {1 2 840 113533 7 66 30}
   DHBMParameter ::= SEQUENCE {
     owf     AlgorithmIdentifier,
       --   AlgId для односторонней
       --   функции (OWF) 
       --   (рекомендуется SHA-1)
     mac       AlgorithmIdentifier
       --   the MAC AlgId (например,
       --   DES-MAC, 
       --   Triple-DES-MAC или НМАС)
   }

   protectionAlg OWF применяется к результату вычислений DH. Выход OWF (называемый BASEKEY ) используется для формирования симметричного ключа. Если алгоритм МАС требует K -битного ключа и K < H, то используются K младших битов BASEKEY. Если K > H, то используется весь BASEKEY для младших Н битов ключа, OWF ("1" || BASEKEY) применяется для следующих младших Н битов ключа и т.д.
3. Подпись

   Если отправитель имеет пару ключей подписывания, он может просто подписать PKI-сообщение. PKIProtection будет содержать значение подписи, protectionAlg будет определяться значением AlgorithnIdentifier.
4. Многократная защита

   В случае, когда конечный участник отправляет защищенное PKI-сообщение RA, RA может перенаправить данное сообщение СА, присоединив свою собственную защиту (которая может быть МАС или цифровой подписью, в зависимости от информации и сертификатов, разделяемых RA и СА). Это предполагает вложение всего сообщения, посылаемого конечным участником, в новое PKI-сообщение. Используется следующая структура.

   NestedMessageContent ::= PKIMessage