Интегрированные сети ISDN

         

Структура сообщения CardCInitReq



Таблица 4.6.2.17. Структура сообщения CardCInitReq



CardCInitReq

{RRPID, LID-EE, Chall-EE, BrandID, [Thumbs]}

RRPID

Идентификатор пары запрос/отклик

LID-EE

Локальный ID, сформированный для системы владельца карты

Chall-EE

Вызов владельца карты по поводу пригодности подписи, адресованный ССА

BrandID

Идентификатор платежной системы для запрошенного сертификата

Thumbs

Список оттисков сертификатов (включая корневой), CRL и BrandCRLIdentifier, которые хранятся в данный момент владельцем карты

ССА, получив CardCInitReq, выполнит следующие операции:

Шаг Действие
1 Получить CardCInitReq из сообщения Receive
2 Проверить, что RRPID в CardCInitReq соответствует RRPID в цифровом конверте сообщения. Если проверка не прошла, присылается сообщение об ошибке с кодом ErrorCode= unknownRRPID
3 Запомнить список откликов, LID-EE, Chall-EE и RRPID, которые должны быть использованы в CardCInitRes

После того как ССА обработает CardCInitReq, он выполнит следующие шаги, для того чтобы сформировать CardCInitRes. Как и в случае SignedData, сертификаты и CRL, нужные для верификации подписи, включаются в CardCInitRes вне данных, которые должны быть подписаны. Последовательность действий представлена ниже в таблице.

Шаг Действие
1 Сформировать структуру данных CardCInitResTBS, для этого:

  • Скопировать RRPID, LID-EE и Chall-EE, полученные из сообщения CardCInitReq
  • Сформировать опционно LID-CA
  • Заполнить CAEThumb оттиском сертификата шифрования данных CCA
  • Если BrandCRLIdentifier не специфицирован в списке оттисков, полученном в CardCInitReq, занести BrandCRLIdentifier
  • Скопировать список оттисков из CardCInitReq

  • 2 Подписать DER-кодированный массив кодов CardCInitResTBS, установить тип содержимого SigneadData равным id-set-content- CardCInitResTBS.

    Включить в SigneadData любые сертификаты, CRL или BrandCRLIdentifier, которые отсутствуют в списке оттисков.

    3 Сформировать цифровой конверт сообщения и послать сообщение CardCInitRes владельцу карты
    <
    Последовательность формирования и посылки RegFormReq представлена ниже в таблице.

    Шаг Действие
    1 Сформировать RegFormReqData согласно следующему формату:
  • Сформировать новый RRPID

  • Скопировать LID-EE, посланный в CardCInitReq

  • Сформировать новый Chall-EE2

  • Если такой элемент был включен в CardCInitRes, скопировать LID-CA

  • Заполнить RequestType согласно таблице 4.6.2.19, где представлены коды поля RequestType регистрационной формы владельца карты

  • Заполнить поле языка (Language)

  • Опционно ввести список оттисков для каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентных для кэша оттисков владельца карты (если таковой имеется).
  • 2 Сформировать структуру RegFormReqTBE:
  • Ввести ReqFormReqData

  • Заполнить поле PANOnly, используя PAN и ExNonce. В PAN не используется заполнитель.

  • Сформировать хэш SHA-1 для DER-кодированного PANOnly. Установить код типа содержимого digestedData равным id-set-content-PANOnly
  • 3 Оформить поле данных, подлежащих дополнительному шифрованию:
  • Заполнить PAN. Если PAN имеет длину менее 19 байт, дополнить его до 19 байт

  • Для маскирования PAN сгенерировать новый EXNonce
  • 4 Зашифровать данные, используя оператор EXH со следующими параметрами:
  • RegFormReqTBE в качестве данных, подлежащих шифрованию, и типом contentType данных Envelopeddata равным id-set-content-RegFormReqTBE и

  • Результатом шага 3 в качестве данных, подлежащих шифрованию

  • Для шифрования используется сертификат идентифицированный CAEThumb в CardCInitRes
    5 Вложить результат в цифровой конверт комбинированного сообщения и послать RegFormReq в центр СА

    Структура сообщения RegFormReq представлена в таблице 4.6.2.18.

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