16 декабря, воскресенье 12:57
Bankir.Ru

Объявление

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

Атрибутные сертификаты в банках

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

  • Атрибутные сертификаты в банках

    Хочется выделить из соседнего топика данный вопрос для обсуждения.
    В соседнем топике плавно пришли к тому, что пихать все подряд в сертификат открытого ключа ЭЦП - нелогично. А информация дополнительная нужна. Для решения этой проблемы логично использовать атрибутные сертификаты в соответствии с RFC 3281.
    Атрибутный сертификат отличается от сертификата открытого ключа тем, что в нем нет открытого ключа пользователя, а только ссылка на сертификат открытого ключа и атрибут(ы). Т.е. если сертификат открытого ключа это как бы "паспорт", то атрибутный сертификат это типа "пропуска" (владельцу паспорта такого-то можно туда-то).
    Вот
    Собственно, предлагается обсудить, какие именно атрибуты логично запихивать в атрибутники применительно к банкам.
    У меня ход мысли примерно такой:
    1) В subject сертификата открытого ключа помещаем псевдоним (обеспечивая на всю жизнь постоянный CN и конфиденциальность личных данных, т.к. этот сертификат должен быть в открытом справочнике)
    2) Выпускаем атрибутник с alternate name (реальные ФИО, которые могут меняться в некоторых случаях)
    3) При необходимости можно выпустить атрибутник и с ПД (либо вложить их в атрибутник с ФИО).
    4) Доступ к определенным счетам дается путем выпуска атрибутника, в расширениях которого указывается номер счета.

    Вы спросите: а зачем все это обсуждать? На что я отвечу: поскольку у банков специфичные пожелания к доп. информации, которую хочется иметь в расширениях сертификата (в данном контексте - атрибутного), и "стандартные" расширения не удовлетворяют, то во избежание всяких конфликтов по совместимости их лучше бы по максимуму формализовать, т.е. изладить нечто вроде "профиля", дабы разработчики СКЗИ/PKI не несли отсебятину, а сделали удобный продукт и зарегистрировали стандартные OID под это дело.
    Earl Vlad Drakula. ///

  • #2
    Если вы о корпоративном УЦ, то почему у вас основной сертификат в открытом справочнике? Предоставьте доступ к УЦ только для участников корпоративной системы и указывайте ФИО и ПД в основном сертификате.
    И зачем вам атрибутный сертификат, ведь вы информацию о клиенте держите в базе данных?

    Комментарий


    • #3
      Что-то и я не вижу необходимости в каких-то дополнительных (атрибутных)сертификатах как для банка (корпоративной системы) так и для открытых УЦ
      Если не трудно поясните, желательно на примере.

      Комментарий


      • #4
        ToJoint: Что, опять про ПД? Об этом же говорилось в соседней теме и вам пытались объяснить, что очень нетехнологично укладывать в долгосрочный документ атрибуты, которые могут измениться в не предсказуемый момент времени и что раскрывать персональную информацию не хорошо, ее как раз по трехглавому закону вы должны защищать. Более того переиздание сертификата регламентируется ФЗ Об ЭЦП и до сих пор ясности нет как это делать правильно, а атрибутные сертификаты – совсем другое дело – ничего не публикуется в открытом доступе и переиздание по внутренним правилам банка.
        По поводу СУБД, да именно так сейчас все и делают – каждый по своему, а АА – это стандартное решение и весьма технологичное.
        И вопрос в теме по моему интересен – на основе опыта работы всех форумян попытаться создать типовые профили для физлиц, юрлиц и обслуживающего персонала в приложении к банковской сферы деятельности.

        Комментарий


        • #5
          Sergey_Murugov: очень нетехнологично укладывать в долгосрочный документ атрибуты, которые могут измениться в не предсказуемый момент времени и что раскрывать персональную информацию не хорошо

          О чем вы? Сертификат выдается на год, паспорт за всю жизнь меняется раза 3-4.
          К тому же вы так и не сказали, почему ПД являются конфиденциальной информацией? Что злоумышленник может сделать, если узнает ваши ПД?

          Комментарий


          • #6
            ToJoint: давайте по второму кругу не затевать про ПД, посмотрите предыдущий топик – там все написано и про возможность использование ПД и их смену и смену ФИО и т.д. Разумное желание иметь долгоживущее доверенное удостоверение связанное именно с персоной, а не с ее характеристиками (женат, потерял паспорт, сменил паспорт (мне 46 лет и я к примеру уже за последние 4 года его два раза менял – паспортная реформа помогла, на кой мне помимо геморроя с милицией еще и в УЦ бегать). Вопрос был поставлен про АА. Почему это технологично, тоже наверное понятно – автоматизированная система становится отвязанной от организационной. При использовании АА вам фактически все равно кто издал (лишь бы вы доверяли издателю) сертификат пользователя – публичный УЦ, корпоративны или УЦ какого то объединения, у вас ведь в банковском секторе есть что то типа ассоциации, возьмут завтра придумают выпускать сертификаты – ваши действия? И сразу становятся бессмысленны пассажи на тему: а нужен ли публичный УЦ или нет – «жизнь внесет свои коррективы».

            Комментарий


            • #7
              Joint
              Если вы о корпоративном УЦ
              Если сбудется Ваша мечта - то я об УЦ общего пользования
              И зачем вам атрибутный сертификат, ведь вы информацию о клиенте держите в базе данных?
              Угу. И подписываю связки ЭЦП. Т.е., фактически, тот же самый атрибутник, только на коленке сделанный.

              Alex Novikov
              Если не трудно поясните, желательно на примере
              Мария Пупкина является влиентом банка как частный вкладчик. А еще она имеет право распоряжаться счетами 10 фирм, счета которых в этом же банке (директор там она, финдиректор или главбух).
              Если в CN сертификата открытого ключа забить ФИО, то если Пупкина выйдет замуж и сменит фамилию, сертификат не будет соответствовать действительности. Он будет действительным, но неудобным в использовании для приложений, которые читают CN.
              Если в CN вбить только псевдоним (типа USR120589) и выпустить ссылающийся на него атрибутник с ФИО, то при смене фамилии достаточно перевыпустить только атрибутник, на заморачиваясь с сертификатом открытого ключа.
              Аналогично со сменой ПД в середине срока действия ключа.
              Далее, если в расширения сертификата открытого ключа запихивать, например, номера счетов, которыми может рулить мадам Пупкина, то при увольнении ее с должности финдиректора одной из фирм придется переиздавать сертификат открытого ключа. В случае атрибутника - отзывается конкретный атрибутник.
              Собственно, атрибутный сертификат это подписанная пара "субъект - свойство/право". И свойства, которые в течение срока действия сертификата открытого ключа могут поменяться, логично записывать в атрибутник.
              Все равно в каждой системе есть некая табличка с кучей строк "субъект-свойство", и очень мало кто защищает ее ЭЦП. Но даже если и защищают, зачем ваять на коленке, когда есть типовое решение?
              Earl Vlad Drakula. ///

              Комментарий


              • #8
                http://ats.cryptopro.ru/ra/cdp/reglament.rtf
                1. 1.3.6.1.4.1.18545.1.1.1.1 Подписывание документов руководителем организации
                2. 1.3.6.1.4.1.18545.1.1.1.2 Подписывание документов главным бухгалтером
                3. 1.3.6.1.4.1.18545.1.1.1.3 Подписывание документов заместителем руководителя организации
                ...
                15. 1.3.6.1.4.1.18545.1.1.1.15 Подписывание отказа от подписания отчета комиссионера;
                16. 1.3.6.1.4.1.18545.1.1.1.16 Подписывание счета-фактуры на электроэнергию.
                ...
                108. 1.3.6.1.4.1.18545.1.1.5.5 Подписывание файла XML формата, содержащего информацию о состояниях объектов измерений

                Комментарий


                • #9
                  Ничего не понимаю ....
                  Посмотрел за кем закреплена база OID 1.3.6.1.4.1.18545
                  http://www.iana.org/assignments/enterprise-numbers
                  и вижу
                  18545
                  NONPROFIT PARTNERSHIP ADMINISTRATOR OF TRADE SYSTEM
                  Aleksander Lashmanov
                  law@rosenergo.com
                  Он что к банкам какое то отношение имеет?
                  И в Регламенте КриптоПРО - весь этот список при каких то условиях может быть использован?
                  Мне казалось в банковской карточке как то проще :-(

                  Комментарий


                  • #10
                    1. Атрибутные сертификаты - это не сертификаты ключей подписи и НИКАКОГО отношения к ЭЦП, регулируемой ФЗ "Об ЭЦП" не имеют.
                    2. Регламент услуг УЦ ООО "КРИПТО-ПРО", приведенный коллегой, это регламент предоставления услуг для конкретной определенной корпоративной информационной системы сектора свободной торговли оптового рынка электроэнергии. Ессно, что для банковской системы будет другой Регламент...
                    3. Для Sergey_Murugov: Как ни странно, это все, с таким количеством OID, в системе работает :-)) И очень хорошо работает. Объем торгов более 11 млн. долларов...

                    Резюме: обсуждаемая тема (АА) к применению электронной цифровой подписи в условиях равнозначности ЭЦП собственноручной подписи (а именно это регулируется ФЗ "Об ЭЦП") НИКАКОГО ОТНОШЕНИЯ НЕ ИМЕЕТ!

                    Комментарий


                    • #11
                      А никто к ФЗ Об ЭЦП атрибутные сертификаты и не привязывает - у них назначение совершенно другое.
                      Внимательно перечитайте сообщения.
                      Задача этой темы как следует из первого поста, попытаться создать профиль атрибутного сертификата в приложении к банковскому сектору, не надергивать из разных регламентов и мест неописаныые OID, а их создать, описать и обсудить.

                      Комментарий


                      • #12
                        Uri_Maslov
                        Атрибутные сертификаты - это не сертификаты ключей подписи и НИКАКОГО отношения к ЭЦП, регулируемой ФЗ "Об ЭЦП" не имеют.
                        А с этим кто-то спорит?

                        обсуждаемая тема (АА) к применению электронной цифровой подписи в условиях равнозначности ЭЦП собственноручной подписи (а именно это регулируется ФЗ "Об ЭЦП") НИКАКОГО ОТНОШЕНИЯ НЕ ИМЕЕТ!
                        И?

                        Если Вы не поняли, то ЭЦП и з-н об ЭЦП это "про паспорт", а АА - это "пропуск для владельца паспорта". Собственно, форму пропуска и пытаемся обсудить
                        Earl Vlad Drakula. ///

                        Комментарий


                        • #13
                          hugevlad: Если сбудется Ваша мечта - то я об УЦ общего пользования

                          Хорошо, тогда я буду говорить о сведениях в публичных сертификатах .

                          Начнем с физлиц.

                          Если посмотреть на документы, которые подписывают физлица, то обнаружится, что в большинстве из них присутствуют ФИО, паспортные данные и адрес. Поэтому, было бы логичным включить все эти сведения в сертификат физлица. ФИО и ПД должны там быть еще и потому, что они позволяют однозначно идентифицировать владельца сертификата.
                          Однако, стоит также учитывать следующие факторы: актуальность и конфиденциальность .

                          Лично я не считаю ПД конфиденциальной информацией, однако для тех, кто думает иначе, в топике "Регистрация сертификатов в СДБО и PKI" (http://dom.bankir.ru/showthread.php?t=50764) предложен следующий выход: в сертификате оставить только ФИО, а ПД указывать в XML-справке, где также будет ссылка на сертификат. Данная справка должна подписываться УЦ, т.к. только УЦ может связать сертификат и ПД его владельца. Конфиденциальность сохраняется тем, что данную справку УЦ имеет право выдавать только владельцу сертификата. И далее уже владелец решает, кому пересылать данную справку, как приложение к подписанному документу.
                          Поддержка актуальности сведений ПД в сертификате (или справке) также возлагается на УЦ. О технической возможности этого уже говорилось в вышеупомянутом топике. УЦ должен отзывать сертификаты, если паспорта, на основании которых они были выданы, станут недействительными.

                          Теперь, что касается адреса.
                          Справку с адресом, думаю, можно будет получить на сайте МВД. Т.к. информация в справке конфиденциальная, то выдавать ее должны только тому, чей адрес указан в самой справке. Определяется это, разумеется, по сертификату, хотя в самой справке сертификат можно и не указывать - только ФИО, ПД и адрес.
                          В зависимости от способа поддержки актуальности, возможно 2 типа справки. Наиболее простой тип - справка с ограниченным сроком действия, которая требует от получателя справки и МВД минимум телодвижений. Второй тип - справка с возможностью отзыва. Тут МВД берет на себя ответственность за своевременную отмену справки, а получатель справки обязан проверять ее действительность.

                          Что еще может быть в сведениях сертификата физлица?

                          Допустим, семейное положение. Но зачем его указывать в сертификате, если всегда можно будет получить соответствующую справку на сайте загса?

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

                          Дата рождения? Может и пригодится где-нибудь. А где-то затребуют электронную копию свидетельства о рождении.

                          Банковский счет? Та же справка, только из банка (как защитная мера от хакеров).

                          Номер кредитной карты ?

                          to Uri_Maslov

                          Вашу систему я упомянул в качестве примера того, как не следует поступать. Если для анонимных сертификатов hugevlad'а вся информация содержится в базе, то у вас сведения, которые логичнее хранить в базе, занесены в сертификат .

                          Комментарий


                          • #14
                            To Joint: а давайте поступим так, мы не будем обсуждать (уточнять) в каком сертификате (открытого ключа или атрибутном) находятся расширения или каким иным способом получаются, а просто сформируем их список с описанием и обсудим в приложении именно банковского сектора, а не абстрактной системы торгов или е-коммерции.
                            Итак, на сегодня для физлица есть:
                            1. ФИО
                            2. ПД
                            3. Адрес
                            4. ИНН
                            5. Семейное положение
                            6. Что то из свидетельства постановки на учет в налоговой
                            7. дата рождения
                            8. Банковский счет
                            9. ? Номер кредитки
                            Еще есть какие нибудь мысли?

                            Комментарий


                            • #15
                              Sergey_Murugov: а давайте поступим так, мы не будем обсуждать (уточнять) в каком сертификате (открытого ключа или атрибутном) находятся расширения или каким иным способом получаются

                              В том-то и дело, что этот вопрос принципиален.

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

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

                              Если кому-то нужно, чтобы сведения о клиенте в базе данных были подписаны, то это должна быть подпись операциониста, который эти сведения заносит. И сделать это очень просто. Достаточно завести в таблице, записи которой должны подписываться, дополнительное поле "sign" . А если подписывать нужно поля нескольких таблиц, то потребуется дополнительная таблица с перечнем полей, которые участвуют в подписи.

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

                              А в сертификатах для юрлиц должна содержаться только та информация, которая необходима для заключения договора сторонами, когда ни у одной из сторон в базе данных нет информации о другой стороне. А именно:
                              - ФИО
                              - ПД
                              - должность
                              - № и дата доверенности (если это зам.)
                              - наименование фирмы
                              - юридический адрес фирмы
                              - банковские реквизиты фирмы
                              - контактные телефоны, факс, email

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

                              Комментарий


                              • #16
                                To Joint: Я не служу в банке и поэтому уж извините меня за вопросы, которые может быть для вас вполне очевидны, а для меня нет.

                                Давайте, все таки вернемся к теме.
                                Мы НЕ рассматриваем регламент заключения дистанционного договора как элемента е-коммерции, мы НЕ рассматриваем процедуру (перечень документов) при первичной регистрации в банке физлица или юрлица, т.е. то что нужно чтобы открыть счет.
                                Мы рассматриваем минимальный набор атрибутов (характеристик) субъекта доступа при автоматизированной обработке запроса, который бы позволил не обращаясь к базе с первичными документами (по всей видимости это и не нужно делать каждый раз когда приходит платежка) мог бы однозначно связать: атрибуты платежки, субъекта доступа (идентификация субъекта доступа сейчас НЕ рассматриваем, в это вовлечен сертификат открытого ключа) со специфическими характеристиками счета для выполнении банком своих обязанностей.
                                Про преимущества работы через атрибутные сертификаты – носителя данной информации тут много раз говорилось, повторюсь:
                                1. удобство в обслуживании субъекта доступа – обладателя нескольких счетов
                                2. технологическая независимость от сертификата открытого ключа, периодичности его создания-переиздания, его издателя и состава.
                                3. полная самостоятельность банка в определении состава, регламента обращения, политики применения и т.п. атрибутного сертификата.
                                4. существенная экономия средств, поскольку нет необходимости сопровождать самим PKI систему, нет технологической необходимости самим содержать УЦ.
                                5. поскольку база с клиентами и информацией о них наверное достаточно охраняемый компонент банковской системы, то для процедур не требующих доступа к первичным документам, доступ к базе даже на чтение закрыт.
                                6. использование данной технологии не только при определении политике доступа клиента банка к собственному счету, но и использование специальных профилей для назначения ролевых признаков обслуживающего персонала по допуску к банковским информационным ресурсам.
                                7. информация об указанных атрибутах защищена ЭЦП.
                                Наверное еще что то можно написать, но я думаю этого вполне достаточно, чтобы данный топик имел право на жизнь.

                                Комментарий


                                • #17
                                  to Sergey_Murugov

                                  Возможно некоторое недопонимание у нас возникло потому, что в топике смешиваются два вопроса:

                                  1. Какая информация должна быть представлена в сведениях сертификата, а какая информация остается в базе данных информационной системы?
                                  2. Имеет ли смысл дублировать информацию базы данных в так называемых атрибутных сертификатах?

                                  На первый вопрос, в силу своего представления, я вроде ответил.
                                  Чтобы ответить на второй вопрос, нужно четко понимать, что из себя представляет атрибутный сертификат. Как здесь уже говорилось, атрибутный сертификат (АА) сертификатом собственно и не является, т.к. в нем нет открытого ключа и он не предназначен для проверки подписи.
                                  АА - это обыкновенный электронный документ примитивной структуры (не XML), который подписывается владельцем информационной системы (в нашем случае, банком). Причем, как следует из ваших слов, данный владелец может и не являться собственником УЦ, на сертификат которого ссылается АА.
                                  Поэтому второй вопрос нужно переформулировать:
                                  2. Имеет ли смысл дублировать информацию базы данных в электронных документах, подписанных банком, которые будут находиться в некоем хранилище АА?

                                  В общем случае информационная система банка имеет две базы данных. Одна из них БД АБС, другая БД СДБО. Если доступ на чтение к первой может быть каким-то образом ограничен, то какой смысл ограничивать доступ ко второй БД?
                                  Потом, хранилище АА - это ведь тоже база данных. Зачем нужна эта третья БД, чем не устраивает БД СДБО?

                                  Далее. Допустим, счета, по которым у должностного лица имеется право подписи, указываются у него в АА. Тогда что, если у фирмы появится новый счет, нужно не только занести этот счет в БД АБС, но и переиздать АА всех должностных лиц с правами 1 и 2 подписи? А ведь это может быть не только директор и главбух. Конечно, можно завести отдельный АА на фирму, а в АА должностных лиц сделать на него ссылку, но не проще ли работать с обычной БД, чем с такими электронными документами?
                                  Кстати, каким образом в АА указывать счета фирмы? Acc1=.., Acc2=.., Acc3=.., ...? А если понадобится кроме счета указать, скажем, дату его открытия или какие-нибудь другие атрибуты счета, так что заводить еще один тип АА - для счета?

                                  В какой-то степени АА напоминает то, что я называю справкой. Только справку выдает одна сторона другой стороне для предъявления третьей стороне. А выдавать справку для использования в собственной информационной системе вместо того, чтобы работать с нормальной базой данных ?

                                  Комментарий


                                  • #18
                                    Joint
                                    Имеет ли смысл дублировать информацию базы данных в электронных документах, подписанных банком, которые будут находиться в некоем хранилище АА?
                                    Немного не так. Дублировать базу, естессно, смысла нет.
                                    Продолжая аналогию с паспортами/пропусками и т.п.
                                    База - это аналог "списка на вахте", где перечислены ФИО и номера паспортов имеющих право входа. А атрибутный сертификат - это все-таки пропуск. Т.е. Атрибутник не вытаскивается из базы, а представляется клиентом при аутентификации (единственное, что надо проверить, это не внесен ли он в CRL).
                                    При таком дизайне в СДБО вообще не нужно хранить базу "кому куда можно". Плюс, такой дизайн повышает безопасность системы:
                                    - таблица в БД с парами "субъект - объект доступа" может быть изменена админом системы; атрибутник же защищен криптографически.
                                    - "выписывает пропуск" один, а проверяет другой, т.е. работает "принцип 4 глаз", сильно снижающий вероятность злоупотреблений.

                                    Отсюда логичное следствие: чтобы юзать АА, дизайн системы должен быть на них ориентирован. Если "прикрутить сбоку на изоленту", то хорошего ничего не будет
                                    Earl Vlad Drakula. ///

                                    Комментарий


                                    • #19
                                      To Joint: По поводу состава АА – этих сертификатов может быть много, связанных с одним сертификатом открытого ключа, именно поэтому очень удобно строить связку: персона – конкретный объект или объекты (или свойства). Для вашего примера, при появлении у фирмы нового счета, просто создается еще один атрибутник (идентифицирующий счет + характеристики персоны к нему допущенной) и связанный с сертификатом открытого ключа субъекта (возможно анонимного по составу информационной части сертификата) доступа к этому счету. При организации доступа по сертификату открытого ключа извлекаются все АА с ним связанные.
                                      По поводу каким образом указывать дату открытия счета в АА или еще чего - указывать через расширения нами выдуманные(атрибуты) атрибутного сертификата - вот собственно и хотелось узнать что разумно заталкивать в АА, например, если никогда не потребуется при автообработке платежки использовать дату открытия счета, то зачем ее тогда писать в АА. Если эта информация когда нибудь может понадобиться, то для этого есть банковская карточка в виде записи в базе или еще как, где это все написано.

                                      Комментарий


                                      • #20
                                        hugevlad: Мария Пупкина является влиентом банка как частный вкладчик. А еще она имеет право распоряжаться счетами 10 фирм, счета которых в этом же банке (директор там она, финдиректор или главбух).
                                        Если в CN сертификата открытого ключа забить ФИО, то если Пупкина выйдет замуж и сменит фамилию..


                                        Ваш пример соответствует моему 1 варианту для юрлиц (http://dom.bankir.ru/showpost.php?p=...&postcount=21), за исключением того, что у меня сертификат именованный. Преимущество данного варианта в том, что если Пупкина работает в 10 фирмах, то ей не нужно заводить 10 служебных сертификатов, достаточно одного личного. Однако при этом Пупкина лишается возможности подписывать вне банка документы от имени фирмы, т.к. в личном сертификате сведения о фирме отсутствуют.
                                        Так вот, если бы в моем варианте использовался анонимный сертификат, а информация о самой Пупкиной и ее фирмах содержалась в базе, то при смене Пупкиной фамилии банку было бы достаточно занести новую фамилию в базу. У вас же банк не только меняет информацию в базе, но и должен переиздать все атрибутные сертификаты Пупкиной. Это к вопросу о дублировании.

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

                                        hugevlad: таблица в БД с парами "субъект - объект доступа" может быть изменена админом системы; атрибутник же защищен криптографически.

                                        Если записи подписаны операционистами, то админ не сможет изменить таблицу.

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

                                        Sergey_Murugov: To Joint: По поводу состава АА – этих сертификатов может быть много, связанных с одним сертификатом открытого ключа, именно поэтому очень удобно строить связку: персона – конкретный объект или объекты (или свойства). Для вашего примера, при появлении у фирмы нового счета, просто создается еще один атрибутник..

                                        Если бы у вас был XML-формат, то не нужно было бы для каждого счета заводить отдельный атрибутный сертификат. Достаточно было бы одного ЭД на фирму, в который занести информацию из карточек с образцами подписей этой фирмы. И назвать такой ЭД, соответственно - КОПс .

                                        И вообще. Если уж связываться с атрибутным сервером, то использовать его нужно по полной программе. В том числе для выдачи справок банком, о чем я здесь уже говорил. Причем справки должны быть нескольких типов:
                                        - с ограниченным сроком действия
                                        - с привязкой к сертификату (опосредованный отзыв)
                                        - без привязки к сертификату, с возможностью непосредственного отзыва

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

                                        Комментарий


                                        • #21
                                          Если бы у вас был XML-формат, то не нужно было бы для каждого счета заводить отдельный атрибутный сертификат.
                                          Гм... Вообще говоря, атрибутный сертификат - это документ в формате ASN.1 (Abstract Syntax Notation).
                                          Этот формат предусматривает несколько кодировок, в т.ч. BER, DER, XER. Последняя - XML Encoding Rules - XML-представление...

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

                                          Комментарий


                                          • #22
                                            to goris

                                            Насколько я понял, hugevlad и Sergey_Murugov не планируют использовать XML в атрибутных сертификатах.

                                            hugevlad: поскольку у банков специфичные пожелания к доп. информации, которую хочется иметь в расширениях сертификата (в данном контексте - атрибутного), и "стандартные" расширения не удовлетворяют, то во избежание всяких конфликтов по совместимости их лучше бы по максимуму формализовать, т.е. изладить нечто вроде "профиля", дабы разработчики СКЗИ/PKI не несли отсебятину, а сделали удобный продукт и зарегистрировали стандартные OID под это дело

                                            Кстати, по этому же вопросу (http://dom.bankir.ru/showpost.php?p=...9&postcount=24)
                                            Сообщение от Serge3
                                            Другое дело, что "атрибутные сертификаты" стандартизированы RFC 3281 для почтовых (CMS, S/MIME) и телекоммуникационных (PPP, TLS) приложений, которые активно работают с ASN.1. А вот стоит ли использовать RFC 3281 для приложений XML, это вопрос? Мы в своих продуктах широко используем ASN.1 XER (XML encoding rule), но приживётся ли такой подход за пределами специфичных для защиты информации задач?

                                            Комментарий


                                            • #23
                                              Насколько я понял, hugevlad и Sergey_Murugov не планируют использовать XML в атрибутных сертификатах.
                                              Но ASN.1-то они наверняка планируют )))
                                              А получить XER из DER - лишь дело техники, по моему...
                                              Ну и пускай АА издает сертификаты в DER-кодировке.
                                              Надо какому-нибудь банку в своих приложениях XML использовать - да ради бога. Конвертация из одной ASN-кодировки в другую - дело, вроде бы, нехитрое!

                                              Комментарий


                                              • #24
                                                to goris

                                                Никаких проблем, если в АА будет нечто подобное

                                                COPS>
                                                CLIENT>ООО Рога и копыта/CLIENT>
                                                COP>
                                                ACCOUNT>40702810010130010079/ACCOUNT>
                                                1SIGNS>
                                                SIGN>
                                                CHIF> Генеральный директор/CHIF>
                                                FIO>Пупкин А.А./FIO>
                                                /SIGN>
                                                SIGN>
                                                CHIF> Первый зам./CHIF>
                                                FIO>Гупкин В.А./FIO>
                                                /SIGN>
                                                /1SIGNS>
                                                2SIGNS>
                                                SIGN>
                                                CHIF> Главбух/CHIF>
                                                FIO>Пупкина А.А./FIO>
                                                /SIGN>
                                                SIGN>
                                                CHIF>Зам. главбуха/CHIF>
                                                FIO>Гупкина В.А./FIO>
                                                /SIGN>
                                                /2SIGNS>
                                                /COP>
                                                /COPS>

                                                Комментарий


                                                • #25
                                                  Опять какая то путаница прорисовывается, итак по порядку.
                                                  1. Субъектом доступа у нас выступает автор либо ЭЦП на Эл. Документе либо владелец сертификата открытого ключа участвующего в образовании сетевого соединения. Еще нет ООО Рога и копыта о нем пока никто не знает – сертификаты анонимные.
                                                  2. Некий колбэк должен извлечь из реестра один или несколько АА соответствующих сертификату открытого ключа и в любом удобном виде все это либо пробросить на прикладной уровень либо на процедуру принятия решения о праве доступа. Именно об этом писал Сергей Леонтьев (CMS и сетевой коннект, TLS например).
                                                  Вопрос темы – каков должен быть состав этого (этих) АА в приложении к банковской деятельности, чтобы процедуры принятия решения и прикладного уровня не лазя больше никуда могли сделать заключение об отбраковки соединения и получили всю необходимую целевую информацию для механизмов дальнейшей обработки электронного документа в системе.
                                                  P.S.
                                                  Создать атрибутник любого состава - не проблема.

                                                  Комментарий


                                                  • #26
                                                    Да, давненько я тут не был... По долгу службы занимался обследованием проблем информационной безопасности Интернет-банкинга в коммерческих банках. Не берусь судить за все банки, но "им бы ваши проблемы"...
                                                    С другой стороны, в свете выхода Стандарта БР по информационной безопасности и готовящегося Технического Регламента по информационной безопасности... ребята! Вы вообще о чём!? У вас забора нет вокруг дома, а спорим о конструкции замка в калитке

                                                    Комментарий


                                                    • #27
                                                      Уважаемый Lee, какую цель Вы преследовали написав ЭТО?
                                                      (нужное подчеркнуть :-) )
                                                      1. Закрыть тему.
                                                      2. Объяснить представителям коммерческих банков в чем у них проблема. Это очень просто – открываете новую тему – и вперед.
                                                      3. Другое.

                                                      Комментарий


                                                      • #28
                                                        Сообщение от Sergey_Murugov
                                                        Уважаемый Lee, какую цель Вы преследовали написав ЭТО?
                                                        (нужное подчеркнуть :-) )
                                                        1. Закрыть тему.
                                                        2. Объяснить представителям коммерческих банков в чем у них проблема. Это очень просто – открываете новую тему – и вперед.
                                                        3. Другое.
                                                        Второе вряд ли востребовано Не думаю, что представители комбанков, присутствующие тут, не знают своих проблем (те, кто не знает, задает вопросы и получает ответы). Просто хотел предложил закрыть тему как не актуальную на данный момент.

                                                        Комментарий


                                                        • #29
                                                          Sergey_Murugov: Субъектом доступа у нас выступает автор .. ЭЦП на Эл. Документе... Еще нет ООО Рога и копыта о нем пока никто не знает – сертификаты анонимные.

                                                          Это пример, когда сертификаты Пупкиных и Гупкиных именованные и все они ссылаются на общий АА для ООО "Рога и копыта". В этом АА производится поиск ФИО из сертификата и определяются полномочия владельца сертификата по списанию со счета, указанного в платежке.
                                                          Если вам нравятся анонимные сертификаты, добавьте в секцию SIGN еще и номер сертификата.

                                                          Комментарий


                                                          • #30
                                                            To Joint: Исходя их технологии АА привязан к сертификату открытого ключа, а не к счету ООО Рога и Копыта. Субъект доступа – это человек - физическое лицо (а не группа лиц – хорошо что вас из ФСБ не слышат за такую крамолу  ) по закону он называется – владелец сертификата. В вот дальше по составу соответствующему ему АА выясняется имеет ли он какое либо отношение к ООО Рогам и копытам от которого он пытается провести платеж (к примеру). Если субъект рулит несколькими счетами и сертификат открытого ключа у него один, т.к. человек один (и в его сертификате как мы ранее договорились нет служебной информации, возможно даже и ФИО нет, что допускает ФЗ Об ЭЦП), то к этому сертификату привязано много АА, каждый из которых описывает статус этой персоны по отношению к конкретному счету, где у него первая подпись, где вторая, где вообще частный вклад и т.д.

                                                            Комментарий

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

                                                            Свернуть

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

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