16 ноября, пятница 07:04
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Так нужно ли заверять время электронной подписи?

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Так нужно ли заверять время электронной подписи?

    Попробую закрыть вопрос о необходимости заверения третьим лицом (time-stamp сервером) времени подписи электронного документа, иначе, похоже, он будет постоянно всплывать на Форуме. Думаю, здесь нужно исходить не из теоретических, а из практических соображений.
    Поэтому на примере Интернет-банкинга постараюсь показать, что заверение времени подписи требуется в ИБ, как собаке пятая нога .
    Для ИБ возможны 3 схемы взаимодействия с УЦ (зависит от сервиса, который УЦ предоставляет).
    1.Самая простая - чтение сертификата с УЦ при каждом получении подписанного документа.
    2-3.Чтение сертификата клиента с УЦ только при его регистрации в системе ИБ и по окончанию срока его действия (обычно через год). Но при этом нужно либо забирать с УЦ анулированные сертификаты, скажем, раз в сутки, либо получать их по подписке (важна периодичность, с которой УЦ делает рассылку).

    Последние два варианта предпочтительнее как для УЦ (нагрузка меньше), так и для ИБ (работа не зависит от загрузки УЦ).
    Дальше больше . Подавляющая масса платежей по ИБ подписывается в день отправки. Сюда же входят платежи, отправленные после окончания операционного дня, для проведения на завтра.
    Случай, когда директор уезжает в командировку и оставляет главбуху подписанные платежи, встречается, но, во-первых, это доли процента всех платежей. И потом для электронных платежей дело здесь обстоит так же, как и для платежей на бумаге: если в банк принесут платежи недельной давности, а за это время сменился директор и в банке уже новая карточка с образцами подписей и печати, то банк такие платежи не примет, хотя на момент их подписания старый директор имел все полномочия. Значит, если в банк поступили электронные платежи, подписанные старым ключем, но в ИБ зарегистрирована другая карточка открытого ключа, то банк такие платежи должен отклонить. Причем когда эти платежи были подписаны - только что или неделю назад, абсолютно неважно!

    Ладно ИБ, возьмем электронную торговлю. Так ведь и в онлайн-магазине физик платит со своего счета в банке, причем, возможно, по тому же ИБ!
    Более того, в любой системе ИБ у клиента должна быть возможность заблокировать свои платежи напрямую, в дополнение к аннулированию сертификата в УЦ.

    Так кто же мне все-таки объяснит, зачем в ИБ нужно заверять время подписи платежей???

    P.S. Я специально выяснял, как с аналогичной ситуацией (с Вашего картсчета сняли деньги уже после того, как Вы заявили банку-эмитенту об утере своей карты) справляются в карточных системах.
    http://dom.bankir.ru/showthread.php?threadid=19493
    Оказывается, что в договоре с клиентом срок, в течение которого банк не несет ответственности за снятие денег с утерянной карты, может достигать месяца (для чиповых карт в режиме электронного кошелька)!

    И не нужно даже менять по этому поводу что-либо в Законе об ЭЦП. В общем случае, достаточно забить в договоре с клиентом (публичная оферта), что банк (страховая компания, онлайн магазин..) не принимает претензии по отказу от электронной подписи исполненного документа, если с момента анулирования сертификата до исполнения прошло менее суток.

  • #2
    По поводу сроков отмены сертификата\карты\итп.
    Обычно атака совершается в ближайшие несколько часов после компрометации ключа\карты\пароля. Поэтому договор, в котором написано, что втечение этого дня действительными считаются все транзакции, будет мягко говоря неприемлимым.
    "Востребован ли такой ИБанкинг" уже обсуждалось.

    //Подавляющая масса платежей по ИБ подписывается в день отправки.
    В случае если нужна множественная подпись, то обычно это уже несколько дней. К тому же системы неспособные работать 10 дней(редкий случай той же командировки) из 365, раздражают, и не только клиентов. Например я не смогу не есть 10 дней из 365.

    Хотя, Вы в чем то правы - для проведения платежей - приемлимы предложенные схемы, хотя и не самые удобные.(Напоминает юридическо-шаманские пляски: тут мы так, потом вот так, здесь присядем, тут подпрыгнем) А вот для документооборота, для учета контрактов, для ведения счета - заверение необходимо.

    Подводя итоги. Отсутствие TT Servises дает -
    1) дополнительные риски клиентам.
    2) неуодбства (например, если время на машине клиента совсем другое(год неправильный по ошибке администратора), то он не может ничего сделать - дата должна браться с сервера)
    3)Операции не должны быть больше чем на один день(примерно).Что есть в самом простом, хоть и распространенном случае.
    4)документооборот, учет контрактов, ведение счета - отпадают.

    Комментарий


    • #3
      Dimka-Toucan: Обычно атака совершается в ближайшие несколько часов после компрометации ключа\карты\пароля.

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

      Теперь насчет ИБ. Я же написал, что именно для ИБ и не существует проблемы (в том числе и со множеством подписей и при длительной командировке), т.к. клиент может не только на УЦ анулировать сертификат, но и отправить требование блокировки ключа непосредственно на сервер ИБ. И я не знаю ИБ, где такая возможность отсутствует.
      Поэтому я и утверждаю, что для ИБ в ТТ-сервисе абсолютно нет необходимости.


      Подводя итоги. Отсутствие TT Servises дает -
      1) дополнительные риски клиентам.

      Для ИБ никаких рисков!

      2) неуодбства (например, если время на машине клиента совсем другое(год неправильный по ошибке администратора), то он не может ничего сделать - дата должна браться с сервера)
      Дата в документе (платеже) набирается, а не берется с машины автоматом!

      3)Операции не должны быть больше чем на один день(примерно).Что есть в самом простом, хоть и распространенном случае.
      Не понял, откуда Вы это взяли

      Dimka-Toucan: А вот для документооборота, для учета контрактов, для ведения счета - заверение необходимо.
      Попробуйте убедить меня в этом . Если можно на конкретном примере, из реальной жизни.

      Комментарий


      • #4
        Здравствуйте,

        Метки времени - это не для непосредственного применения, а для разборок. Поясню:

        1. Если Вы используете ЭЦП, значит, предполагаете возможность спора между отправителем и получателем сообщения;

        2. Если Вы предполагаете возможность спора, то у Вас прописан способ его разрешения;

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

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

        3б. Сложный - Вы используете статусы сертификатов на момент отправки/приёма сообщения. Вот тут нужно, либо обозначить взаимное и безусловное доверие к протоколам одного из участников по поводу времени отправки/приёма сообщения, либо использовать метку времени на ЭЦП;

        3в. Могут быть промежуточные варианты, скажем, при разборе используется время подачи протеста.

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

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

        Успехов.
        --
        LSE, Сергей Леонтьев, Крипто-Про, http://www.CryptoPro.ru
        Последний раз редактировалось Serge3; 18.06.2002, 12:29.
        Успехов
        Леонтьев Сергей, lse@CryptoPro.ru, Крипто-Про

        Комментарий


        • #5
          to Serge3
          Как-то Вы неконкретно
          Хотелось бы надеяться, что Вы все-таки согласны с тем, что для ИБ заверять время подписи не нужно - даже для разборок. Тогда рассмотрим общий случай.
          Моя фирма подписывает с банком договор. Обычный договор, в нем, естественно, указывается номер и дата договора (не время !). Допустим, первым договор подписывает банк. В простом случае время подписи не проставляется (в некоторых договорах дата подписи также не ставится). Считается, таким образом, что подпись поставлена в день = дате договора. Поэтому, получив договор обратно, я проверяю валидность сертификата банка на дату договора. Если все в порядке, ставлю свою подпись и возвращаю договор банку. После проверки моей подписи, тоже на дату договора, банк должен подписать его второй раз, чтобы показать свою осведомленность о факте моей подписи. Таким образом при разборках в суде банку достаточно предъявить договор с двумя подписями, мне нужно предъявить договор с тремя подписями, причем на дату договора сертификаты всех подписей должны быть действительными.
          И все!
          Так зачем же здесь заверять время подписи договора?

          P.S. На закуску : в банк пришел платеж, в котором стоит дата недельной давности. Не криминал, конечно, но... платеж подписан ключем, сертификат которого зарегистрирован только вчера (неделю назад был другой директор!).
          Почему-то мне кажется , что ни один из толстых или тонких интернет-клиентов не сможет правильно разобраться в данной ситуации и исключить такой платеж. Или я не прав, уважаемые господа-разработчики?

          Комментарий


          • #6
            Sandyman здравствуйте,

            Неконкретно - это потому, что вопрос о необходимости удостоверения времени подписи относится к компетенции автора бизнес процесса, т.е. автора конкретных организационно-технических мер защиты. А я занимаюсь конкретными техническими средствами и типовыми организационными.

            По поводу основного абзаца:
            1. Общеупотребительные технические средства проверки ЭЦП осуществляют контроль на текущий момент времени, поэтому от проверки "на дату договора" придётся отказаться (для этого примера это ограничение не существенно);
            2. Вы предложили некоторый достаточно дорогой алгоритм взаимного удостоверения времени подписи и подтверждения признания сертификатов. Если этот алгоритм органично вытекает из общепринятой процедуры согласования и утверждения договоров этого типа, то хорошо, а если нет, то лучше использовать другие алгоритмы, более надёжные (доказательные) и более дешёвые (по времени, каналам, памяти, по деньгам). К основному недостатку этого алгоритма следует отнести не свойственные клиентам функции удостоверения и, соответственно, использование в решающем правиле клиентских сертификатов, которые чаще отзываются и имеют более короткие сроки действия;
            3. При использовании ЭЦП в корпоративной информационной системе, Вы до суда должны пройти процедуру разбора конфликтов определённую в договоре. В нём надо не забыть упомянуть о порядке разбора результатов этого алгоритма и обоюдном доверии к нему;
            4. При использовании ЭЦП в информационной системе общего пользования для разбора ЭЦП на момент подписания требуются доказательства, определяющие момент подписания договора. На мой взгляд, предложенный алгоритм их обеспечивает не в полной мере, в зависимости от условий применения.

            А теперь, для увеселения, рассмотрим пару сценариев защиты от необоснованных претензий клиента по поводу ЭЦП:

            Простой:
            1. Клиент приходит и пытается отказаться от документа с поручением;
            2. При разборе выясняется, что подпись верна, но сертификат клиента отозван позже фактически проведённых по поручению клиента действий;
            3. Открываем порядок разбора конфликтов по ЭЦП;
            4. Выясняем, что считается доказанным факт подлинности ЭЦП на момент проверки;
            5. Претензии клиента считаются не обоснованными.

            Сложнее:
            1. Клиент приходит и пытается отказаться от документа с поручением;
            2. При разборе выясняется, что хоть подпись, и верна, и сертификат клиента отозван до момента получения документа, но согласно расписанию работы УЦ, скажем VeriSign, первый СОС (CRL) содержащий отозванный сертификат был опубликован позже фактически проведённых по поручению клиента действий;
            3. Открываем порядок разбора конфликтов по ЭЦП;
            4. Выясняем, что считается доказанным факт подлинности ЭЦП на момент проверки;
            5. Претензии клиента считаются не обоснованными.

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

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

            Так же они могут использоваться как средства повышения защищённости клиента.

            Все эти навороты не обязательны, и всё можно решить в договоре, если таковой подписывается. А Ваш алгоритм, мне кажется опасным, т.к. в корпоративной системе всё решается проще, а в системе общего пользования он создаёт необоснованную иллюзию защищённости сторон.

            Успехов.
            Последний раз редактировалось Serge3; 19.06.2002, 22:11.
            Успехов
            Леонтьев Сергей, lse@CryptoPro.ru, Крипто-Про

            Комментарий


            • #7
              Serge3 1. Общеупотребительные технические средства проверки ЭЦП осуществляют контроль на текущий момент времени, поэтому от проверки "на дату договора" придётся отказаться

              Зачем отказываться? Достаточно ведь посмотреть период валидности сертификата.

              Serge3: Вы предложили некоторый достаточно дорогой алгоритм...
              А в чем дороговизна? Три подписи? Так ведь без этого не обойтись: должны же у стороны, которая поставила подпись второй, быть доказательства того, что первая сторона знала об этом факте подписи.

              Ваши рассуждения можно отнести, скорее, к обмену документами в ИБ. Ну так факт, что Вы подписали платеж и передали его в банк еще ни о чем не говорит. До тех пор пока у Вас не будет подтверждения из банка о том, что платеж получен. А подтверждением будет тот же Ваш платеж и некоторая доп. информация (статус платежа, время получения), подписанная банком. Вот с этим документом Вы можете идти в суд, если на время получения платежа, указанное в подтверждении, сертификат был отозван. А отзыв сертификата, как уже говорилось, в ИБ направляется не на УЦ (не только на УЦ), а непосредственно в банк. И на этот отзыв сертификата банк тоже формирует подписанное подтверждение о его приеме, где банком также указывается время приема. И никакой третьей стороны, заверяющей время, в такой схеме не требуется. И схема, ИМХО, простая и естественная.

              Комментарий


              • #8
                Sandyman здравствуйте,

                Сначала дискуссия.

                Serge3 1. Общеупотребительные технические средства проверки ЭЦП осуществляют контроль на текущий момент времени, поэтому от проверки "на дату договора" придётся отказаться
                Зачем отказываться? Достаточно ведь посмотреть период валидности сертификата.

                Не достаточно.

                Serge3: Вы предложили некоторый достаточно дорогой алгоритм...
                А в чем дороговизна?

                1. Объём пересылок: три раза пересылать документ;
                2. Время: поручение может начать исполняться только после выполнения всего алгоритма;
                3. Деньги: требование наличия дуплексного on-line по всей цепочке прохождения документа, т.к. всё начинается с пользовательского документа без ЭЦП, а в архив должен уйти документ с двумя (или тремя) подписями;
                4. Ещё раз деньги: Ваш алгоритм обязывает обе стороны контролировать фактический статус другой стороны на момент согласования, поэтому они будут вынуждены, либо постоянно опрашивать СОС (CRL) УЦ (а УЦ должен будет с достаточно высокой частотой их издавать), либо использовать механизмы on-line подтверждения статуса сертификатов типа OСSP. Кроме того, требует усиления требований к средствам криптографической защиты обеих сторон.

                Три подписи? Так ведь без этого не обойтись: должны же у стороны, которая поставила подпись второй, быть доказательства того, что первая сторона знала об этом факте подписи.
                Хм. Зачем? Во-первых, достаточно двух, а во-вторых, смотри ниже.

                Ваши рассуждения можно отнести, скорее, к обмену документами в ИБ. Ну, так факт, что Вы подписали платеж и передали его в банк, еще ни о чем не говорит. До тех пор пока у Вас не будет подтверждения из банка о том, что платеж получен. А подтверждением будет тот же Ваш платеж и некоторая доп. информация (статус платежа, время получения), подписанная банком.
                Я конечно человек достаточно далёкий от ИБ, но в результате наблюдений за нашей бухгалтерией у меня сложилось впечатление, что основные операции ИБ:
                1. Послать "платеж";
                2. Получить "выписку" об уже выполненных (или уже принятых к исполнению и проводимых) "платежах".

                А Вы предлагаете вставить ещё две:
                1а. Получить статус принятого банком "платежа" на согласование;
                1б. Послать согласие на выполнение принятого банком "платежа" по п.1.

                Вам не кажется, что это пустая растрата народных денег?

                Вот с этим документом Вы можете идти в суд, если на время получения платежа, указанное в подтверждении, сертификат был отозван.
                Чтобы идти с этим документом в суд с опорой на "Закон об ЭЦП" нужно иметь доказательства, определяющие момент подписания. А предложенный алгоритм, в отличие от других алгоритмов получения "метки времени", не даёт подтверждения абсолютного времени подписания (без значительного удорожания средств криптографической защиты), он даёт только последовательность согласования и, поэтому, допускает большую неопределённость в толкованиях. Так что не советую, лучше уж через корпоративный порядок разбора конфликтов.

                Потом обсуждение предмета дискуссии.

                Sandyman, Вам не кажется, что наша дискуссия инвертировалась? Т.е. получается, что я утверждаю: "метки времени" хотя и полезная, но совершенно не обязательная возможность. А Вы отстаиваете полезность и необходимость некоторого конкретного алгоритма получения "метки времени", тем самым, опровергая свой основной тезис, вынесенный в заголовок.

                P.S.

                В общем, меня как-то смущает высокая встречаемость не обоснованных требований потребителей ИОК (PKI) к времени компрометации ключа в системах. На пример, часто требуют наличия возможности и собираются переиздавать СОС максимально быстро по факту сообщения о компрометации, но тогда на момент разбора конфликта обе стороны смогут оперировать СОС с перекрывающимися сроками действия, что затруднит разбор конфликта. И т.п. противоречия в требованиях. Клиент, конечно, всегда прав.

                Как Вы совершенно верно заметили в карточных системах отношение к этому более разумное.

                Успехов.
                Последний раз редактировалось Serge3; 21.06.2002, 00:40.
                Успехов
                Леонтьев Сергей, lse@CryptoPro.ru, Крипто-Про

                Комментарий


                • #9
                  Serge3: А Вы предлагаете вставить ещё две:
                  1а. Получить статус принятого банком "платежа" на согласование;
                  1б. Послать согласие на выполнение принятого банком "платежа" по п.1.


                  Вовсе нет! Вы смешиваете частный случай подписи платежей для ИБ и общий случай подписания договора.
                  Для платежей никакие три подписи не нужны. Вы правильно описали процедуру проведения платежей в ИБ (или БК), только то, что Вы называете выписками у нас, например, называются протоколами, в которых фиксируется статус обработки документа: принят, исключен, проведен, подтвержден. В протоколе можно указать идентификатор платежа, но с идентификатором в суд не пойдешь, поэтому более правильным было бы включение в протокол самого текста подписанного Вами платежа. Ну и конечно, протокол подписывается банком. И время в протоколе заверять не нужно - это время проставляет банк, а Вам остается его только принять к сведению.

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

                  sandyman: Зачем отказываться? Достаточно ведь посмотреть период валидности сертификата
                  Serge3: Не достаточно

                  И что же мешает, если используется XML?

                  Serge3: Хм. Зачем? Во-первых, достаточно двух

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

                  Serge3: часто требуют наличия возможности и собираются переиздавать СОС максимально быстро по факту сообщения о компрометации, но тогда на момент разбора конфликта обе стороны смогут оперировать СОС с перекрывающимися сроками действия, что затруднит разбор конфликта.

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

                  Serge3: я утверждаю: "метки времени" хотя и полезная, но совершенно не обязательная возможность. А Вы отстаиваете полезность и необходимость некоторого конкретного алгоритма

                  Я опасаюсь, что в законе (об ЭЦП или об электронном документе) пропишут обязательность заверения времени подписи и поэтому стараюсь показать, что без этого прекрасно можно обойтись.

                  Комментарий


                  • #10
                    Sandyman здравствуйте,

                    Для платежей никакие три подписи не нужны.

                    Мы рассматриваем процедуру разрешения конфликта по некоторому документу. Это может быть договор, а может быть и платёж. Итого, если просуммировать, то Вы считаете:
                    1. Для договоров, лучше вместо двух подписей и стандартной "метки времени" использовать "метку времени" полученную "естественным" путём дополнительного подтверждения согласия с текстом договором;
                    Примечание: Надо понимать, что суд может отказаться принять к рассмотрению показания двух системных таймеров по причине отсутствия документального подтверждения их качества, либо по заявлению одной из сторон о недоверии к их показаниям, либо по причине расхождения их показаний, и начать рассмотрение конфликта исходя из статуса сертификатов на момент рассмотрения иска, если стороны не представят иных доказательств.

                    2. Для платежей "метка времени" вообще не нужна, а в случае возникновения конфликтов, то в качестве доказательств момента времени ЭЦП следует использовать протоколы банка и/или времена фактического прохождения платежей.

                    Вы должны проверить валидность подписи, обратившись на УЦ.

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

                    Как я понял, СОС - это стоп-лист, где перечислены отозванные сертификаты.

                    Да, и в нём указан некоторый период времени в течение, которого клиент не обязан получать новый СОС, а по окончании, которого должен блокировать работу с сертификатами до получения нового.

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

                    Я опасаюсь, что в законе (об ЭЦП или об электронном документе) пропишут обязательность заверения времени подписи и поэтому стараюсь показать, что без этого прекрасно можно обойтись.

                    а) Я с Вами, совершенно согласен, что при определённых условиях без времени можно обойтись ценой некоторых рисков, которые можно контролировать иными способами. На пример, разумным отношением к компрометации;

                    б) На пример, в законе об ЭЦП РФ записано следующее (и, на мой взгляд, этого достаточно):
                    Статья 4. Условия признания равнозначности электронной цифровой подписи и собственноручной подписи
                    1. Электронная цифровая подпись в электронном документе равнозначна собственноручной подписи в документе на бумажном носителе при одновременном соблюдении следующих условий:
                    сертификат ключа подписи, относящийся к этой электронной цифровой подписи, не утратил силу (действует) на момент проверки или на момент подписания электронного документа при наличии доказательств, определяющих момент подписания;
                    подтверждена подлинность электронной цифровой подписи в электронном документе;

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

                    г) Как я Вас понял, Вы считаете, что в некоторых случаях следует использовать "метки времени" или их заменители.

                    Успехов.
                    Последний раз редактировалось Serge3; 22.06.2002, 20:48.
                    Успехов
                    Леонтьев Сергей, lse@CryptoPro.ru, Крипто-Про

                    Комментарий


                    • #11
                      В общем-то, все правильно !

                      Serge3: Стоимость услуг оперативного обращения к УЦ в информационных системах общего пользования (типа VeriSign), на которых сейчас все помешались (в частности, суд им подавай, без полюбовного разбора конфликта в рамках корпоративной системы), может стоить достаточно дорого.

                      А как же статья 9 Закона об ЭЦП?
                      4. Услуги по выдаче участникам информационных систем сертификатов ключей подписей, зарегистрированных удостоверяющим центром, одновременно с информацией об их действии в форме электронных документов оказываются безвозмездно.

                      Serge3: Надо понимать, что суд может отказаться принять к рассмотрению показания двух системных таймеров по причине отсутствия документального подтверждения их качества

                      Доверие к качеству системных таймеров, ИМХО, здесь непричем. Перед тем как поставить свою подпись под договором вторая сторона должна проверить валидность подписи первой стороны. Для этого программа берет дату договора (XML), сравнивает ее с периодом действия сертификата, и, если все в порядке, проверяет подпись и ставит свою. В более сложном случае, когда проставлено время первой подписи, программа проверяет валидность сертификата и на это время. В любом случае вторая сторона осведомлена о времени (дате) первой подписи , и простановкой своей подписи выражает согласие с этим временем.
                      Что касается протокола получения платежа банком, то он должен выкладываться сразу. Отсутствие протокола означает, что в системе ИБ (БК) произошел сбой, и, значит, нужно звонить в банк и выяснять в чем дело. Время в данном протоколе, таким образом, значения не имеет. Ежели Вы, в какой-то момент, связавшись с банком, получили протокол об отклонении Вашего платежа, то для Вас имеет значение только попадание времени подписи банком данного протокола в период между текущим временем и временем получения Вами предыдущего протокола, что практически всегда имеет место быть. В любом случае программа также показывает Вам время подписи протоколов, а банк отвечает за значение проставленного времени и никакие ссылки на испорченность таймеров ему не помогут.


                      P.S. Да и еще замечание, по поводу стоп-листов. Не знаю как в Verisign, но, ИМХО, было бы целесообразно отдельно публиковать стоп-листы сертификатов, прекративших свое действие досрочно (убитых ), и стоп-листы сертификатов, у которых срок действия просто закончился (умерших).

                      Комментарий


                      • #12
                        Sandyman здравствуйте,

                        А как же статья 9 Закона об ЭЦП?
                        4. Услуги по выдаче участникам информационных систем сертификатов ключей подписей, зарегистрированных удостоверяющим центром, одновременно с информацией об их действии в форме электронных документов оказываются безвозмездно.


                        Извините, строго говоря, я имел в виду и ссылался на суммарную себестоимость услуги (и для клиента, и для УЦ). Да и вообще, это очень странное положение закона, т.к. определяет обязательную максимальную цену услуги, но не определяет обязательного минимального её качества (скажем, запросы/секунду, время простоя в год). Эти вопросы отдаются на откуп уполномоченного федерального органа исполнительной власти. Ну да ладно, закон - есть закон.

                        А то, каким путём себестоимость УЦ превратится в стоимость (цену) услуги, это уже вопрос маркетинга, но водичка дырочку найдёт. На примере мирового опыта, возможен такой вариант: УЦ введёт несколько классов сертификатов (по цене и уровню требований уполномоченного федерального органа исполнительной власти), для каждого из которых определит и согласует свою форму предоставления информации об их действии, скажем, публикация СОС (CRL) раз в десять дней для 1 класса, а то и по запросу, высылаемому обычной почтой и т.д. А кроме этого, предложит платные услуги предоставления "меток" TSP/OCSP/DVCS, совершенно четко мотивировав, что всякие там "метки" не являются обязательными и жизненно необходимым атрибутами ЭЦП.

                        А есть ещё себестоимость услуги для клиента, т.к. СОС могут быть достаточно большими.

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

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

                        P.S. Да и еще замечание, по поводу стоп-листов. Не знаю как в Verisign, но, ИМХО, было бы целесообразно отдельно публиковать стоп-листы сертификатов, прекративших свое действие досрочно (убитых), и стоп-листы сертификатов, у которых срок действия просто закончился (умерших).

                        В X.509 СОС так и определён - это список отозванных сертификатов, у которых срок действия указанный в сертификате ещё не окончился.

                        Но для класса 1 VeriSign, если мне не изменяет память, он занимал несколько сотен килобайт (смотри http://crl.verisign.com/).

                        Ну и вообще, СОС - это очень больная тема, скажем, даже такой монстр - Microsoft вынужден сам распространять СОС на не корректно выданные VeriSign (он же Thawte) сертификаты подписи кода на имя Microsoft в составе своего ПО или в виде его обновлений. И чего все на "Бифит" набросились?

                        Успехов.
                        Успехов
                        Леонтьев Сергей, lse@CryptoPro.ru, Крипто-Про

                        Комментарий


                        • #13
                          Serge3: Но для класса 1 VeriSign, если мне не изменяет память, он занимал несколько сотен килобайт

                          А разве нельзя организовать на УЦ рассылку СОС по индивидуальным заявкам, где будут указаны сертификаты, информацию по которым включать в СОС? При появлении новых клиентов, заявку можно корректировать..

                          P.S. Еще один вопрос (думаю, риторический ) к разработчикам ИБ: какая из систем позволяет клиентам подписывать договора с банком и сколько там ставится подписей ? А может там используется заверение времени подписи?

                          Комментарий


                          • #14
                            какая из систем позволяет клиентам подписывать договора с банком и сколько там ставится подписей
                            Думаю, через месяца три-четыре я смогу Вам на этот вопрос ответить

                            Сейчас мне другой вопрос со временами документов интереснее - банк обязуется взять в обработку текущим днём документы, полученные, e.g. до 14:00 по Москве. Клиент присылает (вводит) документ в 14:05 и начинает выставлять банку претензии, что он-де всё делал вовремя, а вот банк приём этого документа на 10 минут затормозил.
                            Как банки с этим вопросом разбираются?[/I]

                            Комментарий

                            Пользователи, просматривающие эту тему

                            Свернуть

                            Присутствует 1. Участников: 0, гостей: 1.

                            Обработка...
                            X