Comments 41
Глядя на то, как обращаются с ЭП люди, я порой задаюсь вопросом: а не параноик ли я? Может, так и надо? Выдавать ключи и сертификаты в открытом виде на флешке (в лучшем случае, в архиве с паролем). Писать пин-коды на токенах, или оставлять дефолтный 1234. Может, ну их нафиг, эти токены, кому они вообще нужны? Хранить все в реестре! Понапридумывали тут, понимаешь, сложностей. Подписи какие-то, компьютеры, ключи электронные, бабки плати каждый год… Отметки времени еще какие-то, кому они нужны? Вот в кадастровой палате просто выдали сотрудникам сертификаты до 2027 года, зачем заморачиваться с перевыпуском? (а до этого были обычные, сроком на год, поэтому документы росреестра, подписанные в тот период, уже юридически не признать. Кстати, был период, когда они выдавали документы, подписанные просроченной подписью. Где-то месяц.)
Надо быть проще! еще проще! Чтоб самый тупой пользователь смог все подписать, а дальше гори огнём!
Все-таки я, наверное, параноик…
Надо быть проще! еще проще! Чтоб самый тупой пользователь смог все подписать, а дальше гори огнём!
Все-таки я, наверное, параноик…
Абсолютно с вами согласен, но:
Я думаю, мы только в начале пути: на нас сейчас отрабатывают эту технологию, поэтому и складывается впечатление абсурда. Совсем недавно трудно было понять смысл слова «Электронное правительство», теперь это вполне понятные государственные и муниципальные электронные услуги. Но, несмотря на весь прогресс в этой области, существует огромный пласт технических проблем. В качестве примера, приведу, поднятый вами случай: что делать с электронными документами, подписанными уже просроченным сертификатом (ключом). Сейчас они считаются недействительными, то есть у документа есть срок жизни. Представьте себе свидетельство о рождении, которое каждый год надо продлять. Вместе с тем, в Японии каждый совершеннолетний гражданин имел собственную печать еще во времена, когда компьютеров не было. Зачем, когда можно обойтись подписью — спросите вы. Другая культура — другие понятия. Вот и сейчас мы на переломе, когда жить по-старому уже нельзя, а по-новому не получается.
- грамотность пользователей в области ЭП растет на глазах, и это снимает ряд проблем поднятых вами;
- банки демонстрируют возможности совершения операций без ЭП, используя многофакторную идентификацию;
- государство само еще не готово к работе с ЭП, тот пример с сертификатами до 2027 года — наглядное тому подтверждение.
Я думаю, мы только в начале пути: на нас сейчас отрабатывают эту технологию, поэтому и складывается впечатление абсурда. Совсем недавно трудно было понять смысл слова «Электронное правительство», теперь это вполне понятные государственные и муниципальные электронные услуги. Но, несмотря на весь прогресс в этой области, существует огромный пласт технических проблем. В качестве примера, приведу, поднятый вами случай: что делать с электронными документами, подписанными уже просроченным сертификатом (ключом). Сейчас они считаются недействительными, то есть у документа есть срок жизни. Представьте себе свидетельство о рождении, которое каждый год надо продлять. Вместе с тем, в Японии каждый совершеннолетний гражданин имел собственную печать еще во времена, когда компьютеров не было. Зачем, когда можно обойтись подписью — спросите вы. Другая культура — другие понятия. Вот и сейчас мы на переломе, когда жить по-старому уже нельзя, а по-новому не получается.
Чтоб ты жил в эпоху перемен!, — говаривали хитрые китайцы.
Если на момент подписи сертификат просроченный, то подпись действительно должна быть невалидная.
Если же на момент подписи сертификат был валидным, то подпись тоже должна успешно проходить проверку даже после истечения срока жизни сертификата. Для этого используется штамп времени.
Если же на момент подписи сертификат был валидным, то подпись тоже должна успешно проходить проверку даже после истечения срока жизни сертификата. Для этого используется штамп времени.
Для этого нужно доплатить денюжку фирме крипто-про, да и просто знать про эту технологию. Росреестр, увы, или не слышал о таком достижении, или бюрократия не позволила.
Я склоняюсь к версии о тотальной некомпетентности на всех уровнях этого гос.учреждения.
Я склоняюсь к версии о тотальной некомпетентности на всех уровнях этого гос.учреждения.
Вот представьте себе: вы ничего не знаете о криптографии, тут вам приходит грозная бумажка — с завтрашнего дня обеспечить электронную подпись документов. Причем, ни финансирования, ни методических указаний, под этой бумажкой нет. Что делать? Обратиться за помощью в какую-нибудь контору, которая в этом хоть что-то понимает. Из предложенных этой конторой вариантов будет выбран вариант с наименьшими финансовыми вложениями, так как эти деньги отрываются от запланированных ранее затрат. Так что можно говорить не о компетентности какого-то госучреждения в каком-то вопросе, а о непрофессиональности государственного управления.
По поводу того, что нет финансирования — позволю себе не согласиться. На электронные штучки росреестра тратятся огромные деньги (как всегда). Некоторые крупные функционеры даже бегут из страны в связи с этим.
Впрочем, то, что вы описали — это моя мысль другими словами. Непрофессиональность = некомпетентность.
Результат один.
Впрочем, то, что вы описали — это моя мысль другими словами. Непрофессиональность = некомпетентность.
Результат один.
Извините, что неправильно выразился. Федеральные министерства и ведомства возможно и имеют огромные средства для выполнения всех своих эротических фантазий, но почему-то вниз спускают не деньги и конкретные инструкции, а приказы. Так вот, в этой связи глупо обвинять системного администратора или специалиста по работе с клиентами, что они не понимают как надо работать с ЭП.
Да ладно! росреестр — это и есть федеральная структура. Сапельников сбежал в США как раз в связи с информатизацией — публичная карта и т.п. Там на эту программу, емнип, несколько десятков миллиардов потрачено было (еще до отчета счетной палаты, а когда выяснилось, что денежки тютю — еще дали). И свои отдельные подразделения по информатизации там, и люди зарплату получают регулярно,
А по поводу обвинений простых сотрудников — так это очень напоминает ситуацию на почте, тоже, казалось бы, простые люди не виноваты, на мизерную зарплату специалисты не идут, денег нет и т.п. Так я их и не обвиняю особо, к тому же мое исключительно личное мнение (о некомпетентности) основывается не только на эпизодах с просроченной ЭЦП.
Как вам, например, публикация новых ХМL схем через месяц после вступления их в силу? ну и так далее.
Это не ядерная физика, просто обычное, банальнейшее раздолбайство, пофигизм и отрицательный отбор. На всех уровнях.
А по поводу обвинений простых сотрудников — так это очень напоминает ситуацию на почте, тоже, казалось бы, простые люди не виноваты, на мизерную зарплату специалисты не идут, денег нет и т.п. Так я их и не обвиняю особо, к тому же мое исключительно личное мнение (о некомпетентности) основывается не только на эпизодах с просроченной ЭЦП.
Как вам, например, публикация новых ХМL схем через месяц после вступления их в силу? ну и так далее.
Это не ядерная физика, просто обычное, банальнейшее раздолбайство, пофигизм и отрицательный отбор. На всех уровнях.
Спокойно представляю:
У каждой бумажки кроме подписи начальника есть подпись — исполнитель. Я звоню исполнителю с вопросом: WTF?
Он говорит — обратитесь туда. Обращаюсь, узнаю цены — делаю передвижку или запрос дополнительных финансовых средств.
У каждой бумажки кроме подписи начальника есть подпись — исполнитель. Я звоню исполнителю с вопросом: WTF?
Он говорит — обратитесь туда. Обращаюсь, узнаю цены — делаю передвижку или запрос дополнительных финансовых средств.
Главная проблема для такого сервиса — доверие к самому сервису. Никто не мешает владельцу сервиса подписать произвольный документ от имени произвольного пользователя.
Конечно, надо доверять сервису. Так же как надо доверять УЦ. И много кому еще приходится доверять.
Вы же доверяете софту, который фактически осуществляет подпись используя ваши ключи в классическом варианте. Причем, я почти уверен, что вы даже не проверяете, что подписываете. Ведь реально подписывается хэш файла.
Тогда в чем различие доверия к сервису, осуществляющего подпись и доверия к софту делающему то же самое?
Вы же доверяете софту, который фактически осуществляет подпись используя ваши ключи в классическом варианте. Причем, я почти уверен, что вы даже не проверяете, что подписываете. Ведь реально подписывается хэш файла.
Тогда в чем различие доверия к сервису, осуществляющего подпись и доверия к софту делающему то же самое?
И именно поэтому действительно и по-настоящему защищенной системой может считаться только система с «нулевым» доверием. Все прочие, включая и описываемую в статье — всего лишь симулякры…
А таких нет (по-настоящему защищенных). Тот же удостоверяющий центр легко может выпустить любой сертификат. Или у него могут украсть корневой.
Вся эта система, с точки зрения настоящего параноика, уязвима. Но это не повод добавлять туда еще одну дыру.
Вся эта система, с точки зрения настоящего параноика, уязвима. Но это не повод добавлять туда еще одну дыру.
Украсть закрытый ключ сертификата root ca? Разве что, целиком с HSM. Серьёзный подход.
Разве это не случай «доказательства с нулевым разглашением»? cryptography.ru/docs/%D0%B4%D0%BE%D0%BA%D0%B0%D0%B7%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D1%81%D1%82%D0%B2%D0%BE_%D1%81_%D0%BD%D1%83%D0%BB%D0%B5%D0%B2%D1%8B%D0%BC_%D1%80%D0%B0%D0%B7%D0%B3%D0%BB%D0%B0%D1%88%D0%B5%D0%BD%D0%B8
Возможно для кого-то такая вот «облачная подпись» является будущим электронных подписей. Для меня же перенос всех приватных ключей пользователей на сервер означает примерно то же самое, как если бы все обычный человек передал право подписывания всех документов нотариусу. Всех, включая договора, обязательства, отказы от имущественных прав и так далее. Будущее? Я против подобного будущего.
Это не будущее ЭП, это её настоящее.
То есть Вы предлагаете передавать свой персональный закрытый ключ, который используется для подписи в юридически значимом документообороте какой-то третьей, пусть и доверенной (условно), стороне? Вы действительно считаете, что сервер с какой-то многофакторной аутентификацией надежнее клиентских персональное устройств?
Если у пользователя возникают проблемы с наипросторнейшей процедурой подключения токена или смарт-карты, вводом PINа и непосредственно подписью, то стоит ли вообще его наделять правом подписи?
Да, использование ЭП требует от пользователя соблюдения определенных правил, но это не повод добровольно отказаться от своего закрытого ключа в угоду кажущегося удобства.
Если у пользователя возникают проблемы с наипросторнейшей процедурой подключения токена или смарт-карты, вводом PINа и непосредственно подписью, то стоит ли вообще его наделять правом подписи?
Да, использование ЭП требует от пользователя соблюдения определенных правил, но это не повод добровольно отказаться от своего закрытого ключа в угоду кажущегося удобства.
А то, что сегодня вы передаете закрытый ключ смарт-карте вас не пугает? А что там за софт на смарт-карте? Что за закладки? Не считаете ли вы, что таким образом вы уже отказались от своего закрытого ключа?
А еще вы доверяете какому-то стороннему софту делать что угодно с ключевой информацией на этой смарт-карте. Вас это тоже не пугает?
Для меня то, что вы пишете звучит как: «Коробка автомат? Да вы что? Как можно доверять переключение передач какой-то сторонней системе? Водители должны сами все контролировать!»
А еще вы доверяете какому-то стороннему софту делать что угодно с ключевой информацией на этой смарт-карте. Вас это тоже не пугает?
Для меня то, что вы пишете звучит как: «Коробка автомат? Да вы что? Как можно доверять переключение передач какой-то сторонней системе? Водители должны сами все контролировать!»
До недавнего времени я и не подозревал, что пользуюсь электронной подписью, когда оплачиваю сотовую связь через интернет-банк, пока не увидел «Простая электронная подпись Ким Н.Г. от 31.12.9999» в платёжном поручении. Здесь код подтверждения в SMS является частью реализации облачной ЭП, о которой говорится в статье. Это удобно и, доверяя своему банку, я этим пользуюсь.
Тем не менее, смарт-карту, даже полную закладок, я хотя бы могу взять в руки и таким образом контролировать физическое местонахождение ключей, а организовав воздушный зазор — полагать, что они случайно не попадут в чужие руки во время использования.
Тем не менее, смарт-карту, даже полную закладок, я хотя бы могу взять в руки и таким образом контролировать физическое местонахождение ключей, а организовав воздушный зазор — полагать, что они случайно не попадут в чужие руки во время использования.
Я не считаю себя конченным параноиком и не испытываю дискомфорта от того, что мой закрытый ключ хранится на токене. Хотя, по понятным причинам, и это устройство нельзя считать абсолютно безопасным. Однако согласитесь, персональное устройство, подключаемое по требованию, вызывает бОльшее доверие, чем общедоступный сервис (пусть даже в рамках доверенной сети) с хранилищем всех закрытых ключей пользователей, к которому в любой момент времени может получить доступ любой пользователь.
И знаете, я вполне доверяю и автоматам, и роботам и бесступенчатым трансмиссиям. Более того, я предпочитаю автоматы. Но переключение скоростей и передача стороннему сервису права подписи документов — для меня совершенно разные вещи.
Если же Вы не видите разницы, то что ж… Имеете на то право.
И знаете, я вполне доверяю и автоматам, и роботам и бесступенчатым трансмиссиям. Более того, я предпочитаю автоматы. Но переключение скоростей и передача стороннему сервису права подписи документов — для меня совершенно разные вещи.
Если же Вы не видите разницы, то что ж… Имеете на то право.
И мистер Сноуден тому подтверждение.
Не важно общедоступен ли сервис или предоставляется только вам. Ключи в решении с облачной подписью должны храниться на HSM. Никто, даже сам сервер подписи, не получает сами закрытые ключи.
Безопасность типа «подключение по требованию» перестает работать в тот самый момент, когда вы подключаете смарт-карту.
Вы рассуждаете с точки зрения технически подкованного потенциального пользователя. На практике большая часть пользователей систем, требующих ЭП, не очень поддаются внушению и обучению в части правил хранения и эксплуатации смарт-карт.
С точки зрения владельца сервиса, требующего ЭП, пользователи от которых требуется самостоятельно хранить и использовать ключи на смарт-картах это бОльшая проблема, чем пользователи от которых требуется только проверка подлинности.
По поводу АКПП: возможно, неудачная аналогия.
Но, продолжая транспортные аналогии: вы же доверите свою безопасность пилоту самолета, а не предпочтете научиться управлять самостоятельно.
Конечно аналогия гипертрофированна, но я просто пытаюсь передать смысл:
Разумный человек захочет сам отвечать за свою безопасность только если он действительно способен это сделать.
Вопрос доверия — дело личное. Каждый сам должен определять кому, что и в какой ситуации доверять. Хорошо, что вы подходите к этому с таким уровнем ответственности.
Безопасность типа «подключение по требованию» перестает работать в тот самый момент, когда вы подключаете смарт-карту.
Вы рассуждаете с точки зрения технически подкованного потенциального пользователя. На практике большая часть пользователей систем, требующих ЭП, не очень поддаются внушению и обучению в части правил хранения и эксплуатации смарт-карт.
С точки зрения владельца сервиса, требующего ЭП, пользователи от которых требуется самостоятельно хранить и использовать ключи на смарт-картах это бОльшая проблема, чем пользователи от которых требуется только проверка подлинности.
По поводу АКПП: возможно, неудачная аналогия.
Но, продолжая транспортные аналогии: вы же доверите свою безопасность пилоту самолета, а не предпочтете научиться управлять самостоятельно.
Конечно аналогия гипертрофированна, но я просто пытаюсь передать смысл:
Разумный человек захочет сам отвечать за свою безопасность только если он действительно способен это сделать.
Вопрос доверия — дело личное. Каждый сам должен определять кому, что и в какой ситуации доверять. Хорошо, что вы подходите к этому с таким уровнем ответственности.
> Никто, даже сам сервер подписи, не получает сами закрытые ключи.
ОК, допустим, что ключи генерируются самим сервером прямо в HSM и про их содержимое он действительно ничего не знает.
Но зато он прекрасно знает содержимое всех конфиденциальных документов, отправляемых ему на подпись, и может выпустить свой похожий документ от вашего имени, если его хозяевам вдруг так захочется или его кто-то поимеет.
Оно вам таки действительно надо?
ОК, допустим, что ключи генерируются самим сервером прямо в HSM и про их содержимое он действительно ничего не знает.
Но зато он прекрасно знает содержимое всех конфиденциальных документов, отправляемых ему на подпись, и может выпустить свой похожий документ от вашего имени, если его хозяевам вдруг так захочется или его кто-то поимеет.
Оно вам таки действительно надо?
Ключи в решении с облачной подписью должны храниться на HSM. Никто, даже сам сервер подписи, не получает сами закрытые ключи.
Во всей этой «облачной» архитектуре устройство HSM — единственное, чему я могу доверять. Гораздо больше вопросов возникает с механизмами аутентификации (как облачный сервис решает, что именно я владелец закрытого ключа), с передачей документов третьему лицу и т.д. Все эти «лишние» шаги способствуют дополнительным проблемам. И уж коли Вы так любите транспортные аналогии, то мне подобные сервисы видятся не как пилот-профессионал за штурвалом боинга, а как таксист-гастарбайтер за рулем ушатанной шестерки. Если кого-то устраивает такой сервис — пожалуйста.
Вопрос доверия — дело личное.
Вот тут Вы правы. И я такой системе довериться не могу.
Механизмы аутентификации могут быть любыми. И от их выбора будет зависеть вероятность несанкционированного использования вашей ЭП.
Задача передачи документов не является задачей сервера подписи. Он документы не хранит, а только подписывает. А хранится документы могут, например в СЭД. Вот он то и решает задачу их передачи.
К сожалению почти любую системы можно превратить в ушатанную шестерку. Хороший пример — тот же PKI. Мало где в организациях он развернут по правилам. Администратор просто ставит MSCA и делает, что считает нужным. А ведь PKI — это по большей части регламенты/правила/инструкции. Примеры, когда разертывание PKI сопроваждалось написанием Certificate Policy/Certificate Practice Statement, организацией ключевой церемонии (Key Ceremony) с привлечением внешних аудиторов можно в РФ пересчитать по пальцам.
Тем не менее, организации, предоставляющей сервисы технически проще правильно настроить и эксплуатировать одну сущность, чем отвечать за всех пользователей.
У нас почему-то чаще решается вопрос с ответственностью, чем вопрос с потенциальными рисками. Можно конечно собрать со всех пользователей расписки с обязательствами делать то-то и не делать то-то с ключевым носителем. Но в случае с нарушением этих правил, пострадать может и организация предоставляющая сервис.
Если у вас 10000 пользователей, то я бы предпочел возить их на боинге, а не раздавать всем по кукурузнику в надежде, что они усвоили правила пользования.
Задача передачи документов не является задачей сервера подписи. Он документы не хранит, а только подписывает. А хранится документы могут, например в СЭД. Вот он то и решает задачу их передачи.
К сожалению почти любую системы можно превратить в ушатанную шестерку. Хороший пример — тот же PKI. Мало где в организациях он развернут по правилам. Администратор просто ставит MSCA и делает, что считает нужным. А ведь PKI — это по большей части регламенты/правила/инструкции. Примеры, когда разертывание PKI сопроваждалось написанием Certificate Policy/Certificate Practice Statement, организацией ключевой церемонии (Key Ceremony) с привлечением внешних аудиторов можно в РФ пересчитать по пальцам.
Тем не менее, организации, предоставляющей сервисы технически проще правильно настроить и эксплуатировать одну сущность, чем отвечать за всех пользователей.
У нас почему-то чаще решается вопрос с ответственностью, чем вопрос с потенциальными рисками. Можно конечно собрать со всех пользователей расписки с обязательствами делать то-то и не делать то-то с ключевым носителем. Но в случае с нарушением этих правил, пострадать может и организация предоставляющая сервис.
Если у вас 10000 пользователей, то я бы предпочел возить их на боинге, а не раздавать всем по кукурузнику в надежде, что они усвоили правила пользования.
UFO just landed and posted this here
Следуя вашей логике: нотариусы тоже не нужны, они просто заверяют своей подписью документ. Прошу прощения у специалистов, если сейчас не совсем точно объясню. Пара ключ и сертификат — похожа на пару замок и ключ. Каждый может подойти со своим ключом и попробовать открыть тот или иной замок. В случае электронного документооборота нужно гарантировать, что этот документ подписан именно тем-то (сравним с отпечатком пальца), а вот смотреть его будут другие, у кого нет ключа. Поэтому сертификат делается публичным — то есть может распространяться, но подписать им можно будет только, если у вас есть еще и ключ. А он, как правило, располагается на каком-то контейнере: рутокен, етокен, флешка, дискетка и т.д.
UFO just landed and posted this here
Сертификат это просто файл специального формата где лежит ключ, закрытый или публичный.1. Приведите примеры, когда сертификат содержит закрытый ключ. Когда он лежит в каком-нибудь контейнере рядом с закрытым ключом (типа PKCS12), то это вполне понятно.
2. Сертификат кроме, собственно, публичного ключа содержит другую важную информацию:
— кому принадлежит (DN) в том или ином виде (X.500-like DN в X.509, uid в PGP),
— тип ключа, алгоритм подписи
— подпись ключевого материала (CA в случае X.509, другие пользователи в PGP WoT),
— ограничения (сроки действия, использования и т. п.),
— прочее говно (в x509 всякие crl, ocsp-responder, issuer, хэши ключевой информации и прочее).
Если говорить про ЭЦП с точки зрения технологии, то для неё достаточно ключевой пары. Если говорить про ЭЦП с юридической точки зрения, то она требует наличия авторизованного CA, который обязан проверить полноту и достоверность сведений, идентифицировать желающего получить ЭЦП. В рамках этого поста под ЭЦП понимают, скорее, второй вариант. А он невозможен без авторизованного CA (также, как и паспорт, можно получить только через авторизованные организации).
Например, сертификаты для TLS не содержат никаких имён пользователей.Это не так. Клиентский TLS может запросто содержать, например,
/CN=Ivan Ivanov/emailAddress=ii@example.com/.ЭЦП (DSA) гораздо шире и применяется гораздо чаще, чем при работе с домене, госухой и всякими комерсами.DSA — Digital Signature Algorithm — это только один, ныне редкоиспользуемый, алгоритм подписи. Давно вы видели TLS с DSS в ciphersuite? Куда чаще используется RSA, ECDSA и EdDSA.
Это и SSL/TLS и всякие VPN и куча других не очевидных мест.
за сертификаты платитьЕсть разные варианты: бесплатный startssl, wosign; просто говно от comodo за $5 на обычный или $60 на wildcard. Или ждите введения DANE (но за домен всё равно платить придётся), бесплатных сертификатов от Mozilla и т. п.
Сертификат это просто контейнер для хранения ххх бит случайных данных, которые и являются секретным ключём.
Вы допустили опечатку. Всё-таки сертификат — это контейнер с информацией о пользователе и его открытый ключ.
UFO just landed and posted this here
Если бы был вариант мульти САВ этом плане мне нравится PGP.
Кстати, существуют ли «центры сертификации» для него (неё?), подписывающие сертификаты пользователей автоматически или даже с ручной проверкой?
Догадываюсь, что вы пытались ответить мне, но перенести в соответствующую ветку не сможете.
Аналогично, взаимодействие с некоторыми площадками (всякие ФНС, ФСС, госзакупки), порталами госуслуг и т. п. может требовать квалифицированной подписи, согласно 63-фз, что потребует получить сертификат у аккредитованного УЦ.
1. Когда генерируешь самодписной средствами OpenSSL.Приведите пример создания сертификата, когда в теле сертификата оказывается приватный ключ. Результат с двумя сконкатенированными PEM-блоками в base64 не считаются.
На тех же вебсерверах они лежат, для работы TLS.
С юридической точки зрения CA не обязателен.Для части документов это так. Часть документов (например, счета-фактуры) следует подписывать квалифицированной подписью, чтобы они были приняты к рассмотрению при расчёте налогов. А часть документов можно спокойно подписывать простой электронной подписью, если договор или доп. соглашение устанавливает такую договорённость между коммерческими организациями. Судя по описанной арбитражной практике такая подпись вполне работает как аналог собственноручной + печати. Насчёт взаимодействия физик-физик или юрик-физик — не знаю. Стоит также добавить, что некоторые договора могут заключаться только на бумаге (по ГК РФ).
Аналогично, взаимодействие с некоторыми площадками (всякие ФНС, ФСС, госзакупки), порталами госуслуг и т. п. может требовать квалифицированной подписи, согласно 63-фз, что потребует получить сертификат у аккредитованного УЦ.
Если бы был вариант мульти СА, когда мою цп заверяют одновременно разные СА, например Россия, США, Китай и ещё кто нибудь, то это хотя бы от части могло что то гарантировать.Хотите WoT — используйте PGP/GnuPG, там люди удостоверяют, что вы — это вы (и что они видели, как минимум какой-нибудь id, удостоверяющий личность). Была ещё инициатива cacert.org, там тоже через сеть доверия удостоверяли личность.
en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_AlgorithmНепонятно, что вы хотели этим сказать. ЭЦП (digital signature) != DSA, т. к. DSA — частный алгоритм ЭЦП. ECDSA — то же самое, но на группе точек эллиптической кривой, а не в конечном поле целых чисел. Если посмотреть на страницу, посвящённую DSA, то там сказано:
«Elliptic Curve Digital Signature Algorithm (ECDSA) offers a variant of the Digital Signature Algorithm (DSA)»
У них там понятия ЭЦП, есть DSA, насколько я понимаю. Про то это ныне устаревший алгоритм я знаю.
The Digital Signature Algorithm (DSA) is a Federal Information Processing Standard for digital signatures.
Sign up to leave a comment.
Будущее электронной подписи