Телекоммуникационные технологии

         

AqCInitRes указывает, нужно ли AcctInfo


Me- AqCInitRes указывает, нужно ли AcctInfo в AcctInfoField. EncX используется лишь при наличии AcctInfo.

Если ЕЕ является владельцем карты, продавцом или расчетным центром и намерен послать AcctInfo, то CertReq формируется с привлечением методики EncX следующим образом.

Шаг Действие
1 Если RequestType соответствует новому сертификату подписи или его обновлению, формируется пара ключей (общедоступный/секретный), необходимых для подписи сертификата
2 Если запрашивающим субъектом не является владелец карты и, если RequestType соответствует новому сертификату шифрования, формируется пара ключей (общедоступный/секретный), необходимых для сертификата шифрования.
3 Если ЕЕ является владельцем карты, генерируется 160-битовый случайный код - CardSecret.
4 Генерируется 160-битовый случайный код - EXNonce
5 Формируется CertReqTBS:

  • Генерируется RRPID


  • Если ЕЕ получил RegFormRes или Me-AqCInitRes, копируется RequestType из этого сообщения, в противном случае вводится требуемый RequestType.


  • Заполняется поле RequestData


  • Копируется LID-EE (если присутствует) и Chall-CA из предыдущего сообщения. Если его нет, генерируется новый.


  • Генерируется новый Chall-EE3


  • Копируется LID-CA, (если присутствует) и Chall-CA из предыдущего сообщения.


  • Если ЕЕ является продавец карты или расчетный центр, то:


    1. заполняется поле IDData и,


    2. если в Me-AqCInitRes включено поле AcctDataField, записывается AccData, введенная ЕЕ


    • Если ЕЕ является продавец, занести PAN, CardExpiry и CardSecret.


    • Сформировать EXNonce


    • Скопировать RegForm ID, который был послан в RegFormRes или Me-AqCInitRes


    • Если RegFieldSeq присутствовал в Me-AqCInitRes или RegFormRes, включить новую или исправленную форму.


    6
    • Если приложение владельца карты выберет алгоритм шифрования CertRes, производится заполнение ID алгоритма и ключа в CaBackKeyData. Если общего алгоритма не найдено, процесс прерывается, о чем уведомляется пользователь.


    • Заносится вновь сформированный общедоступный ключ, PublicKeyS и/или PublicKeyE, предназначенный для сертификации СА.


    • Если ЕЕ является продавец или расчетный центр, а тип запроса соответствует обновлению сертификата шифрования, заполняется EEThumb с оттиском сертификата, подлежащего обновлению. Если тип запроса соответствует обновлению сертификата подписи, оттиск сертификата подписи не требуется, так как CertReq подписан им.


    • Опционно включается список, который содержит оттиски для каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентно размещенных в кэше.


    7 Данные, подлежащие дополнительному шифрованию, имеют следующий формат. Если ЕЕ является продавец карты, заполняется PAN, CardExpiry, CardSecretCardNonce и EXNonce в PANData0.

    Если ЕЕ является продавец или расчетный центр, опционно заполняется AccTData и EXNonce.
    8 Данные укладываются в конверт с использованием техники EncX:

    Включить:

    Обработка

    а. В качестве подписанных данных CertReqTBS

    То, как данные подписываются зависит от RequestType. Имеется как минимум одна и допускаются две подписи, т.е. SignerInfo для CertReq.

    Если тип запроса относится к новому сертификату подписи, подписать данные, используя секретный ключ, соответствующий общедоступному ключу, содержащемуcя в PublicKeyS.

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

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

    Если данные подписаны секретным ключом, который не соответствует сертификату, установить SignerInfo.SerialNumber равным нулю, а SignerInfo.IssuerName=”Null-DN”, т.е. RDNSequence равна кодированному NULL.

    Тип содержимого SignedData устанавливается равным id-set-content-CertReqTBS.

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

    Провести дополнительное шифрование, используя СА-сертификат, указанный CAEThumb в CardCInitRes или RegFormRes, если один из них был включен, или Me-AqCInitRes

    c. CertReqTBEX в качестве данных, подлежащих шифрованию

    Зашифровать CertReqTBEX и установить тип содержимого EnvelopedData равным id-set-content-CertReqTBEX
    9 Сформировать цифровой конверт и послать сообщение CertReq центру СА
    <

    Содержание  Назад  Вперед