Права Сторон
Стороны имеют право:
Ограничивать и приостанавливать использование Системы в случаях ненадлежащего исполнения другой стороной Соглашения, с уведомлением не позднее дня приостановления, а по требованию компетентных государственных органов в случаях и в порядке, предусмотренных законодательством Российской Федерации.
Производить замену программно-аппаратного обеспечения Системы с предварительным уведомлением не менее чем за два рабочих дня другой стороны.
Остановить работу Системы по техническим причинам, до восстановления ее работоспособности.
Производить плановую и внеплановую замену ключа ЭП, ключа проверки ЭП и сертификата ключа проверки ЭП по своей инициативе с уведомлением другой стороны не менее чем за два рабочих дня.
Ответственность сторон и риски убытков
Стороны несут ответственность за содержание любого ПЭД, при условии подтверждения подлинности ЭП.
Стороны несут ответственность за конфиденциальность и порядок использования ключей ЭП.
Сторона, допустившая компрометацию ключа ЭП, несет ответственность за ЭД, подписанные с использованием скомпрометированного ключа ЭП, до момента официального уведомления об аннулировании (отзыве) соответствующего сертификата и конкретных документов, подписанных указанным ключом.
Сторона, несвоевременно сообщившая о случаях утраты или компрометации ключа ЭП, несет связанные с этим риски.
В случае возникновения убытков, сторона, не исполнившая (ненадлежащим образом исполнившая) обязательства по Соглашению, несет ответственность перед другой стороной за возникшие убытки. При отсутствии доказательств неисполнения (ненадлежащего исполнения) сторонами обязательств по Соглашению, риск убытков несет сторона, чьей ЭП подписан ЭД, исполнение которого повлекло за собой убытки.
Если в результате надлежащего исполнения ЭД возникает ущерб для третьих лиц, ответственность несет Сторона, от имени которой ЭД подписан ЭП.
Стороны освобождаются от ответственности за частичное или полное неисполнение своих обязательств по Соглашению, если таковое явилось следствием обстоятельств непреодолимой силы, возникших после вступления в силу Соглашения, в результате событий чрезвычайного характера, которые не могли быть предвидены и предотвращены разумными мерами. Сторона обязана незамедлительно известить другую сторону о возникновении и прекращении действия обстоятельств непреодолимой силы, препятствующих исполнению ей обязательств по Соглашению, при этом срок выполнения обязательств по Соглашению переносится соразмерно времени, в течение которого действовали такие обстоятельства.
В случае прекращения действия Соглашения по любому основанию стороны несут ответственность по обязательствам, возникшим до прекращения действия Соглашения, в соответствии с законодательством Российской Федерации.
Порядок создания ключа ЭП, ключа проверки ЭП, сертификатов ключей проверки ЭП и их использования и передачи
Стороны генерируют ключ ЭП и соответствующий ключ проверки ЭП. Стороны генерируют соответствующий сертификат ключа проверки ЭП в УЦ.
Используемые сертификаты и списки отозванных сертификатов должны соответствовать формату X.509v3, описанного в спецификации IETF RFC 5280.
Параметры сертификата должны быть следующие:
алгоритм подписи – RSA;
длина ключа – 2048 бит;
алгоритм хеширования – sha1;
срок действия – 1 год.
В поле «субъект» сертификата внести следующие сведения:
CN = ФИО ответственного сотрудника или наименование организации или псевдоним;
E = адрес электронной почты;
OU = Наименование подразделения организации;
O = Название организации;
L = Город размещения организации;
C = Код страны (например, для России C=RU).
Остальные поля сертификата могут быть заполнены по желанию.
Сертификаты, используемые для формирования НЭП, должны иметь атрибуты расширенного использования ключа id_kp_clientAuth (OID 1.3.6.1.5.5.7.3.2).
Сертификаты должны иметь запись с данными о точке распространения списка отозванных сертификатов, доступного по протоколу HTTP из сети Интернет.
Удостоверяющий центр должен добавлять в СОС отозванные сертификаты в течение 1 рабочего дня и опубликовывать новый СОС в Интернете после каждого обновления.
Удостоверяющий центр, который используется для выдачи сертификатов, должен соответствовать всем требованиям к неаккредитованным удостоверяющим центрам, установленными в ФЗ № 63-ФЗ «Об электронной подписи».
Стороны обмениваются следующими сертификатами:
корневой сертификат УЦ (если есть);
промежуточные сертификаты (если есть);
сертификат, который будет использоваться для подписи ЭД в Системе.
Файл сертификата должен быть в формате X.509 (Base64 или DER кодировка, расширение файла .cer) или PKCS#7 (расширение файла .p7b).
Файлы сертификатов передаются другой стороне по электронной почте или через Систему, если она уже функционирует.
Стороны печатают на бумажном носители файлы сертификатов, подписывают ответственным лицом с оттиском печати организации и отправляют другой стороне курьером или передают друг другу в момент подписанию данного Соглашения. Пример формы печати сертификата представлен в конце данного Приложения.
Стороны обязуются принимать все необходимые меры для сохранения конфиденциальности ключей ЭП.
Передающая Сторона подписывает электронный документ своим ключом ЭП, зашифровывает ПЭД ключом проверки ЭП из сертификата принимающей Стороны и отправляет зашифрованный ПЭД через систему.
Принимающая Сторона расшифровывает принятый документ своим ключом ЭП и проверяет ЭП с помощью ключа проверки ЭП из сертификата передающей Стороны.
Система средствами ЭП для каждого полученного ПЭД должна проверить:
подлинность ЭП для данного ПЭД;
факт того, что дата формирования ЭП находится в интервале от даты начала действия сертификата до даты завершения его действия;
корректность самого сертификата, используемого для формирования ЭП;
корректность цепочки выдачи сертификатов от используемого для подписи до корневого;
выполнение требований к ограничению использования сертификата, записанных в самом сертификате;
отсутствие используемого сертификата в списке отозванных сертификатов стороны, выдавшей этот сертификат.
При плановой замене сертификата ключа проверки ЭП сторона генерирует новые ключи и соответствующий сертификат и отправляет файл сертификата другой стороне по электронной почте или через Систему.
При компрометации ключа ЭП (или обоснованных подозрениях на это), используемого для формирования НЭП в ПЭД, сторона должна:
остановить передачу ПЭД в Системе и немедленно (если невозможно, то в течение 1 рабочего дня) уведомить другую сторону о факте компрометации сертификата;
уведомить УЦ о компрометации ключа ЭП;
произвести генерацию нового ключа ЭП, ключа проверки ЭП и выпустить в УЦ новый сертификат ключа проверки ЭП;
передать другой стороне файл с новым сертификатом;
проверить, что УЦ внес в список отозванных сертификатов серийный номер скомпрометированного сертификата и опубликовал новый СОС;
восстановить работу Системы по согласованию с другой стороной.
При компрометации корневого и/или промежуточного ключа ЭП удостоверяющего центра Сторона уведомляет об этом другую Сторону и документооборот приостанавливается до момента получения новых сертификатов.
Порядок разрешения споров, связанных с установлением подлинности ЭД
Любые споры между сторонами, предметом которых является установление подлинности, т.е. целостности текста и аутентичности отправителя ЭД, передаются для разрешения специально создаваемой Экспертной комиссии.
Экспертная комиссия созывается на основании письменного заявления (претензии) любой из сторон. В указанном заявлении сторона указывает реквизиты оспариваемого ПЭД и лиц, уполномоченных представлять интересы этой стороны в составе Экспертной комиссии.
Не позднее 10 рабочих дней с момента получения другой стороной заявления (претензии), стороны определяют дату, место и время начала работы Экспертной комиссии, определяют, какая сторона предоставляет помещение и производит конфигурирование средств ЭП.
Полномочия членов Экспертной комиссии подтверждаются доверенностями.
Состав Экспертной комиссии формируется в равных пропорциях из представителей сторон.
Экспертиза оспариваемого ЭД осуществляется в присутствии всех членов Экспертной комиссии.
Экспертиза осуществляется в четыре этапа:
1-ый этап: стороны совместно устанавливают, конфигурируют и тестируют средство ЭП.
2-ой этап: стороны предоставляют свою копию сертификата ключа проверки ЭП, используемому для создания НЭП оспариваемого ПЭД, а также корневого и промежуточных сертификатов УЦ.
З-ий этап: Экспертная комиссия с помощью средства ЭП получает ключи проверки ЭП из сертификатов, предоставленных сторонами, и сравнивает их с соответствующими ключами из сертификатов, переданными сторонам на основании пункта 8.11 настоящего Соглашения. Сертификаты, ключи проверки ЭП которых совпали, признаются подлинными. Также проверяется корневой сертификат, переданный на бумажном носители до подписания Соглашения, с только предоставленным сертификатом. Экспертная комиссия с помощью средства ЭП проверяет, выпущен ли сертификат ключа проверки ЭП, использованный для подписи оспариваемого ПЭД, с использованием корневого и промежуточных ключа ЭП УЦ.
4-ый этап: Проверка правильности ЭП под оспариваемым документом, предоставленным стороной-получателем, проверяется по сертификату принимающей стороны, подлинность которого подтверждена, как указано выше.
Подтверждением подлинности оспариваемого ПЭД является одновременное наличие следующих условий:
проверка подлинности ЭП оспариваемого ЭД дала положительный результат;
подтверждена принадлежность сертификата ключа проверки ЭП, использованного для проверки подлинности ЭП в оспариваемом ЭД;
ЭД сформирован в Системе и передан для обработки в соответствии с положениями настоящего Соглашения.
Результаты экспертизы оформляются в виде письменного заключения - Акта Экспертной комиссии, подписываемого всеми членами Экспертной комиссии. Акт составляется немедленно после завершения третьего этапа экспертизы. В Акте фиксируются результаты всех этапов проведенной экспертизы, а также все существенные реквизиты оспариваемого ПЭД. Акт составляется в двух экземплярах – по одному для каждой из сторон. Акт комиссии является окончательным и пересмотру не подлежит.
Подтверждение подлинности ЭП в оспариваемом ПЭД и зафиксированное в Акте, будет означать, что этот ПЭД имеет юридическую силу и влечет возникновение прав и обязательств сторон, установленных Основным договором и Соглашением. Не подтверждение подлинности ЭП в оспариваемом ПЭД и зафиксированное в Акте, будет означать, что этот ПЭД не имеет юридической силы и не влечет возникновение каких-либо прав или обязательств сторон, установленных Основным договором и Соглашением.
Стороны признают, что Акт, составленный Экспертной комиссией, является обязательным для сторон и может служить доказательством при дальнейшем разбирательстве спора в Арбитражном суде.
В случае отсутствия согласия по спорным вопросам и добровольного исполнения решения Экспертной комиссии, все материалы по этим вопросам могут быть переданы на рассмотрение в Арбитражном суде города Москвы.
Уполномоченными лицами на использование ЭП от имени Сторон являются:
От Оператора Председатель Правления Шабанова Т.А.
От Контрагента ____________________________(указать подписанта договора от контрагента).
От Оператора:
М.П.
Председатель Правления Шабанова Т.А.
|
От Контрагента:
М.П.
Должность, ФИО
|
Приложение №2
К договору об информационно-технологическом взаимодействии
при перечислении денежных средств в пользу физических лиц
для расчетов с использованием предоплаченных карт №_________ от_____
Приложение «Агент по зачислениям».
Приложение позволяет зачислять деньги на счета пользователей. Зачисления выполняются по спискам из файлов, которые вы загружаете в Агент, — по протоколу обмена информацией с Яндекс.Деньгами (описание протокола смотрите ниже).
Чтобы начать работу, нужно получить сертификат от Яндекс.Денег. Запрос на сертификат генерируется в приложении; полученные файлы нужно отправить на email менеджера в Яндекс.Деньгах. Сертификат придет в ответном письме.
Отправлять зачисления можно сразу после того, как сертификат будет импортирован в приложение.
ПОРЯДОК ОНЛАЙН ВЗАИМОДЕЙСТВИЯ
протокол обмена информацией
перевод средств на счета в системе «Яндекс.Деньги»
Протокол 3.0
Версия от 18.06.2012
Принципы работы
Данный протокол предназначен для информирования ООО НКО «Яндекс.Деньги» (далее — Системы) о поступлении переводов на виртуальные счета клиентов Системы.
Протокол предоставляет информационной системе Контрагента (далее — ИС):
Проверять возможность зачисления переводов.
Передавать запросы на зачисление переводов.
Передавать идентификационные данные физических лиц.
Отслеживать баланс средств по договору приема переводов.
ИС Контрагента и Система взаимодействуют с помощью протокола HTTPS.
Для выполнения каждой из операций ИС передает отдельный HTTP-запрос, содержащий криптопакет формата PKCS#7. На каждый запрос о зачислении сервер Системы отвечает сообщением о результате операции, помещенным в криптопакет PKCS#7.
Также используется криптографическая защита канала связи на базе протокола SSL (HTTPS), с аутентификацией по клиентскому сертификату. Кроме того, ограничивается список IP-адресов, с которых допустимо присылать запросы на сервер Системы.
Контрагент должен получить сертификат, с использованием которого он будет подключаться и формировать запросы к Системе. См. документ «Процедура обмена сертификатами».
Идентификационные данные – ФИО, гражданство пользователя, реквизиты документа, удостоверяющего личность, адрес места жительства, дата и место рождения. Перечень является минимально необходимым; включение иных составляющих в перечень идентификационных данных может быть согласовано сторонами дополнительно.
Параметры подключения Контрагента
Контрагенту доступны операции протокола: testDeposition, makeDeposition, balance .
Контрагенту, передающему идентификационные данные, дополнительно доступны операции протокола: testIdentificationDeposition, makeIdentificationDeposition.
Общее описание протокола
Формирование запроса
Формирование запроса к серверу Системы состоит из следующих шагов:
1. Формирование распоряжения на исполнение операции. Распоряжение формируется как документ согласно стандарту XML 1.0 (Fifth Edition), опубликованному по адресу: http://www.w3.org/TR/xml/. Документ должен быть сформирован в кодировке UTF-8 согласно стандарту: http://www.ietf.org/rfc/rfc2279.txt.
2. Формирование криптопакета. Сформированный документ помещается в криптоконтейнер формата PKCS#7 согласно стандарту http://www.ietf.org/rfc/rfc5652.txt. Криптоконтейнер должен содержать АСП (цифровую подпись, аналог собственноручной подписи). Криптоконтейнер не должен содержать цепочки сертификации. Компрессия данных не используется. Шифрование не используется. Криптопакет должен быть закодирован в формате PEM (OpenSSL). Сертификат Контргента, используемый при изготовлении криптопакета, должен соответствовать стандарту X.509 Version 3 (http://www.ietf.org/rfc/rfc2459.txt).
3. Передача запроса серверу Системы. ИС формирует POST-запрос по протоколу HTTP/1.1 (http://www.ietf.org/rfc/rfc2616.txt, http://www.ietf.org/rfc/rfc2818.txt, http://www.ietf.org/rfc/rfc4346.txt). Криптопакет может быть передан одним из двух способов:
Криптопакет помещается в тело POST-запроса, MIME-тип: application/pkcs7-mime.
Криптопакет передается как multipart-data вложение. MIME-тип: application/pkcs7-mime. POST-запрос должен иметь только один 'part', криптопакет должен быть вложен как файл. Такой запрос может быть отправлен из стандартной HTML-формы для file upload (отправки файла на сервер). См. http://www.ietf.org/rfc/rfc2388.txt.
Для авторизации запросов сервер Системы проверяет АСП криптопакета.
Защита от ошибочных повторов операций зачисления обеспечивается наличием уникального номера операции (clientOrderId).
Пример сформированного запроса:
POST /webservice/deposition/api/makeDeposition HTTP/1.1
Content-Type: application/pkcs7-mime
Content-Length: 572
-----BEGIN PKCS7-----
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCA
JIAEDEhlbGxvIFdvcmxkIQAAAAAAADGCAS8wggErAgEBMCowJTEWMBQGA1UECgwN
Qm91bmN5IENhc3RsZTELMAkGA1UEBhMCQVUCAQIwCQYFKw4DAhoFAKBdMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgwNjE1MzE0
M1owIwYJKoZIhvcNAQkEMRYEFC73veYIzlQE6X1fBC+V+J8cIyhxMA0GCSqGSIb3
DQEBAQUABIGAEgIfi0XDEZwbdC8i0I5EPUnFe1PUnBMiRs3heYxdK+oXaG6v3axO
Zr+VNG3tnW1W8M2xWtOcM4PdSTwx98WR1mWN8XDb2Wl9HiG6CGbmE7k4TgcDKhcg
iZmLV+7anBv302qTprTbKY9vChaaVwclSdQBkjPvxhlPnpBM0C9YdYQAAAAAAAA=
-----END PKCS7-----
Получение ответа
Результат выполнения запроса возвращается Системой в ответе на HTTP-запрос. MIME-тип: application/pkcs7-mime. Данные помещены в криптоконтейнер формата PKCS#7. Криптоконтейнер содержит АСП (цифровую подпись, аналог собственноручной подписи). Криптоконтейнер не содержит цепочки сертификации. Компрессия данных не используется. Шифрование не используется. Криптопакет закодирован в формате PEM (OpenSSL). Криптоконтейнер содержит XML-документ с результатом обработки запроса.
При получении ответа сервера ИС должна выполнить проверку подписи ответа, чтобы убедиться, что ответ отправлен сервером Системы, а также что его содержимое не было изменено третьей стороной. Следует также учитывать, что в ответе могут быть дополнительные поля, не описанные в данном протоколе, но не нарушающие совместимость.
|
