ГОСТ-вый хэш код договора, в качестве пин кода, в назначении платежа

[sanyock]

Задача: Нужно гарантировать согласие лицензиата с лицензионным договором на прог. обеспечение, неизменность его содержимого, а так же безвозвратность платежа лицензиата (например по выдуманной причине, например "оплатил по ошибке", или "по другому договору") в долгосрочном плане. При этом нужно, чтобы такой договор имел юридическую значимость и при необходимости в качестве арбитра мог выступать суд.

Лицензиар=разработчик=предоставитель прав=получатель платежа=резидент РФ
Лицензиат=получатель прав=плательщик=нерезидент РФ

Замечание: Закон РФ вообще не требует подписания присоединенного лицензионного договора сторонами и лицензиатом в т.ч. КриптоАрм в режиме только проверки (без создания) ЭЦП доступен бесплатно через интернет для всех (в т.ч. лицензиату).

Можно ли присоединением лицензиата к электронному договору считать оплату через банк, если:
_____________
1) В электронном договоре обговорить перечисленные здесь условия
2) Для гарантии целостности договора подписать его ЭЦП лицензиара.
3) В назначении платежа лицензиат укажет:
I accept the software license agreement electronic docu_ment with GOST hash code: xxxx
Кстати, какая максимальная длина назначения платежа для международных платежей?
4) При необходимости создать бумажный договор, в котором указать на то, что стороны признают условия электронного документа, подписанного ЭЦП лицензиара. В бумажный договор включить только распечатку ЭЦП, без текста лицензии (из электронного договора), т.к. ЭЦП однозначно идентифицирует электронный документ.
_____________
Выполнятся ли при этом условия задачи?

Уточнение - Цитата(malotavr):
Лицензиат проверил ЭЦП лицензиара и убедился, что оферта в электронном виде пришла от него. Он акцептует оферту, выполняя банковский платеж и указывая хэш оферты. Реквизиты банковского платежа подтверждают, что акцепт был сделан именно лицензиатом, а хэш подтверждает, что акцептована была именно эта оферта.

[stas®]

хэш-код ничего не дает, сделайте просто номер (единый для всех акцептантов)
В платеже должно указываться, что он по этому договору.

[sanyock]

Акцептант только один, потому что договор - исключительная лицензия.
Под номером вы имеете ввиду какой-нибудь порядковый номер 1, 2, 3 ...
или относительно длинный пин код из хотя бы 5-10 символов?

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

Изменение хоть одного символа в тексте договора никак не повлияет на его номер, но полностью изменит его хэш код. В случае изменения текста договора, как мне доказывать потом, что оригинальный текст отличался?

Если формально нужно указывать номер договора, то предлагаю указать и номер и хэш одновременно. Нужно ли будет предварительное бумажное соглашение о признании такого способа акцепта?

[stas®]

sanyock, хэш никому ничего не докажет. А если единственный клиент, то проще переслать бумажный договор.

[sanyock]

Хэш не докажет без грамотно составленного предварительного бумажного договора или даже с ним?

Разве нельзя утверждать, даже без бумажного договора, что строка в назначении платежа:
"Я согласен с условиями электронного документа с хэш кодом по ГОСТ Р 34.11.: xxxxxxxxxx"
указывает на согласие акцептанта с вполне определенным договором и ни чем иным?

А чем тогда может помочь номер договора? он вообще к договору никак не привязан.

[sanyock]

http://www.e-nigma.ru/stat/gost/

3.1.13. хэш-код (hash-code): Строка бит, являющаяся выходным результатом хэш-функции (ИСО/МЭК 148881-1 [3]).

3.1.14. хэш-функция (hash-function): Функция, отображающая строки бит в строки бит фиксированной длины и удовлетворяющая следующим свойствам:

1) по данному значению функции сложно вычислить исходные данные, отображенные в это значение;

2) для заданных исходных данных трудно найти другие исходные данные, отображаемые с тем же результатом;

3) трудно найти какую-либо пару исходных данных с одинаковым значением хэш-функции.

Примечание - Применительно к области ЭЦП свойство 1 подразумевает, что по известной ЭЦП невозможно восстановить исходное сообщение; свойство 2 подразумевает, что для заданного подписанного сообщения трудно подобрать другое (фальсифицированное) сообщение, имеющее ту же ЭЦП, свойство 3 подразумевает, что трудно подобрать какую-либо пару сообщений, имеющих одну и ту же подпись.

[stas®]

sanyock, объясните, зачем Вы городите огород, если в принципе бумажные документы Вы подписываете?

[sanyock]

Один предварительный бумажный договор (или ни одного, если это возможно, не потеряв при этом юридическую значимость) можно было бы использовать для нескольких электронных договоров (по мере выпуска новых версий программы)

ЭЦП со штампом времени очень надежно фиксирует содержимое и время подписания договора, бумага - не уверен.

Почта в обе стороны - это долго, неудобно. По пути может (теоретически) поменяться содержимое, хотя, конечно, можно попросить отправить скан по e-mail перед возвратом одной из подписанных копий. Где гарантия получения подписи именно того человека, который указан в договоре, если личного контакта не было, и его оригинальная подпись не известна на 100%, может ее вообще на компьютере нарисовали? Если считать бумажный договор чистой формальностью, то наверно можно осуществить такой обмен бумажными копиями договора, но будет ли он юридически значимым, например, в суде РФ?

[stas®]

sanyock, вы сами себе противоречите. Основываете целую цепочку электронных договоров на одном бумажном и говорите о ненадежности бумаги.

[sanyock]

я пытаюсь избежать предварительного бумажного договора, предлагая использовать вышеперечисленные доказательства проявления воли каждой из сторон:
со своей стороны - ЭЦП
со стороны плательщика - указания однозначного идентификатора договора в назначении платежа, которое кроме него при отсутсвии форс мажора никто не мог заполнить.

Причем по закону РФ вообще не требуется подписывать лицензионный договор, присоедиенный к экземпляру софта (ни лицензиаром, ни лицензиатом).

Одна из моих главных задач сделать банковский платеж безвозвратным (в т.ч. с юридической точки зрения суда) после получения лицензиатом исходного кода системы. Для этого мне нужно неоспоримое доказательство согласия с договором лицензиата, и наверно того, что плательщик является лицензиатом.
Система находится в режиме тестирования уже больше года (думаю достаточно времени для тестирования).