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

Шаблон регистрационной формы MCA и PCA



Таблица 4.6.2.25. Шаблон регистрационной формы MCA и PCA



Me-AqCInitRes

 S(CA, Me-AqCInitResTBS)

Me-AqCInitResTBS

 {RRPID, LID-EE, Chall-EE, [LID-CA], Chall-CA, RequestType, RegFormOrReferral, [AcctDataField], [Thumbs]}

RRPID

 ID пары запрос/отклик

LID-EE

 Копируется из Me-AqCInitReq

Chall-EE

 Копируется из Me-AqCInitReq

LID-CA

 Локальный ID; генерируется СА системой или для нее

Chall-CA

 СА обращение по поводу пригодности сертификата запрашивающей стороны

RequestType

 Смотри табл. 4.6.2.24

RegFormOrReferral

 Смотри табл. 4.6.2.21

AcctDataField

RegField; дополнительное поле регистрационной формы, которое следует отобразить, для того чтобы получить значение AcctData в CertReq

CAEThumb

 Оттиск сертификата ключевого обмена СА, который должен использоваться для шифрования CertReq

BrandCRLIdentifier

 Смотри раздел описания BrandCRLIdentifier ниже.

Thumbs

 Копируется из Me-AqCInitReq

Приложение SET (продавца или расчетного центра) обрабатывает Me-AqCInitRes

следующим образом:

Шаг Действие
1 Получить Me-AqCInitRes из входного сообщения.
2 Верифицировать подпись. Если она некорректна, послать сообщение об ошибке с ErrorCode равным signatureFailure.
3 Из Me-AqCInitResTBS извлекаются и запоминаются RRPID, LID-EE, Chall-EE, CAEThumb, BrandCRLIdentifier, оттиски и TequestType
4 Проверяется, что RRPID совпадает со значением, извлеченным из цифрового конверта сообщения и кодом, посланным в Me-AqCInitReq. Если равенства нет, посылается сообщение об ошибке с ErrorCode равным unknownRRPID.
5 Проверяется, что полученный Chall-EE соответствует посланному в Me-AqCInitReq. Если соответствие отсутствует, посылается сообщение об ошибке с ErrorCode равным challengeMisMatch.
6 Проверяется, что полученный список оттисков соответствует посланному в сообщении Me-AqCInitReq. Если соответствие отсутствует, посылается сообщение об ошибке с ErrorCode равным thumbsMisMatch.
7 Если в Me-AqCInitResTBS включено поле RegFormData то:

  • Запомнить LID-CA и Chall-CA

  • Отобразить текст общих требований и ввод пользователя, прежде чем приложение SET сформирует CertReq

  • Отобразить видимые поля регистрационной формы и приглашение пользователю для заполнения этих полей

  • Если Me-AqCInitResTBS содержит URL, отобразить логотипы расчетной системы и/или карты

  • Если присутствует поле AcctDataField, отобразить имя и описание, а также приглашение пользователю для заполнения этого поля

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

    		•
    8 После того как продавец или расчетный центр заполнили регистрационную форму и ввели AcctData, (если это требуется) генерируется CertReq.
    9 Если в Me-AqCInitResTBS включено поле ReferrelData, то:

  • Отображается причина

  • Если включено поле ReferralLoc, отображается URL или электронный адрес из ReferralLoc

  • CertReq не генерируется. Протокол продолжит работу с посылки Me-AqCInitReq

    		•
    <
    Владелец карты, системный администратор продавца или расчетного центра вводит информацию, необходимую для RegForm, а приложение SET (EE) посылает сообщение CertReq центру СА. После успешной верификации CertReq формируются сертификаты, которые посылаются ЕЕ в сообщениях CertRes. Если в регистрационной форме обнаружены ошибки, СА оповещает об этом в CertRes. Приложение SET может повторно представить исправленную регистрационную форму в новом CertReq.
    Владелец карты вводит ее номер, дату пригодности и другие данные, запрошенные ССА в регистрационной форме.
    Системный администратор продавца вводит аутентификационные данные расчетного центра и другую информацию, запрошенную МСА в регистрационной форме.
    Системный администратор расчетного центра вводит аутентификационные данные продавца (если таковые имеются) и другую информацию, запрошенную РСА в регистрационной форме.
    Запрос сертификата (CertReq) содержит в себе:
  • Новые общедоступные ключи.

  • Обновляемые сертификаты (если таковые есть).

  • Заполненную регистрационную форму.

  • Информацию об аккоунте ЕЕ

  • Секретные ключи, которые должен использовать СА для шифрования отклика CertRes,

  • Другие контрольные коды

    • Поле данных сообщения и опционно хэш аккоунт-данных ЕЕ подписываются секретным ключом, соответствующим сертификату подписи, подлежащему обновлению (если таковой имеется) и новым секретным ключом. Симметричный ключ, используемый для этого шифрования, берется из OAEP (Bellare-Rogaway Optimal Asymmetric Encryption Padding). Все перечисленные данные шифруются с использованием общедоступного ключа.
    Если СА обнаружит ошибку в представленной регистрационной форме, информация о ней будет передана в сообщении CertRes и будет послан новый запрос CertReq.
    ЕЕ-приложение генерирует CertReq следующим образом. Это делается с использованием EncX или Enc техники в зависимости от присутствия AcctInfo. Если ЕЕ является владельцем карты, 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 из предыдущего сообщения.

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

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

  • если в 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 центру СА
    <


    Если приложением ЕЕ является продавец или расчетный цент, который не имеет данных AcctData (в AcctInfo), чтобы их послать, тогда генерируется CertReq с привлечением техники Enc:

    Шаг Действие
    1 Если RequestType соответствует обновлению сертификата подписи, формируется пара ключей (секретный/общедоступный) для сертификата подписи
    2 Если RequestType соответствует новому или обновляемому сертификату шифрования, формируется пара ключей (секретный/общедоступный) для сертификата шифрования
    3 Сгенерируется 160-битное случайное число - EXNonce
    4 Данные CertReqData формируются следующим образом:
  • Генерируется RRPID

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

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

  • Копируется LID-EE из предыдущего сообщения. Если такового нет, генерируется новое.

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

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

  • Заполнить поле IDData

  • Занести RegFormID, полученный из Me-AqCInitRes

  • Занести новую или скорректированную форму RegForm

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

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

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

    Включить:

    Обработка

  • CertReqData в качестве информации, подлежащей подписыванию.

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

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

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

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

    Если данные подписаны ключом, который еще не соответствует сертификату, следует установить Signer.Info.SerialNumber равным “Null-DN”. Тип содержимого SignedData делается равным id-set-content-CertReqData.

    Производится DER-кодирование полученной информации SignedData с целью получения CertReqTBE.
  • Ключ DES в качестве данных, подлежащих дополнительному шифрованию

    • Для Enc-обработки единственной информацией, которая должна быть зашифрована, является симметричный ключ, используемый для шифрования “обычных данных”. Шифруется ключ с применением сертификата, указанного посредством CAEThumb в Mt-AqCInitRes.

  • CertReqTBE в качестве обычных данных, подлежащих шифрованию

    • Шифруется CertReqTBE и устанавливается ContentType равным id-set-Content-CertReqTBE.
     
    6 Подготовить цифровой конверт и послать CertReq центру СА

    Формат сообщения CertReq, генерируемого EE (End Entity) представлен ниже в таблице 4.6.2.26:

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