Construction order of ESig key, ESig verification key, ESig verification key certificates and their use and transfers
ESig key, ESig verification key and corresponding certificate of ESig verification key are created by ESig means of the parties or purchased from third-party organizations.
Used certificates and Revoked Certificate Lists must comply with the format X.509v3 described in IETF RFC 5280 specification.
Certificate settings should be as follows:
the signature algorithm — RSA;
the key length — 2048 bits.
the hash algorithm — sha1;
validity period — 1 year.
In the “subject” field of the certificate, the following information must be provided:
CN = Full name of the officer, or organization name, or an alias;
E = the email address corresponding to the email address used to send ED;
OU = organizational unit name;
O = organization name;
L = the city where the organization is located;
C = country code (for example, for Russia, C = RU).
The remaining fields of the certificate can be completed as desired.
The certificates that are used to generate the EESig must have the attributes of enhanced key usage id_kp_clientAuth (OID 1.3.6.1.5.5.7.3.2) and id_kp_emailProtection (OID 1.3.6.1.5.5.7.3.4).
The certificates must have a record with information about the distribution points of revoked certificate list accessible via HTTP on the Internet.
Certificate authority must add to RCL the certificates revoked within 1 business day and must publish new RCL online following each such modification.
Certificate authority that is used to issue certificates must satisfy all the requirements for non-accredited certificate centers established by Federal Law #63-FZ "On Electronic Signatures”.
The Parties shall exchange the following certificates:
CA root certificate (if available);
intermediate certificates (if available);
the certificate that will be used to sign the ED in the System.
Certificate file must be in PKCS7 format.
Certificate files are transferred to the other Party via email or via the System, if it is already running.
The root certificate, or, in its absence, the self-signed certificate, is printed by the parties on paper, signed by the responsible person with the seal of the organization affixed and sent to the other party by courier or given to one another at the time of signing of this Agreement.
The Parties undertake to adopt all necessary measures to preserve the confidentiality of ESig keys.
With the help of ESig means and for each received SED, the System shall verify:
the authenticity of the ESig for the SED;
the fact that the date of ESig generation is within the interval from date of commencement of validity of the certificate up to its expiration date;
the correctness of the certificate that is used to generate the ESig;
the correctness of the certificate issuance chain starting from the one used for the signature and ending with the root;
compliance with the restrictions of certificate use, recorded in the certificate itself;
the absence of the used certificate in the list of revoked certificates of the party that issued this certificate.
During the planned replacement of ESig verification key certificate, party generates new keys and the corresponding certificate, and sends the certificate file to the other party via email or through the System.
In case of compromised ESig keys (or justified suspicions of compromise) that is used to generate EESig in the SED, a party must:
stop the transfer of SED in the System and immediately (if not possible, then within 1 business day) notify the other party about the compromise of the certificate;
generate a new ESig key, ESig verification key and release to the CA the new ESig verification key certificate;
transfer to the other Party the file with the new certificate;
add to their CA list of revoked certificates the serial number of the compromised certificate and publish the new RCL;
restore the System as agreed upon with the other party.
When the root and (or) intermediate ESig key of the certificate center is compromised, a Party performs the actions specified in the previous clause, as well as other actions in accordance with its regulations.
The signing of this Agreement is the evidence of the certificate exchange.
Resolution of Disputes Related to ED Verification.
Any disputes between the parties, the subject of which is the authentication verification, i.e. verification of text integrity and authenticity of the sender of the ED, are forwarded for resolution to the especially created Expert Committee.
Expert Committee shall be convened on the basis of a written application (claim) from any of the Parties. In the application, the party shall specify details of the contested SED and the persons authorized to represent the party on the Expert Committee.
No later than 10 business days from the moment of receipt by the other party of the application (claim), the parties shall set the date, location and time for the beginning of work of the Expert Committee, and shall determine which party will provide the personal computer and will configure the ESig means.
Powers of the members of the Expert Committee are confirmed by proxies.
Membership of the Expert Commission is formed in equal proportions from the representatives of the parties.
Examination of the contested ED is carried out in the presence of all the members of the Expert Committee.
Examination is carried out in four phases:
step 1: the parties jointly establish, configure and test ESig means.
step 2: parties provide their copy of the ESig verification key certificate, used to create the EESig of the contested SED, as well as the root and intermediate CA certificates.
step 3: The Expert Committee, with the help of ESig means, receives ESig verification keys from the certificates provided by the parties, and compares them with the corresponding keys from the certificates sent to the Parties on the basis of clause 8.11 of this Agreement. Certificates, which ESig verification keys matched, are recognized as authentic. The root certificate submitted in paper prior to the signing of the Agreement is also compared with the provided certificate. The Expert Committee, with the help of ESig means, verifies whether the ESig verification key certificate used to sign the contested SED was released using the root and intermediate ESig key of the CA.
step 4: verification of correctness of ESig under the contested document, provided by the receiving party, is verified against the certificate of the receiving party, the authenticity of which was confirmed as mentioned above.
The authenticity of the contested SED is confirmed by simultaneous presence of the following conditions:
ESig authentication verification test gave a positive result;
Ownership of the ESig verification key certificate used to verify the authenticity of the ESig in the contested ED is confirmed;
ED is generated in the System and is transmitted for processing in accordance with the provisions of this Agreement.
Results of the examination shall be drawn in the form of a written report - Act of the Expert Committee, signed by all the members of the Expert Committee. The Act shall be drawn up immediately after the completion of the third phase of the examination. The Act records the results of all stages of the conducted examination, as well as all the essential requisites of the contested SED. The Act is drawn up in two copies, one for each of the parties. The Act of the Committee is final and not subject to revision.
Confirmation of the authenticity of ESig in the contested SED recorded in the Act will mean that the SED has legal effect and entails the rights and obligations for the parties established in the Main Contract and Agreement. Failure to confirm the authenticity of ESig in the contested SED, recorded in the Act will mean that the SED has no legal effect and shall not entail any rights or obligations for the parties established in the Main Contract and Agreement.
The Parties recognize that the Act drawn up by the Expert Committee shall be binding for the parties and can serve as evidence in further litigation in arbitration court.
In case of disagreement on contentious issues and absence of voluntary enforcement of the decision of the Expert Committee, all materials on these matters may be referred to the Arbitration Court of Moscow.
Authorized persons to use the ESig on behalf of the Parties are: from the Operator — Chairman of the Board, Tatyana Andreevna Shabanova, from the Counterparty — the person who signed the Application on behalf of the Counterparty.
ПРИЛОЖЕНИЕ № 2 / Annex #2
ТЕХНИЧЕСКАЯ АНКЕТА / TECHNICAL FORM
Параметр/Setting
|
Значение/Value
|
Название контрагента / Counterparty
|
|
Адрес сайта/ website URL
|
|
Описание реализуемых услуг / Description of Servises
|
|
Для реала/For production mode
|
paymentAvisoURL*1
|
https://
|
checkURL*1
|
https://
|
Порядок перенаправления пользователя по завершении платежа / Redirection type
(выбрать вариант) / Please select one option
|
Статические адреса магазина. Для каждого «товара» могут быть свои значения. / Static URLs, Different values for each “Article” allowed
Товар / Article
|
successURL*1
|
failURL*1
|
|
|
|
|
На адреса, задаваемые магазином в платежной форме / Dynamic URLs, specified in Counterparty’s
|
Для тестирования/For tasting mode
|
paymentAvisoURL*1
|
https://
|
checkURL*1
|
https://
|
Порядок перенаправления пользователя по завершении платежа / Redirection type
(выбрать вариант) / Please select one option
|
Статические адреса магазина. Для каждого «товара» могут быть свои значения. / Static URLs, Different values for each “Article” allowed
Товар / Article
|
successURL*1
|
failURL*1
|
|
|
|
|
|
|
|
На адреса, задаваемые магазином в платежной форме / Dynamic URLs, specified in Counterparty’s payment form
|
Параметр
|
Возможные значения
|
Место размещения платежной формы
(выбрать одно значение) / Please select one option
|
Сайт Оператора / Operators site
|
Сайт Контрагента / Counterpartys site
|
Формат сообщений/ Message format
|
NVP/MD5
|
shopPassword
|
|
Кодировка символов/ Character encodin
|
UTF-8
|
Отображение текста отказа в приеме платежа на витрине/ Payment refusal reason text message displayed to Buyer
(выбрать одно значение) / Please select one option
|
Нужно / True
|
Не нужно / Faulse
|
Время учета платежей / Payment accounting time
|
По часам «Яндекс.Деньги» / Yandex.Money
|
Учет платежей при недоставке уведомления об оплате/ Payments accounting in case of non-delivery of payment notification
(выбрать одно значение) / Please select one option
|
Считать неуспешным / Consider failed
|
Считать успешным/ Consider successful *2
|
Уведомлять о недоступности
(выбрать одно значение) / Please select one option
|
Да/Yes
|
Нет/No
|
Email для реестров / Email for daily registers
|
|
Email для уведомлений о недоступности / Email for payment failure notifications
|
|
paymentAvisoURL — URL, на который отправляется запрос «Уведомление об оплате».
successURL — URL, на который делается редирект браузера клиента после успешной оплаты.
failURL — URL, на который делается редирект браузера клиента после неуспешной оплаты.
checkURL — URL, на который отправляется запрос «Проверка заказа (платежа)».
NVP/MD5 — данные передаются посредством вызова по протоколу HTTP/1.1, методом POST. Данные платежа упаковываются как набор параметров POST-запроса в виде пар «имя=значение». Один из параметров (md5) содержит хеш данных платежной формы вместе с секретным словом (=shopPassword).
shopPassword — секретный пароль (20 случайных символов), который используется при расчете криптографического хеша.
Отображение текста отказа в приеме платежа на витрине — возможность передачи магазином собственного текста для отображения пользователю в ответе на операцию проверки возможности платежа.
Учет платежей при недоставке уведомления об оплате — взаимное поведение магазина и Яндекс.Денег при невозможности доставки «Уведомления об оплате»:
Считать неуспешным. Яндекс.Деньги прекращают попытки доставки уведомления, помечают платеж как недоставленный в магазин. Сумма платежа возвращается покупателю автоматически.
|
paymentAvisoURL for sending payment notification request.
successURL for browser redirect after a successful payment.
failURL browser redirect after a failed payment attempt.
checkURL for sending payment check request. URL must be no longer than 200 characters
NVP/MD5. Data is transferred via HTTP/1.1 POST method. Payment details are stored as name=value pair POST parameters. One of the parameters (md5) contains payment form data hash along with shopPassword.
shopPassword is a private password (20 random characters) used to calculate the cryptographic hash.
Payment refusal reason text message can be specified to display to User in response to payment check request.
Payment accounting in case of non-delivery of payment notification for Yandex.Money to Counterparty interaction in case of non-delivery of payment notification:
Consider failed. Yandex.Money cease attempts to deliver notification, mark payment as undelivered to Merchant. Funds are automatically returned to User.
Consider successful. Yandex.Money cease attempts to deliver notification, mark payment as successful. Merchant may discover “undelivered notifications” by checking against payment register, or using Merchant Web Services.
Value allowed only if Yandex.Money time is selected for payment accounting.
|
ПРИЛОЖЕНИЕ № 3 / Annex #3
Форма акта о подключении / FORM OF THE ACT ON CONNECTION
Акт о подключении
к Договору об информационно-технологическом взаимодействии
при осуществлении переводов физических лиц без открытия счета
№ __от __
Act оf Connection
to Contract on information and technology interaction
throughout the implementation of transfers from individuals
without opening an account No__ dated __
г. Москва / Moscow
|
«_____»____________________20___
|
|
(заполняется Оператором Системы)
|
DRAFT
Общество с ограниченной ответственностью небанковская кредитная организация «Яндекс.Деньги», именуемое в дальнейшем «Оператор», в лице Председателя Правления Шабановой Т.А., действующей на основании Устава, с одной стороны, и
__________________ ______________________________, именуем___ в дальнейшем «Контрагент», в лице _________ ____________________________________, действующ__ на основании ______________________, с другой стороны, совместно именуемые «Стороны»,
составили настоящий акт о том, что Контрагент завершил тестирование (shopId=____) и подключен к Системе ЭДО в рабочем режиме.
|
______________, hereinafter referred to as “Counterparty” registered at ______________, represented by ______________ acting upon the ______________ on the one part, and
Limited Liability Company Non-bank Credit Organization "Yandex.Money", hereinafter referred to as “Operator” represented by ______________ acting upon ______________, on the other part,
have created the present Act on completion of testing by Counterparty (shopId=____) and connection to the System of EMF in production mode.
|
От Оператора: / On behalf of the Operator:
М.П./ Company Seal Here
ФИО/ Name
|
От Контрагента: / On behalf of the Counterparty:
М.П./ Company Seal Here
ФИО/ Name
|
| |
