
 Использование Tumar CSP v5 для работы в инфраструктуре PKIX и при построении документооборота.
 Процесс обработки использует только методы криптопровайдера в соответствии со спецификацией
 Microsoft - Cryptographic Service Provider (CSP) и JNI интерфейс для Java-приложений.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


 Взаимодействие с УЦ.
 ~~~~~~~~~~~~~~~~~~~~

 1. Инициализация пользователя в УЦ. Применяется в случае, если клиент еще не имеет ключей
 и сертификатов, но знает свой идентификационный номер и владеет секретом (например, паролем).

 Пример ex_ir.cpp демонстрирует процесс создания ключа и формирования запроса в УЦ на
 получение сертификата защищенного общим секретом.
 В соответствии с
 RFC-4211 Certificate Request Message Format (CRMF)
 RFC-4210 Certificate Management Protocol (CMP)
   5.3.1.   Initialization Request
   5.1.3.1. Shared Secret Information

 Пример ex_ip.cpp демонстрирует процесс проверки ответа от УЦ с использованием общего секрета
 после его получения, и установки в контейнер выпущенных сертификатов пользователя и полученных 
 сертификатов УЦ.
 В соответствии с
 RFC-4210 Certificate Management Protocol (CMP)
   5.3.2.   Initialization Response
   5.1.3.1. Shared Secret Information

 2. Выпуск сертификатов пользователя. Применяется в случае, если клиент уже имеет ключ и 
 сертификат с правами подписи.

 Пример ex_сr.cpp демонстрирует процесс создания ключа и формирования запроса в УЦ на
 получение сертификата защищенного ЭЦП.
 В соответствии с
 RFC-4211 Certificate Request Message Format (CRMF)
 RFC-4210 Certificate Management Protocol (CMP)
   5.3.3.   Certification Request
   5.1.3.3. Signature
 
 Пример ex_сr2.cpp аналогичен ex_сr.cpp. Демонстрирует процесс нескольких ключей и формирования 
 запроса в УЦ на получение нескольких сертификатов.

 Пример ex_сp.cpp демонстрирует процесс проверки ответа от УЦ с использованием ЭЦП
 после его получения, и установки в контейнер выпущенных сертификатов пользователя и полученных 
 сертификатов УЦ.
 В соответствии с
 RFC-4210 Certificate Management Protocol (CMP)
   5.3.4.   Certification Response
   5.1.3.3. Signature

 Пример ex_rr.cpp демонстрирует процесс формирования запроса в УЦ на
 отзыв сертификата с указанием причины защищенного ЭЦП.
 В соответствии с
 RFC-4210 Certificate Management Protocol (CMP)
   5.3.9.   Revocation Request Content
   5.1.3.3. Signature

 Пример ex_rr2.cpp то же что и ex_rr.cpp, для внешнего сертификата (не в контейнере).

 Пример ex_ip_crt.cpp демонстрирует получение сертификатов из ответа сервера:
 - сертификатов сообщения
 - выпущенных сертификатов
 - сертификатов УЦ

 Пример ex_kur.cpp демонстрирует процесс формирования запроса в УЦ на
 изменение сертификата защищенного ЭЦП.
 В соответствии с
 RFC-4211 Certificate Request Message Format (CRMF)
 RFC-4210 Certificate Management Protocol (CMP)
   5.3.5.   Key Update Request Content
   5.1.3.3. Signature
 

 3. Дополнительные запросы в УЦ. Позволяют использовать сервисные возможности УЦ.

 Пример ex_genm.cpp демонстрирует процесс формирования запроса в УЦ на получение 
 текущего СОС, защищенного ЭЦП.
 В соответствии с
 RFC-4210 Certificate Management Protocol (CMP)
   5.3.19. PKI General Message Content
	
 Пример ex_genp.cpp демонстрирует процесс проверки ответа от УЦ с использованием ЭЦП
 после его получения, и экспорт СОС из сообщения.
 В соответствии с
 RFC-4210 Certificate Management Protocol (CMP)
   5.3.20. PKI General Response Content


 Работа с сертификатами и списками отзыва сертификатов (СОС).
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 1. Пример ex_crt.cpp демонстрирует процесс проверки подлинности сертификата
 с использованием цепочек сертификатов контейнера.

 2. Пример ex_crt_val.cpp демонстрирует процесс проверки валидности сертификата

 3. Пример ex_crt_prop.cpp демонстрирует процесс проверки свойств сертификата, таких как
 прав использования ключа, полномочий, соответствия сертификата заданным политикам использования.

 4. Пример ex_crl.cpp демонстрирует процесс проверки подлинности СОС
 с использованием цепочек сертификатов контейнера.

 4. Пример ex_crl2.cpp демонстрирует процесс проверки подлинности СОС
 с использованием сертификата УЦ.

 5. Пример ex_rev.cpp демонстрирует процесс проверки статуса сертификата с использованием СОС.


 Взаимодействие с сервером OCSP.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 1. Пример ex_ocsp_r.cpp демонстрирует процесс формирования запроса к серверу OCSP для получения
 квитанции о статусе сертификата.
 В соответствии с
 RFC-2560 Online Certificate Status Protocol - OCSP

 2. Пример ex_ocsp_r2.cpp демонстрирует процесс формирования запроса к серверу OCSP для получения
 квитанции о статусе сертификата без использования ключевого контейнера.
 В соответствии с
 RFC-2560 Online Certificate Status Protocol - OCSP

 2. Пример ex_ocsp_p.cpp демонстрирует процесс проверки ответа от сервера OCSP с использованием ЭЦП
 и проверки статуса указанного сертификата.
 В соответствии с
 RFC-2560 Online Certificate Status Protocol - OCSP


 Работа с шифрованными сообщениями.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 1. Пример ex_enc.cpp демонстрирует процесс формирования зашифрованного сообщения для 
 указанного получателя в формате Enveloped PKCS-7 message, в соответствии со стандартом 
 PKCS #7: Cryptographic Message Syntax Standard

 2. Пример ex_enc3.cpp демонстрирует процесс формирования зашифрованного сообщения для 
 нескольких указанных получателей в формате Enveloped PKCS-7 message, в соответствии со стандартом 
 PKCS #7: Cryptographic Message Syntax Standard

 3. Пример ex_dnc.cpp демонстрирует процесс расшифрования зашифрованного сообщения
 в формате Enveloped PKCS-7 message, в соответствии со стандартом 
 PKCS #7: Cryptographic Message Syntax Standard


 Работа с электронными документами.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 1. Пример ex_sign.cpp демонстрирует процесс формирования электронного документа в
 формате Signed PKCS-7 message, в соответствии со стандартом 
 PKCS #7: Cryptographic Message Syntax Standard

 2. Пример ex_sign_ex.cpp демонстрирует процесс формирования электронного документа в
 формате Signed PKCS-7 message, в соответствии со стандартом 
 PKCS #7: Cryptographic Message Syntax Standard
 а также демонстрирует возможности
    - вкладывать данные в сообщение
    - вкладывать несколько сертификатов
    - добавлять подписываемые атрибуты
    - добавлять неподписываемые атрибуты
    - формировать множественные подписи
 
 3. Пример ex_vrf.cpp демонстрирует процесс проверки электронного документа в
 формате Signed PKCS-7 message, в соответствии со стандартом 
 PKCS #7: Cryptographic Message Syntax Standard
 при наличии сертификата подписавшего.

 4. Пример ex_vrf_a.cpp делает то же, что и ex_vrf.cpp, но для случая
 если данные вложены в сообщение.

 формате Signed PKCS-7 message, в соответствии со стандартом 
 PKCS #7: Cryptographic Message Syntax Standard
 при наличии сертификата подписавшего.

 5. Пример ex_vrf_ex.cpp демонстрирует процесс проверки электронного документа в
 формате Signed PKCS-7 message, в соответствии со стандартом 
 PKCS #7: Cryptographic Message Syntax Standard
 с получением сертификата подписавшего из тела сообщения или получение необходимых
 данных о подписавшем из сообщения для возможности получения сертификата другими
 методами.

 6. Пример ex_sign_deg.cpp демонстрирует процесс создания и проверки дегенеративного
 сообщения в формате Signed PKCS-7 message, в соответствии со стандартом 
 PKCS #7: Cryptographic Message Syntax Standard


 Работа с метками времени (TimeStamp).
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 1. Пример ex_tsp_r.cpp демонстрирует процесс формирования запроса к серверу TSA для получения
 метки времени в соответствии со стандартом
 RFC-3161 Time-Stamp Protocol (TSP)
 
 2. Пример ex_tsp_r.cpp - то же что и ex_tsp_r.cpp, но запрос формируется авторизованный (с ЭЦП).

 3. Пример ex_tsp_vrf.cpp демонстрирует процесс проверки ЭЦП сервера TSA, подписавшего метку времени
 в формате CMS/Signed PKCS-7 message, в соответствии со стандартом 
 RFC-3161 Time-Stamp Protocol (TSP)

 4. Пример ex_tsp_p.cpp демонстрирует процесс получения информации из указанной метки времени

 5. Пример ex_tsp_p7.cpp демонстрирует процесс добавления метки времени в электронный
 документ в формате Signed PKCS-7 message.


 Депонирование ключей.
 ~~~~~~~~~~~~~~~~~~~~~
 RFC 4210 / CMP

 5.3.19.  PKI General Message Content
 5.3.19.14.  Депонирование ключей.

 Запрос на депонирование ключей:
      GenMsg:    {id-it 50.1}, PKCS#8
      GenRep:    {id-it 50.1}, < absent >

 Запрос на получение депонированных ключей:
      GenMsg:    {id-it 50.2}, < absent >
      GenRep:    {id-it 50.2}, PKCS#8

 Запрос на удаление депонированных ключей:
      GenMsg:    {id-it 50.3}, < absent >
      GenRep:    {id-it 50.3}, < absent >

 Запрос и ответ должен быть защищен с использованием механизма Shared Secret Information (5.1.3.1.).

 Клиент зашифровывает ключевой контейнер и формирует PKCS#8. Алгоритм шифрования ключей – ГОСТ 28148-89
 в режиме CBC. Ключом является конкатенация  OTPassword || SharedSecret (в результате
 получаем ключ 160 бит, по CT РК 1073-2007 для 3-го уровня достаточно 150 бит).
 Полученный PKCS#8 вкладывается в запрос и защищается SharedSecret. Номер транзакции 
 (transactionID) и одноразовый пароль (OTPassword), полученные из сообщения, запоминаются. 

 При получении депонированных ключей пользователь формирует запрос, защищенный SharedSecret, 
 с указанием заданного номера транзакции депонирования, извлекает зашифрованный PKCS#8 из 
 ответа сервера, расшифровывает его с использованием ключа OTPassword || SharedSecret, 
 использует полученный контейнер с ключами.

 1. Пример ex_genm_dep.cpp демонстрирует процесс формирования запроса к серверу CMP 
 депонирования ключей и сертификатов контейнера с получением одноразового пароля и
 номера транзакции. Запрос подписывается с использованием идентификационного номера и
 секрета.

 2. Пример ex_genp_dep.cpp демонстрирует процесс проверки ответа сервера на депонирование
 ключей.

 3. Пример ex_genm_dep2.cpp демонстрирует процесс формирования запроса к серверу CMP 
 на получение ранее депонированных ключей и сертификатов контейнера с использованием
 номера транзакции, идентификационного номера и секрета.

 4. Пример ex_genp_dep2.cpp демонстрирует процесс проверки ответа сервера на получение
 ранее депонированных ключей и извлечение ключей и сертификатов с использованием
 одноразового пароля депонирования и секрета.

 5. Пример ex_genm_dep3.cpp демонстрирует процесс формирования запроса к серверу CMP 
 на удаление ранее депонированных ключей и сертификатов контейнера с использованием
 номера транзакции, идентификационного номера и секрета.

 6. Пример ex_genp_dep3.cpp демонстрирует процесс проверки ответа сервера на удаление
 ранее депонированных ключей.


 Работа с базой секретов.
 ~~~~~~~~~~~~~~~~~~~~~~~~
 RFC 4210 / CMP

 5.3.19.  PKI General Message Content
 5.3.19.15.  База данных секретов.

   SecretInfo ::= SEQUENCE {
       version     Version DEFAULT v1,
       userKID     KeyIdentifier,
       alias       [0]  IMPLICIT UTF8String OPTIONAL,
       dn          [1]  IMPLICIT UTF8String OPTIONAL,
       secret      [2]  IMPLICIT OCTET STRING OPTIONAL,
       templ       [3]  IMPLICIT UTF8String OPTIONAL,
       valid       [4]  IMPLICIT BOOLEAN DEFAULT TRUE
   }

   Version  ::=  ENUMERATED  {  v1(0), v2(1), v3(2)  }

   KeyIdentifier ::= OCTET STRING

 Запрос на добавление информации о секрете:
      GenMsg:    {id-it 50.5}, EnvelopedData(SecretInfo) (поля alias, dn, secret - обязательные)
      GenRep:    {id-it 50.5}, < absent >

 Запрос на модификацию информации о секрете:
      GenMsg:    {id-it 50.6}, EnvelopedData(SecretInfo)
      GenRep:    {id-it 50.6}, < absent >

 Запрос на получение информации о секрете:
      GenMsg:    {id-it 50.7}, SecretInfo (обязательный только userKID)
      GenRep:    {id-it 50.7}, EnvelopedData(SecretInfo)

 Запрос на удаление информации о секрете:
      GenMsg:    {id-it 50.8}, SecretInfo (обязательный только userKID)
      GenRep:    {id-it 50.8}, < absent >


5.3.19.9.  Revocation Passphrase

...
   1. EncryptedValue = EnvelopedData(SecretInfo).
   2. Если указанный userKID и DN-имя подписавшего запрос не найдены в базе секретов,
      то речь идет о добавлении нового секрета в базу.
   3. Если поле secret не указано или пустое, то речь идет об удалении секрета из базы.



 Протокол работы при добавлении/модификации информации в базе секретов:
 1. Администратор посылает запрос General Message (5.3.19.1.  CA Protocol Encryption Certificate),
    и получает в ответ сертификат сервера CMP с ключом шифрования.
 2. Формирует стуктуру типа SecretInfo и шифрует ее с использованием полученного 
    сертификата CMP (формат PKCS#7/CMS EnvelopedData).
 3. Формирует CMP запрос на добавление/модификацию и вкладывает в него зашифрованные данные.
 4. Сформированный запрос посылает на сервер CMP.
 5. Сервер получает, проверяет (с учетом полномочий RA) и анализирует запрос, 
    расшифровывает данные на своем секретном ключе, добавляет/модифицирует данные в базе секретов.
 6. Администратор получает, проверяет и анализирует ответ.

 Протокол работы при получении информации из базы секретов:
 1. Администратор формирует CMP запрос на получение информации и вкладывает в него свой сертификат
    для шифрования.
 2. Сформированный CMP запрос посылает на сервер CMP.
 3. Сервер получает, проверяет (с учетом полномочий RA) и анализирует запрос.
 4. Формирует ответ администратору в формате SecretInfo, зашифровывает с использованием
    сертификата пользователя на шифрование.
 5. Администратор получает, проверяет и анализирует ответ.
 6. Расшифровывает вложенные данные используя свой секретный ключ шифрования.
 7. Использует расшифрованные данные (структура SecretInfo).

 Протокол работы при удалении информации из базы секретов:
 1. Администратор формирует CMP запрос на удаление информации.
 2. Сформированный CMP запрос посылает на сервер CMP.
 3. Сервер получает, проверяет (с учетом полномочий RA) и анализирует запрос.
 4. Удаляет информацию о секрете пользователя из базы секретов.
 5. Администратор получает, проверяет и анализирует ответ.


 Протокол работы пользователя при смене секрета на сервере:
 1. Пользователь посылает запрос General Message (5.3.19.1.  CA Protocol Encryption Certificate),
    и получает в ответ сертификат сервера CMP с ключом шифрования.
 2. Шифрует новый секрет с использованием полученного сертификата CMP
    (формат PKCS#7/CMS EnvelopedData).
 3. Формирует CMP запрос на смену секрета (5.3.19.9.  Revocation Passphrase) и вкладывает 
    в него зашифрованные данные.
 4. Сформированный запрос посылает на сервер CMP.
 5. Сервер получает, проверяет и анализирует запрос.
 6. Меняет текущий секрет пользователя в базе секретов на новый.
 7. Пользователь получает, проверяет и анализирует ответ сервера.





 Работа с базой транзакций.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~

 1. Пользователь/администратор присылает CMP-запрос.

 1.1. Сервер получает, проверяет и анализирует запрос.

 1.2. Если ошибка - отправляет в ответ error.



 2. Если пользователь прислал ir/cr/kur/ccr запрос:

 2.1. Если транзакция с указанным transactionID существует, она удаляется.

 2.2. Если запрос должен быть отложен по времени, он сохраняется
   в базе транзакций в формате ir/cr/kur/ccr body со статусом PKI_TRANS_STATE_WAIT_TIME,
   пользователю возвращается дегенеративный ip/cp/kup/ccp соответственно с указанием
   статуса PKISTATUS_INFO_WAITING по каждому запрошенному сертификату.

 2.3. Запрос обрабатывается в УЦ без публикации результата в хранилище.

 2.4. Если служба УЦ в данный момент недоступна, запрос сохраняется
   в базе транзакций в формате ir/cr/kur/ccr body со статусом PKI_TRANS_STATE_ACCEPT,
   пользователю возвращается дегенеративный ip/cp/kup/ccp соответственно с указанием
   статуса PKISTATUS_INFO_WAITING по каждому запрошенному сертификату.

 2.5. Если в соответствии с политикой запрос дожен быть подтвержден администратором, он сохраняется
   в базе транзакций в формате ip/cp/kup/ccp body со статусом PKI_TRANS_STATE_WAIT_ADMIN,
   пользователю возвращается дегенеративный ip/cp/kup/ccp соответственно с указанием
   статуса PKISTATUS_INFO_WAITING по каждому запрошенному сертификату.

 2.6. Если запрос имеет ImplicitConfirm, сертификаты публикуются в хранилище сертификатов,
   результат отправляется пользователю в формате ip/cp/kup/ccp.

 2.7. Запрос сохраняется в базе транзакций со статусом PKI_TRANS_STATE_WAIT_USER.



 3. Если пользователь прислал pollReq запрос:

 3.1. Если транзакция с указанным transactionID не найдена, отправляет в ответ error.

 3.2. Если транзакция имеет статус PKI_TRANS_STATE_WAIT_USER,
   пользователю возвращается ip/cp/kup/ccp ответ с содержимым транзакции.

 3.3. Если транзакция имеет статус PKI_TRANS_STATE_ACCEPT:

 3.3.1. Запрос обрабатывается в УЦ без публикации результата в хранилище.

 3.3.2. Если служба УЦ в данный момент недоступна,
   пользователю возвращается pollRep.

 3.3.3. Если в соответствии с политикой запрос дожен быть подтвержден администратором,
   он сохраняется в базе транзакций в формате ip/cp/kup/ccp body со статусом PKI_TRANS_STATE_WAIT_ADMIN,
   пользователю возвращается pollRep.

 3.4. Если транзакция имеет другой статус,
   пользователю возвращается pollRep.



 4. Если пользователь прислал certConf запрос:

 4.1. Если транзакция с указанным transactionID не найдена, отправляет в ответ error.

 4.2. Если транзакция имеет статус отличный от PKI_TRANS_STATE_WAIT_USER, отправляет в ответ error.

 4.3. Сертификаты указанные в запросе certConf, подтвержденные пользователем,
   публикуются в хранилище сертификатов, пользователю возвращается pkiconf.


---------------------------------------------------
 RFC 4210 / CMP

 5.3.19.  PKI General Message Content
 5.3.19.16.  База данных транзакций.

   TransInfo ::= SEQUENCE {
       version     Version DEFAULT v1,
       transactionID OCTET STRING,
       type        [0]  IMPLICIT INTEGER OPTIONAL,
       state       [1]  IMPLICIT INTEGER OPTIONAL,
       dn          [2]  IMPLICIT UTF8String OPTIONAL,
       notBefore   [3]  IMPLICIT GeneralizedTime OPTIONAL,
       notAfter    [4]  IMPLICIT GeneralizedTime OPTIONAL
   }

   Version  ::=  ENUMERATED  {  v1(0), v2(1), v3(2)  }

   TransInfos ::= SEQUENCE OF TransInfo
 
 Запрос на получение списка транзакций:
      GenMsg:    {id-it 50.10}, TransInfo | < absent >
      GenRep:    {id-it 50.10}, TransInfos

 1. Если стуктура TransInfo в запросе отсутствует, то сервер
    выдает информацию по всем транзакциям базы траезакций.
 2. Если стуктура TransInfo в запросе присутствует, то поле
    transactionID игнорируется.


5.3.22.  Polling Request and Response

...
   5.  Если структура PollReqContent не содержит ни одного certReqId,
       сервер выдает информацию по всем certReqId этой транзакции.

---------------------------------------------------


 5. Если администратор прислал General Message с запросом на получение списка транзакций:

 5.1. Если нет полномочий RA, отправляет в ответ error.

 5.2. Возвращает ответ General Message со списком транзакций.



 6. Если администратор прислал pollReq запрос:

 6.1. Если транзакция с указанным transactionID не найдена, отправляет в ответ error.

 6.2. Если транзакция имеет статус PKI_TRANS_STATE_WAIT_USER,
   выполняются действия описанные в п. 3.

 6.3. Если транзакция имеет статус PKI_TRANS_STATE_WAIT_ADMIN,
   администратору возвращается ip/cp/kup/ccp ответ с содержимым транзакции.

 6.4. Если транзакция имеет другой статус, отправляет в ответ error.



 7. Если администратор прислал certConf запрос:

 7.1. Если транзакция с указанным transactionID не найдена, отправляет в ответ error.

 7.2. Если транзакция имеет статус PKI_TRANS_STATE_WAIT_USER,
   выполняются действия описанные в п. 4.

 7.3. Если транзакция имеет статус PKI_TRANS_STATE_WAIT_ADMIN,
   из содержимого транзакции удаляются сертификаты, не подтвержденные
   администратором, модифицированная транзакция записывается в
   базу транзакций со статусом PKI_TRANS_STATE_WAIT_USER,
   администратору возвращается pkiconf.

 7.4. Если транзакция имеет другой статус, отправляет в ответ error.


---------------------------------------------------

 RFC 4210 / CMP

 5.3.19.  PKI General Message Content
 5.3.19.17.  Отчет работы УЦ по выпуску/отзыву сертификатов за указанную дату.

   OperListCA  ::=  SEQUENCE OF OperInfoCA

   OperInfoCA  ::=  SEQUENCE  {
        operType        OperType,           // тип операции выпуск/отзыв/обновление
        operTime        UTCTime,            // время проведения операции
        service         OBJECT IDENTIFIER,  // OID службы выполнившей операцию
        serialNumber    OCTET STRING,       // серийный номер сертификата
        subject         Name,               // DN-имя владельца сертификата
        notBefore       UTCTime,            // валидность сертификата (с)
        notAfter        UTCTime,            // валидность сертификата (по)
        keyUsage        INTEGER,            // использование ключа
        keyOID          OBJECT IDENTIFIER,  // OID ключа
        policyList      PolicyList,         // список политик сертификата
        reason          INTEGER OPTIONAL}   // причина отзыва (только для операции revocation)
 
   OperType ::= ENUMERATED {
        issuing             (0),
        revocation          (1),
        updating            (2) }
 
   PolicyList ::= SEQUENCE OF OBJECT IDENTIFIER

   Period ::= SEQUENCE {
        dateFrom GeneralizedTime,
        dateTo   GeneralizedTime OPTIONAL } // пока не реализовано


 Запрос на получение Отчета работы УЦ за указанную дату:
      GenMsg:    {id-it 50.11}, Period
      GenRep:    {id-it 50.11}, OperListCA

P.S.

 1. Хранение в LDAP каталоге типа 'B'.
 2. Узлы: dc=DD;dc=MM;dc=YY;dc=CA,
    где YY-год, MM-месяц, DD-день.
 3. Атрибут хранения записи операции: "transBody"

---------------------------------------------------

 RFC 4210 / CMP

 5.3.19.  PKI General Message Content
 5.3.19.18.  Работа с персональными данными пользователей.


 Запрос на добавление персональных данных пользователя:
      GenMsg:    {id-it 50.14}, EnvelopedData(UserDataList)
      GenRep:    {id-it 50.14}, < absent >

 Запрос на изменение персональных данных пользователя:
      GenMsg:    {id-it 50.15}, EnvelopedData(UserDataList)
      GenRep:    {id-it 50.15}, < absent >

 Запрос на получение персональных данных пользователя:
      GenMsg:    {id-it 50.16}, UserAttrList
      GenRep:    {id-it 50.16}, EnvelopedData(UserDataList)


   UserAttrList ::= SEQUENCE {
        user    UserName,
        attr    AttributeDescriptionList }

   UserDataList ::= SEQUENCE {
        user    UserName,
        data    AttributeTypeAndValuesList }


   UserName ::= CHOICE {
        object       [0] IMPLICIT LDAPDN,
        userKID      [1] IMPLICIT KeyIdentifier }

   AttributeDescriptionList ::= SEQUENCE OF
        AttributeDescription

   AttributeDescription ::= LDAPString

   LDAPString ::= OCTET STRING

   LDAPDN ::= LDAPString

   AttributeTypeAndValuesList ::= SEQUENCE OF
        AttributeTypeAndValues

   AttributeTypeAndValues ::= SEQUENCE {
        type    AttributeDescription,
        vals    SET OF AttributeValue }

   AttributeValue ::= OCTET STRING

   KeyIdentifier ::= OCTET STRING

---------------------------------------------------

