22 ноября, среда 04:47
Bankir.Ru

Объявление

Свернуть
1 из 2 < >

Выбираем Золотого пользователя - 2017

2 из 2 < >

Выбираем Золотого модератора - 2017

Показать больше
Показать меньше

О заполнении полей сертификата

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

  • О заполнении полей сертификата

    Что-то грузанлуся под вечер.
    Ситуация:
    1) Фирма зарегистрирована в Рязани. Фактический адрес - в Екатеринбурге
    2) Банк и фактически, и юридически находится в Екатеринбурге.

    Фирма открывает в банке счет; с целью удаленного управления счетом получает в УЦ банка сертификат.
    Вопрос: что правильнее писать в полях сертификата Locality и State/Province?
    Earl Vlad Drakula. ///

  • #2
    Зарегистрирована кем? Если имеется в виду, что юридический адрес фирмы г. Рязань, а фактический г. Екатеринбург, то логично заполнить эти поля юридическим адресом.
    P.S.Кстати, интересная статья по этому поводу

    Комментарий


    • #3
      Zuz
      Зарегистрирована кем? Если имеется в виду, что юридический адрес фирмы г. Рязань
      Да, именно так.

      логично заполнить эти поля юридическим адресом.
      Мне почему-то тоже так кажется

      P.S.Кстати, интересная статья по этому поводу
      Спасибо, полезный материал.
      Earl Vlad Drakula. ///

      Комментарий


      • #4
        1. Встречный вопрос, зачем вообще эти поля заполнять?
        2. И т.к. сертификат выдается физическому лицу, то не логично ли эти поля, если их необходимо заполнять, местом регистрации этого физического лица (правда при изменении этих полей, например, переезд физического лица придется отзывать сертификат и выпускать новый)?

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

        Т.е. из закона, Imho, следует, что такие данные не нужно вносить в сертификат, необходимо внести данные только о местоположении УЦ.

        Кстати, насколько чётко должно быть указано местоположение?
        Например: "Россия", чем не местоположение?
        Взять, к примеру, корневой сертификат, уважаемого мной ЗАО "УДОСТОВЕРЯЮЩИЙ ЦЕНТР", г. Санкт-Петербург.
        Четкого местоположения там нет, только страна и город.
        И, кстати, этот сертификат выдан не на физическое лицо (если это не так, поправьте меня), я понимаю, что он корневой, но по закону любой сертификат выдается на физическое лицо (опять же, если это не так, поправьте меня). И если это псевдоним физического лица, то в сертификате в электронной форме нет об этом никаких записей. Не важно, что, есть бумажный сертификат, где указано соответствие между физическим лицом и этим сертификатом, ведь из сертификата в электронной форме этого не видно и не должно быть расхождений.
        В таком случае как быть, если лицо, на которое выдан корневой сертификат УЦ, уволилось, а ещё проще заболело, то каким образом УЦ вообще работать сможет (закрытый ключ УЦ есть только у этого человека)?
        Кто-нибудь решил эти проблемы или я чего не понял ;-?

        Комментарий


        • #5
          Zuz
          Т.е. из закона, Imho, следует, что такие данные не нужно вносить в сертификат
          По закону об ЭЦП - не обязательно. Но там дальше есть еще пассаж, что могут быть внесены и другие сведения.
          Собственно, УЦ заинтересован ниболее точно идентифицировать владельца сертификата, точнее, наиболее полно осуществить привязку электронной сущности (открытый ключ), к субъекту правовых отношений. Сколько у нас в городе Ивановых Иванов Ивановичей? Значит, чисто по ФИО идентифицировать плохо, надо что-то еще. Вот в X.509 и введены поля Country, State/Province, Locality, Organization, Org. Unit, Title и E-mail.

          И, кстати, этот сертификат выдан не на физическое лицо (если это не так, поправьте меня), я понимаю, что он корневой, но по закону любой сертификат выдается на физическое лицо (опять же, если это не так, поправьте меня).
          Юра, надо было сегодня прийти на круглый стол, который "Скайнет" проводил, там как раз эти вопросы жевали (правда, безрезультатно).
          Могу лишь высказать один давний тезис: в праве нет понятия "подпись юридического лица", а поскольку ЭЦП является одним из аналогов собственноручной подписи (являющейся атрибутом физического лица), то изобретать новую сущность - нецелесобразно. Причем, нужно заметить, что собственноручная подпись гражданина Иванова И.И. и директора ООО "Закат солнца вручную" Иванова И.И. несколько различаются (хотя графически выглядят одинаково), посему в сертификате для второго случая правильно указывать наименование конторы и должность. Либо делать сертификат просто на Иванова, а потом выпускать атрибутный сертификат для него, как для директора ООО.
          С корневым сертификатом УЦ (да и не только с корневым) - да, грабли получаются. IMHO, это как раз тот случай, для которого надо делать исключение, и "приколачивать" ключ не к конкретному физическому лицу, занимающему сейчас определенную должность, а просто к должности. Но тогда нужно специльными орг.-тех. мероприятиями создавать режим доступа к секретному ключу, при котором "смена тела" на этой должности не приведет к компрометации этого ключа и необходимости отзыва всего, что им подписано. Почти аналогичная песня с SSL-сертификатом для сервера.
          Earl Vlad Drakula. ///

          Комментарий


          • #6
            2 hugevlad:
            Мне больше нравится идея с атрибутными сертификатами, не хочу я по каждому чиху сертификат отзывать, новый выпускать - с ума сойти можно ;-) Кстати, кто-нибудь внедрил это у себя, появилась ли реализация в софте?
            В реальной жизни мы же паспорт не меняем, когда работу сменили... даже при смене места жительства не меняем паспорт, а вот сертификат, если эти поля заполнять, придется сменить (причем владелец сертификата, в этом случае, даже не почешется это сделать ;-)...

            P.S> Про круглый стол не знал, жаль, что не попал ;-(

            Комментарий


            • #7
              Zuz
              Кстати, кто-нибудь внедрил это у себя, появилась ли реализация в софте?
              Прототип есть в "Инеге":
              http://www.adam.ru/Pki/inega.phtml
              (поиск по "RFC 3281")

              Про круглый стол не знал, жаль, что не попал ;-(
              1) Не много потерял
              2) Материалы этого и предыдущего столов будут в мартовском номере "Бизнес-Скайнет" N2(40)
              Earl Vlad Drakula. ///

              Комментарий


              • #8
                2 hugevlad:
                Про "Инегу" я в курсе, хотелось бы реальные внедрения пощупать с регламентами ;-)

                Комментарий


                • #9
                  Сообщение от hugevlad
                  Zuz
                  ...
                  И, кстати, этот сертификат выдан не на физическое лицо (если это не так, поправьте меня), я понимаю, что он корневой, но по закону любой сертификат выдается на физическое лицо (опять же, если это не так, поправьте меня).
                  ...
                  Могу лишь высказать один давний тезис: в праве нет понятия "подпись юридического лица", а поскольку ЭЦП является одним из аналогов собственноручной подписи (являющейся атрибутом физического лица), то изобретать новую сущность - нецелесобразно.
                  ...
                  С корневым сертификатом УЦ (да и не только с корневым) - да, грабли получаются. IMHO, это как раз тот случай, для которого надо делать исключение, и "приколачивать" ключ не к конкретному физическому лицу, занимающему сейчас определенную должность, а просто к должности. Но тогда нужно специльными орг.-тех. мероприятиями создавать режим доступа к секретному ключу, при котором "смена тела" на этой должности не приведет к компрометации этого ключа и необходимости отзыва всего, что им подписано. Почти аналогичная песня с SSL-сертификатом для сервера.
                  Да нет здесь особых граблей, и исключений делать особо не требуется. Понятие персональной ответственности за закрытый ключ разработчикам X.509/RFC 3280 было не чуждо.
                  .
                  В случае сертификатов уполномоченных лиц удостоверяющих центров, то X.509/RFC 3280 описывают все необходимые процедуры работы CA, который может иметь несколько самоподписанных сертификатов (они связываются самовыпущенными сертификатами). Так что, если Вам необходимо иметь несколько уполномоченных лиц, или Ваше уполномоченное лицо меняется, то это не должно вызывать принципиальных проблем.

                  Сертификат SSL сервера не обязан быть единственным, скажем, если SSL сервер обслуживается несколькими операторами, то каждый из них может иметь свой закрытый ключ и сертификат.
                  Успехов
                  Леонтьев Сергей, lse@CryptoPro.ru, Крипто-Про

                  Комментарий


                  • #10
                    Serge3
                    X.509/RFC 3280 описывают все необходимые процедуры работы CA, который может иметь несколько самоподписанных сертификатов (они связываются самовыпущенными сертификатами). Так что, если Вам необходимо иметь несколько уполномоченных лиц, или Ваше уполномоченное лицо меняется, то это не должно вызывать принципиальных проблем.
                    Конечно, я завтра с утра почитаю, но чисто организационно я не очень понимаю этот процесс. После увольнения одного из этих лиц, его ключ считается скомпрометированным. Соответственно, надо отзывать и все выпущенные им сертификаты. ИЛи перевыпускать от другого ответственного...

                    Ой, пойду спать
                    Earl Vlad Drakula. ///

                    Комментарий


                    • #11
                      Сообщение от hugevlad
                      После увольнения одного из этих лиц, его ключ считается скомпрометированным. Соответственно, надо отзывать и все выпущенные им сертификаты.
                      Почему считается скомпрометированным? Закрытый ключ согласно регламенту уничтожается в процессе передачи дел и всё.

                      Сообщение от hugevlad
                      ИЛи перевыпускать от другого ответственного...Ой, пойду спать
                      Согласен, утро вечера мудренее.
                      Успехов
                      Леонтьев Сергей, lse@CryptoPro.ru, Крипто-Про

                      Комментарий


                      • #12
                        2 Serge3:
                        1. Легко сказать, закрытый ключ уничтожается... а кто даст гарантию, что не было сделано копии?
                        И, кстати, в софте такая реализация есть? Что-то у Microsoft я такого в их реализации PKI не нашел (не надо ногами пинать, вполне нормальное решение ;-)

                        2. Serge3 пожалуйста ответьте на эти и ранее поставленные вопросы более подробно, как специалист (особенно интересно, про нескольких ответственных лиц и несколько сертификатов УЦ, если не сложно дайте более конкретные ссылки в RFC 3280 чего-то не нашел про это)! Посмотрел Ваш УЦ упоминаний о таких процедурах не нашел (как и регламента, который упомянут на первой странице сайта ;-(

                        3. Про SSL сервер, но ведь в конкретный момент времени активен сертификат одного оператора?

                        4. Можно вопрос к Вам, как представителю Crypto Pro? Если в качестве ключевого контейнера используется eToken R2 или Pro (естественно в вашей реализации криптопровайдера и поддержки этих устройств), насколько просто сделать копию с такого носителя зная пароль к eToken'у? Можно ли этого избежать, если нет, есть ли USB устройство подобного класса с требуемыми мне характеристиками?

                        Заранее спасибо!

                        Комментарий


                        • #13
                          Serge3
                          Почему считается скомпрометированным? Закрытый ключ согласно регламенту уничтожается в процессе передачи дел и всё.
                          Аргументов два: один "формальный", другой - "по жизни".
                          Формальный - согласно правил эксплуатации всех попадавшихся мне под руку СКЗИ, к событиям, являющимся компрометацией ключа относится "Увольнение сотрудников, имевших доступ к ключевой информации."
                          Конечно, из формального аргумента не следует, что теряют свой статус все ранее подписанные документы (в т.ч. и сертификаты). Но здесь отыскиваются закопанные подводные грабли с CRL, которые должны подписываться тем же ключем, которым выпущены отзываемые сертификаты (или я ошибаюсь?).
                          Плюс, как заметил Юрий, довольно сложно гарантировать отсутствие доп. копий ключа, сделанных экс-владельцем...
                          Earl Vlad Drakula. ///

                          Комментарий


                          • #14
                            Serge3
                            В случае сертификатов уполномоченных лиц удостоверяющих центров, то X.509/RFC 3280 описывают все необходимые процедуры работы CA, который может иметь несколько самоподписанных сертификатов (они связываются самовыпущенными сертификатами).
                            Сергей, не подскажете номер раздела в RFC?
                            Сходу не смог найти описание этих процедур...
                            Earl Vlad Drakula. ///

                            Комментарий


                            • #15
                              Сообщение от hugevlad
                              Serge3
                              Почему считается скомпрометированным? Закрытый ключ согласно регламенту уничтожается в процессе передачи дел и всё.
                              Аргументов два: один "формальный", другой - "по жизни".
                              Формальный - согласно правил эксплуатации всех попадавшихся мне под руку СКЗИ, к событиям, являющимся компрометацией ключа относится "Увольнение сотрудников, имевших доступ к ключевой информации."
                              Это уже технические детали конкретной реализации, вариантов может быть несколько:
                              1. Сложный - ключ уполномоченного лица в хранится HSM зашифрованный на ключе смарт-карточки уполномоченного лица и ключах защиты от НСД по схеме 3 смарт-карточки из 5 возможных;
                              2. Простой - уполномоченное лицо клянётся, что оно уничтожило ключ при передаче дел.


                              Сообщение от hugevlad
                              Но здесь отыскиваются закопанные подводные грабли с CRL, которые должны подписываться тем же ключем, которым выпущены отзываемые сертификаты (или я ошибаюсь?).
                              Согласно RFC 3280 СОС (CRL) может быть подписан самим CA, т.е. теми ключами, сертификаты которых имеют те же самые issuer, а это могут быть любые из самоподписанных (self-signed) сертификатов CA для которых может быть построена цепочка до доверенного хранилища пользователя из самовыпущенных (self-issued) сертификатов. Либо СОС может подписываться ключами специализированных источников СОС имеющих сертификаты с расширением использования ключа cRLSign.
                              Успехов
                              Леонтьев Сергей, lse@CryptoPro.ru, Крипто-Про

                              Комментарий


                              • #16
                                Serge3
                                Сложный - ключ уполномоченного лица в хранится HSM зашифрованный на ключе смарт-карточки уполномоченного лица и ключах защиты от НСД по схеме 3 смарт-карточки из 5 возможных;
                                Вот я именно такую схему и хочу. Самоподписанный сертификат СА выпадает из ХСМ, а соответствующий секретный ключ рождается в этом ХСМ и никогда его не покидает. (в скобках ехидно напомню, что кто-то в ру.крипт говорил, будто ХСМ не нужен, пентиум неплохо справляется ) Затем коллегиально сертифицируем ключики операторов УЦ (человек 5-10 ) и объясняем СА, что ежели приходит запрос на сертификат, заверенный одним из этих 10 ключей, то отдавать его на сертификацию в ХСМ. В такой схеме при увольнении одного из операторов, его серт спокойно отзывается, но компрометации самого главного ключа не происходит, потому что никто не имеет к нему единоличного доступа. Плюс хранится (для прокурора) вся история обработки запросов, с ЭЦП операторов.

                                Согласно RFC 3280 СОС (CRL) может быть подписан самим CA, т.е. теми ключами... и т.п.
                                Т.е. не обязательно ключем того же издателя.
                                Хотя, это зависит от реализации. В NotaryPRO, например, CRL подписуется только тем ключем, которым выпускался соответствующий сертификат.
                                Earl Vlad Drakula. ///

                                Комментарий


                                • #17
                                  Сообщение от Zuz
                                  2 Serge3:
                                  1. Легко сказать, закрытый ключ уничтожается... а кто даст гарантию, что не было сделано копии?
                                  И, кстати, в софте такая реализация есть?
                                  Есть. А на счет гарантий, то возможно разделять ключи и/или использовать HSM.
                                  Сообщение от Zuz
                                  Что-то у Microsoft я такого в их реализации PKI не нашел (не надо ногами пинать, вполне нормальное решение ;-)
                                  Действительно, MS CA такими возможностями не обладает.
                                  Сообщение от Zuz
                                  2. Serge3 пожалуйста ответьте на эти и ранее поставленные вопросы более подробно, как специалист (особенно интересно, про нескольких ответственных лиц и несколько сертификатов УЦ, если не сложно дайте более конкретные ссылки в RFC 3280 чего-то не нашел про это)!
                                  Скажем так, RFC 3280 нигде не высказывает требования на единственность ключа и сертификата УЦ. А в необходимых местах рассматривает особенности обработки самоподписанных (self-signed) и самовыпущенных (self-issued) сертификатов, наиболее важные места: построение цепочек в разделе 6.1 и проверка СОС (CRL) в раздел 6.3.3. А частный случай смены ключа корневого УЦ подробно рассматривается в RFC 2510 раздел 2.4.
                                  Сообщение от Zuz
                                  Посмотрел Ваш УЦ упоминаний о таких процедурах не нашел (как и регламента, который упомянут на первой странице сайта ;-(
                                  "КриптоПро УЦ" был рассчитан на обслуживание небольшим штатом сотрудников, в частности он поддерживает только одно уполномоченное лицо, соответственно ему эти процедуры не нужны (кроме уничтожения ключа, эта процедура описана в документации на "КриптоПро CSP"). На наш взгляд такие небольшие УЦ наиболее востребованы рынком.

                                  У нас есть изделия, рассчитанные на большой штат (8 человек и более), я надеюсь, что в ближайшее время мы анонсируем коммерческую версию.
                                  Сообщение от Zuz
                                  3. Про SSL сервер, но ведь в конкретный момент времени активен сертификат одного оператора?
                                  Конечно, просто можно каждого оператора обязать отвечать за свой ключ и его сохранность. И нет необходимости устраивать "коллективную безответственность".
                                  Сообщение от Zuz
                                  4. Можно вопрос к Вам, как представителю Crypto Pro? Если в качестве ключевого контейнера используется eToken R2 или Pro (естественно в вашей реализации криптопровайдера и поддержки этих устройств), насколько просто сделать копию с такого носителя зная пароль к eToken'у?
                                  Если экспорт ключа разрешен, то это можно сделать из панели управления "КриптоПро CSP".
                                  Если нет, то зная пароль и/или имея ключ(и) защиты можно, в принципе, разработать утилиту копирования.
                                  Сообщение от Zuz
                                  Можно ли этого избежать, если нет, есть ли USB устройство подобного класса с требуемыми мне характеристиками?
                                  Не очень понял, какие характеристики Вам требуются.
                                  Успехов
                                  Леонтьев Сергей, lse@CryptoPro.ru, Крипто-Про

                                  Комментарий


                                  • #18
                                    Сообщение от hugevlad
                                    Serge3
                                    Сложный - ключ уполномоченного лица в хранится HSM зашифрованный на ключе смарт-карточки уполномоченного лица и ключах защиты от НСД по схеме 3 смарт-карточки из 5 возможных;
                                    Вот я именно такую схему и хочу. Самоподписанный сертификат СА выпадает из ХСМ, а соответствующий секретный ключ рождается в этом ХСМ и никогда его не покидает. (в скобках ехидно напомню, что кто-то в ру.крипт говорил, будто ХСМ не нужен, пентиум неплохо справляется )
                                    Это с точки зрения производительности HSM не нужен.
                                    Сообщение от hugevlad
                                    Затем коллегиально сертифицируем ключики операторов УЦ (человек 5-10 ) и объясняем СА, что ежели приходит запрос на сертификат, заверенный одним из этих 10 ключей, то отдавать его на сертификацию в ХСМ. В такой схеме при увольнении одного из операторов, его серт спокойно отзывается, но компрометации самого главного ключа не происходит, потому что никто не имеет к нему единоличного доступа.
                                    Мне ближе позиция ФЗ "Об ЭЦП" об личной ответственности за использование ключа, а HSM и ключевые схемы разделения могут применяться для гарантированного уничтожения ключа и уменьшения вероятности явной или неявной компрометации ключа.
                                    Сообщение от hugevlad
                                    Плюс хранится (для прокурора) вся история обработки запросов, с ЭЦП операторов.
                                    Хм. Прокурор работает с документами, быть может и с электронными документами, а не с "историями", именно поэтому Ваша схема не так хороша, как могла бы.
                                    Сообщение от hugevlad
                                    Согласно RFC 3280 СОС (CRL) может быть подписан самим CA, т.е. теми ключами... и т.п.
                                    Т.е. не обязательно ключем того же издателя.
                                    Хотя, это зависит от реализации. В NotaryPRO, например, CRL подписуется только тем ключем, которым выпускался соответствующий сертификат.
                                    Не всем надо такой огород городить.
                                    Успехов
                                    Леонтьев Сергей, lse@CryptoPro.ru, Крипто-Про

                                    Комментарий


                                    • #19
                                      2 Serge3:
                                      Насколько я понял HSM это Hardware Security Module?
                                      Хотелось бы подробнее узнать о реализации - в каких реализациях PKI можно использовать? Например, как это реализовано у Вас и есть ли такие решения для PKI в реализации Microsoft? Кто предлагает такие решения?
                                      Также интересно в каких реализациях PKI учтены Вами выше изложенные требования?

                                      Про требования к USB устройству: оно должно исключать возможность копирования закрытого ключа.

                                      Комментарий


                                      • #20
                                        Serge3
                                        Мне ближе позиция ФЗ "Об ЭЦП" об личной ответственности за использование ключа
                                        А где противоречие? "Самый главный ключ" (aka корневой сертификат) можно сделать на директора УЦ (вероятность увольнения которого существенно меньше, чем оператора). Но директор сам им врядли будет оперировать, посему посадить ключик в ХСМ...

                                        Хм. Прокурор работает с документами, быть может и с электронными документами, а не с "историями", именно поэтому Ваша схема не так хороша, как могла бы.
                                        А что есть "история"? Набор электронных документов с цифровой подписью.
                                        Не вижу причин, по которым CMS-сообщения (RFC 2797 и 3369) нельзя было бы отнести к документам.

                                        Не всем надо такой огород городить.
                                        Согласен, что не всем. Но все-таки, достаточно востребовано. Самый простой пример - банковские системы. Клиентов много, смена ключей/сертификатов иден равномерно в течение всего года, также надо периодически менять ключи серверов. Любая схема, обеспечивающая "плавность хода" очень болезненно отреагирует на внеплановую смену ключа УЦ - клиенты просто порвут, как Тузик грелку, если их вдруг оповестить "у нас уволилось должностное лицо УЦ, посему всем надо срочно прийти и поменять сертификаты". Они насчет плановой смены 1 раз в год и то возмущаются...
                                        Earl Vlad Drakula. ///

                                        Комментарий


                                        • #21
                                          Сообщение от Zuz
                                          2 Serge3:
                                          Насколько я понял HSM это Hardware Security Module?
                                          Хотелось бы подробнее узнать о реализации - в каких реализациях PKI можно использовать? Например, как это реализовано у Вас и есть ли такие решения для PKI в реализации Microsoft? Кто предлагает такие решения?
                                          Да, HSM - это Hardware Security Module.
                                          Нет проблем использовать его совместно с ПО от Microsoft.
                                          Сообщение от Zuz
                                          Также интересно в каких реализациях PKI учтены Вами выше изложенные требования?
                                          Извините, но мне трудно делать независимый обзор. На пример, у нас есть изделия, поддерживающие несколько уполномоченных лиц (я их уже упоминал ранее).
                                          Сообщение от Zuz
                                          Про требования к USB устройству: оно должно исключать возможность копирования закрытого ключа.
                                          Мне неизвестны персональные носители ключевой информации, которые полностью гарантировали бы исключение возможности считывания/копирования закрытого ключа (особенно лицом знающим PIN-код).

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

                                          Для "КриптоПро CSP"/"КриптоПро УЦ" Вы можете при создании ключа УЦ указать контейнер Flash-USB, указать в место "установки нового пароля" "установить новый ключ" расположенный на eToken R2 или Pro, который также защищён PIN-кодом (собственно здесь можно не фиксироваться на USB). Либо использовать более изощрённые схемы разделения ключа и доступа к нему. В результате для копирования закрытого ключа потенциальному нарушителю потребуется иметь достаточное количество ключевых носителей и знать соответствующие им PIN-коды. Кроме того, усиливаются гарантии уничтожения ключа при необходимости таковой.
                                          Последний раз редактировалось Serge3; 17.03.2004, 01:58.
                                          Успехов
                                          Леонтьев Сергей, lse@CryptoPro.ru, Крипто-Про

                                          Комментарий


                                          • #22
                                            Сообщение от hugevlad
                                            Serge3
                                            Мне ближе позиция ФЗ "Об ЭЦП" об личной ответственности за использование ключа
                                            А где противоречие? "Самый главный ключ" (aka корневой сертификат) можно сделать на директора УЦ (вероятность увольнения которого существенно меньше, чем оператора).
                                            Однако, она не нулевая.
                                            Сообщение от hugevlad
                                            Но директор сам им врядли будет оперировать, посему посадить ключик в ХСМ...
                                            Человек, отвечающий за бизнес вправе сам определять порядок ведения дел, соответственно он может установить эту схему. Но зачем его ограничивать только этой схемой? Возможно, ему потребуется, что бы без его личного контроля (или контроля его заместителей или уполномоченных лиц) ни один документ (сертификат) не должен быть подписан.
                                            Сообщение от hugevlad
                                            Любая схема, обеспечивающая "плавность хода" очень болезненно отреагирует на внеплановую смену ключа УЦ - клиенты просто порвут, как Тузик грелку, если их вдруг оповестить "у нас уволилось должностное лицо УЦ, посему всем надо срочно прийти и поменять сертификаты". Они насчет плановой смены 1 раз в год и то возмущаются...
                                            При плановой смене ключей уполномоченных лиц УЦ в соответствии с RFC 3280 и RFC 2510 совместимые клиенты ничего не заметят. Т.к. сертификаты уполномоченных лиц не отзываются и не требуют немедленной замены на стороне клиента, таким образом, может быть обеспечено плавное течение дел клиентов при любых кадровых перестановках на стороне УЦ.
                                            Успехов
                                            Леонтьев Сергей, lse@CryptoPro.ru, Крипто-Про

                                            Комментарий


                                            • #23
                                              Serge3
                                              При плановой смене ключей уполномоченных лиц УЦ в соответствии с RFC 3280 и RFC 2510 совместимые клиенты ничего не заметят. Т.к. сертификаты уполномоченных лиц не отзываются и не требуют немедленной замены на стороне клиента, таким образом, может быть обеспечено плавное течение дел клиентов при любых кадровых перестановках на стороне УЦ.
                                              Есть один тонкий момент: как эти клиенты будут взаимодействовать с другими клиентами/серверами, сертификаты которых выпущены уже на новом ключе УЦ?
                                              Мы у себя придумали хитрую схему с перекрытиями, если все штатно, то все идет плавно и прозрачно для юзеров, но в случае внеплановой смены ключа УЦ - кирдык.
                                              Earl Vlad Drakula. ///

                                              Комментарий


                                              • #24
                                                Сообщение от hugevlad
                                                Serge3
                                                Есть один тонкий момент: как эти клиенты будут взаимодействовать с другими клиентами/серверами, сертификаты которых выпущены уже на новом ключе УЦ?
                                                Все самоподписанные сертификаты уполномоченых лиц связанны самовыпущеными сертификатами, которые могут храниться в сетевом справочнике и/или передаваться с сообщениями. При этом "старые" клиенты могут построить цепочки до "старых" самоподписанных сертификатов из доверенного хранилища, а "новые" до "новых". Подробности процесса построения цепочек смотрите выше упомянутые RFC.
                                                Последний раз редактировалось Serge3; 17.03.2004, 10:18. Причина: Синтаксис
                                                Успехов
                                                Леонтьев Сергей, lse@CryptoPro.ru, Крипто-Про

                                                Комментарий


                                                • #25
                                                  Serge3
                                                  Рискую показаться тупым, тем не менее спрошу
                                                  Что значит "Все самоподписанные сертификаты уполномоченых лиц связаны самовыпущеными сертификатами"?
                                                  Что-то я не очень догоняю разницу между self-signed и self-ussued.
                                                  Или имеется ввиду, что новый и старый сертификаты делают между собой кросс?
                                                  Earl Vlad Drakula. ///

                                                  Комментарий


                                                  • #26
                                                    Более интересен вопрос (в терминологии Леонтьева) как "старые" пользователи будут проверять CMS подписанные "новыми" пользователями. Придется делать либо кросс между старым и новым корнем либо организационно (доверенная доставка) раздавать новый корень - старым, а старым - новый, верить тому что в LDAPe лежит самоподписанный сертификат нельзя.

                                                    Комментарий


                                                    • #27
                                                      Sergey_Murugov
                                                      Придется делать либо кросс между старым и новым корнем либо организационно (доверенная доставка) раздавать новый корень
                                                      Мы сделали проще: сертификат пользователю печем на "текущем" сертификате УЦ, серверный сделан на "прошлогоднем". Обоим (и серверу, и клиенту) даем сразу оба корня. Сроки подобраны так, что даже если придется менять сертификат сервера, клиенты все равно смогут его проверить, а до следующей смены уже поменяют свой сертификат и получат новый корень.
                                                      Несколько сумбурно, сорри.
                                                      В общем, нормально, если не приключится компрометации.
                                                      Если мы правильно поняли суть идеи Сергея Леонтьева (кросс старого с новым), то по безопасности схема эквивалентна, и тоже очень боится компрометации корня.
                                                      Earl Vlad Drakula. ///

                                                      Комментарий


                                                      • #28
                                                        В приведенных Rfc насколько я помню о кроссах не говорится и Леонтьев этих слов не произносил. Он имел ввиду что то другое.
                                                        О компрометации корня - самое чуствительное в Pki что может произойти, тут спору нет. А как минимизировать последствия, чтобы не было ни "Тузика ни грелки" - вот вопрос.

                                                        Комментарий


                                                        • #29
                                                          Сообщение от hugevlad
                                                          Serge3
                                                          Рискую показаться тупым, тем не менее спрошу
                                                          Что значит "Все самоподписанные сертификаты уполномоченых лиц связаны самовыпущеными сертификатами"?
                                                          Что-то я не очень догоняю разницу между self-signed и self-ussued.
                                                          Самоподписанный сертификат (смотрите RFC 3280, п. 6.1):
                                                          When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path. Information about trust anchors are provided as inputs to the certification path validation algorithm (section 6.1.1).

                                                          Самовыпущенный сертификат (смотрите RFC 3280, п. 6.1):
                                                          A certificate is self-issued if the DNs that appear in the subject and issuer fields are identical and are not empty. In general, the issuer and subject of the certificates that make up a path are different for each certificate. However, a CA may issue a certificate to itself to support key rollover or changes in certificate policies. These self-issued certificates are not counted when evaluating path length or name constraints.

                                                          Сообщение от hugevlad
                                                          Или имеется ввиду, что новый и старый сертификаты делают между собой кросс?
                                                          Нет.

                                                          Кросс-сертификат (смотрите RFC 3280, п. 3.5):
                                                          (g) cross-certification: Two CAs exchange information used in establishing a cross-certificate. A cross-certificate is a certificate issued by one CA to another CA which contains a CA signature key used for issuing certificates.

                                                          Они несколько отличаются от самовыпущенных сертификатов, особенно в части проверки СОС (списков отозванных сертификатов).
                                                          Успехов
                                                          Леонтьев Сергей, lse@CryptoPro.ru, Крипто-Про

                                                          Комментарий


                                                          • #30
                                                            Сообщение от Sergey_Murugov
                                                            Более интересен вопрос (в терминологии Леонтьева) как "старые" пользователи будут проверять CMS подписанные "новыми" пользователями.
                                                            Этот вопрос рассмотрен в RFC 3280. Грубо говоря, построит цепочку через самовыпущенный сертификат "новый" на "старом" до одного из "старых" самоподписанных сертификатов из своего доверенного хранилища.
                                                            Сообщение от Sergey_Murugov
                                                            Придется делать либо кросс между старым и новым корнем либо организационно (доверенная доставка) раздавать новый корень - старым, а старым - новый, верить тому что в LDAPe лежит самоподписанный сертификат нельзя.
                                                            В сетевом справочнике самоподписанные сертификаты храниться не должны. Там могут храниться самовыпущенные сертификаты, так же они могут передаваться в составе сообщений (CMS, TLS и т.п.).

                                                            Доверенные хранилища сертификатов клиентов должны обновляться, но, в данном случае, периодичность их обновления может определяться не периодом смены закрытых ключей уполномоченных лиц, а сроком действия их открытых ключей.
                                                            Последний раз редактировалось Serge3; 18.03.2004, 01:02. Причина: Уточнение
                                                            Успехов
                                                            Леонтьев Сергей, lse@CryptoPro.ru, Крипто-Про

                                                            Комментарий

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

                                                            Свернуть

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

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