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


Таблица Шаблон регистрационной формы MCA и PCA - часть 3


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 центру СА

<


Начало  Назад  Вперед