Работа с CAdES (создание всех версий, вплоть до архивных);
Работа с PAdES (подпись и шифрование). То есть PKIjs используется как вспомогательная в дополнение к нашему собственному парсеру/мейкеру PDF (всё на чистом JavaScript);
Создание собственных серверов OCSP, TSP, CA, RA (на Node.js);
Создание «polyfills» для возможности работы PKIjs с помощью сторонних библиотек таких как эта, а также для работы внутри Node.js, для работы с алгоритмами ГОСТ и прочая без изменения исходного кода PKijs;
Реализация полноценной «verification engine», способной проверять подписи CAdES и PAdES;
Реализация поддержки PKCS#12 (когда у меня будет время);
И ещё кое-что;
Также скажу что понятие «в работе» фактически можно свести к «в работе на финальной стадии», то есть процентов 90 всего кода уже готово. Скорее всего весь код будет публично доступен, но часть его будет «только для некоммерческого использования». Следите за анонсами.
Так что ресурсы вкладываются большие, библиотека активно совершенствуется, пусть пока и несколько скрытно.
Понимаете, давным-давно жили умные люди. И захотелось им чтобы было общее хранилище для всех цифровых идентификаторов пользователей. И придумали они стандарт X.500 — и возрадовались. Также были другие умные люди, которые решили, что стандарт X.500 уж больно сложен. И придумали они LDAP (Lightweight Directory Access Protocol), который был проще. Также умные люди придумали ещё один стандарт — X.509, дабы служил он для достоверной передачи сведений о пользователях и достоверной идентификации оных.
А потом, лет эдак через 20, появился чудесный продукт — EMCSSL. И придумали для этого продукта базу данных — «доверенный блокчейн». И хранила она пары «имя-значение» и были эти пары однозначно привязаны к пользователю. С сертификатами в этом продукте решили не заморачиваться, и использовали сильно обрезанные сертификаты из X.509.
А теперь по существу. Вашему «доверенный блокчейну» даже до упрощённых реализаций «X.500 directory» — как до Луны пешком. Все ваши «инновации» и «улучшение SSL» достигаются просто дополнительным уровнем проверки по вашей базе данных («доверенному блокчейну»). Всё это давным-давно возможно, и может быть реализовано гораздо более правильно путём использования стандартных «directories» с доступом по LDAP. Ваши «сертификаты» ущербны потому, что в них отсутствует корректное использование следующих полей:
1) subject;
2) notBefore + notAfter;
3) issuerUniqueID + subjectUniqueID;
4) ну и на сладкое — все поля из «extensions»;
Наверное кто-то решил, что эти поля в сертификатах вторичны. Конечно, зачем умные люди их придумали — мы же живём в «новой цифровой эпохе», тут у нас есть «доверенный блокчейн» :)
Кстати — полей «OU1...OU4» в сертификатах нет. Полагаю, что вы говорите про «organizationalUnitName», а это всего лишь один из элементов имени, используемый в полях сертификата «issuer», «subject» плюс в различных расширениях сертификата (поле «extensions»).
У меня есть куча других дел, кроме копания в вашей поделке. Если мои замечания для вас пустой звук, то мне на самом деле наплевать. Мои замечания здесь тогда будут оценивать другие читатели данной статьи.
Также в вашей системе возможна ситуация, когда пользователь изготавливает себе сертификат удостоверяющего центра. И таким образом может начать сам устанавливать политики использования выпущенных сертификатов и другие ограничения. Или сделать очень длинную цепочку сертификатов (скажем в 1000 промежуточных удостоверяющий центров) и создавать тем самым возможные проблемы для «certificate verification engines».
Кстати, ответьте, пожалуйста, на мой вопрос в этой теме.
Вы публикуете (либо обновляете) «цифровую подпись» сертификата в EmerCoin NVS
Обновляете? Это как?
При генерации последующих сертификатов, Вы можете отредактировать файл *.tpl, и внести туда другие значения полей CN/Email/UID, после чего сгенерировать новый сертификат, заменить его в браузере и соответственно изменить контрольную сумму в соответствующей записи в NVS
Правильно ли я понимаю, что можно произвольно заменять сертификаты просто зная его серийный номер?
Ну тогда я вам расскажу, как работает ваша система. Всё работает по стандартной схеме PKI: есть один удостоверяющий центр и множество пользовательских сертификатов. Так как сертификат пользователя генерируется самим пользователем, то возникает проблема — отсутствие уникальности серийных номеров сертификатов. Данную проблему вы решаете использованием блокчейна. Так что блокчейн у вас тут крайне второстепенная вещь, которая просто обеспечивает формальные требования к пользовательским сертификатам. Доверенное TLS у вас действительно возникает, но вот только потому, что вы добавляете корневой сертификат вашего так сказать «удостоверяющего центра» в доверенные. То есть выполняете формальные требования.
Однако думаю, что возможны различные претензии к вашим пользовательским сертификатам, вызванные тем, что генерируются они самим пользователем. Так основная претензия будет к качеству генерируемых ключей — при генерации ключей с помощью УЦ возможно использование «правильных алгоритмов» генерации и правильных параметров к ним, а вот при генерации на стороне пользователя с этим уже могут возникнуть сложности. Ну и опять же я до сих пор утверждаю, что в ваших сертификатах полезной нагрузкой является только публичный ключ. На все остальные поля сертификата можно закрывать глаза.
Мда. Самоподписанным называется сертификат, у которого поля «issuer» и «subject» являются одинаковыми и у которого подпись самого сертификата выполнена с использованием закрытого ключа, соответствующего публичному ключу из данного сертификата. А ваша схема уже формально использует «удостоверяющий центр».
Доверенный сертификат или нет в PKI определяется доверием к корневому сертификату цепочки сертификатов для данного пользовательского сертификата. Понятие «доверенный блокчейн» мне понятно слабо. Как я понял из статьи этот блокчейн может однозначно подтвердить только то, что серийный номер сертификата уникален.
Сервера логов СТ известны и эти сервера множатся. Однако вот знает ли кто-нибудь действующие сервера типа «аудитор» и «наблюдатель»? И вообще — насколько реальна задача в реальном времени проверить один сертификат по базе в 6-9 миллионов сертификатов?
Сервер, получив сертификат, вначале проверяет подпись сертификата. Успешная проверка подписи доказывает, что сертификат был сгенерирован для системы emcssl.
Как сервер проверяет, что именно этот сертификат был сгенерирован для системы emcssl, при условии, что клиентский сертификат самоподписанный?
Безопасное TLS соединение создаётся когда сертификат является доверенным. Ваши же сертификаты являются самоподписанными и доверенными их считать изначально невозможно. Для осуществления установления доверия к подобным сертификатам нужно будет провести очень большой комплекс процедур. И пока я считаю, что этот «комплекс процедур» будет существенно больше по затратам, чем стандартная модель PKI.
В общем ещё раз — в данной системе используется простейший режим создания подписей на основе уникальности пары «публичный-закрытый ключ». Сертификаты тут использованы только для того, чтобы упростить их использование в браузере. Из всего сертификата используется только массив публичного ключа. Какое-либо использование подобных «сертификатов» в PKI просто невозможно.
Ах вот оно что — сертификаты самоподписаные. Тогда тем более нет никакой (вообще) причины использовать именно сертификаты. Если у вас возникает проблема с использованием публичного/приватного ключа при создании коммуникаций в браузере, то вполне вероятно написать самостоятельное расширение.
У меня остался один вопрос: зачем в данной системе использовать именно сертификат, когда из всех полей сертификата реально можно использовать только одно — публичный ключ? Поясню почему нельзя использовать другие поля сертификата: закрытый и публичный ключ генерирует сам пользователь, хэш сумма вычисляется только от общего массива получившегося сертификата. Таким образом в данной системе могут быть миллионы сертификатов выданных, например, Владимиру Владимировичу Путину. Или Биллу Гейтсу. Так что пока считаю, что в данной чудесной системе можно обойтись и без PKI — просто использовать массив публичного ключа.
Отличная логическая игрушка. Кстати, на начальном сайте http://games.flowix.com помниться были даже исходники данной игры. Так что автору данной статьи эти исходники были бы, возможно, также интересны.
Как оказалось, исходная статья как минимум сменила свой адрес нахождения. Также как и исходный код к статье. Однако здесь я нашёл копию исходной статьи, а также копию исходных кодов к ней. Возможно, что кому-нибудь эта информация и поможет.
Также скажу что понятие «в работе» фактически можно свести к «в работе на финальной стадии», то есть процентов 90 всего кода уже готово. Скорее всего весь код будет публично доступен, но часть его будет «только для некоммерческого использования». Следите за анонсами.
Так что ресурсы вкладываются большие, библиотека активно совершенствуется, пусть пока и несколько скрытно.
Понимаете, давным-давно жили умные люди. И захотелось им чтобы было общее хранилище для всех цифровых идентификаторов пользователей. И придумали они стандарт X.500 — и возрадовались. Также были другие умные люди, которые решили, что стандарт X.500 уж больно сложен. И придумали они LDAP (Lightweight Directory Access Protocol), который был проще. Также умные люди придумали ещё один стандарт — X.509, дабы служил он для достоверной передачи сведений о пользователях и достоверной идентификации оных.
А потом, лет эдак через 20, появился чудесный продукт — EMCSSL. И придумали для этого продукта базу данных — «доверенный блокчейн». И хранила она пары «имя-значение» и были эти пары однозначно привязаны к пользователю. С сертификатами в этом продукте решили не заморачиваться, и использовали сильно обрезанные сертификаты из X.509.
А теперь по существу. Вашему «доверенный блокчейну» даже до упрощённых реализаций «X.500 directory» — как до Луны пешком. Все ваши «инновации» и «улучшение SSL» достигаются просто дополнительным уровнем проверки по вашей базе данных («доверенному блокчейну»). Всё это давным-давно возможно, и может быть реализовано гораздо более правильно путём использования стандартных «directories» с доступом по LDAP. Ваши «сертификаты» ущербны потому, что в них отсутствует корректное использование следующих полей:
1) subject;
2) notBefore + notAfter;
3) issuerUniqueID + subjectUniqueID;
4) ну и на сладкое — все поля из «extensions»;
Наверное кто-то решил, что эти поля в сертификатах вторичны. Конечно, зачем умные люди их придумали — мы же живём в «новой цифровой эпохе», тут у нас есть «доверенный блокчейн» :)
Кстати — полей «OU1...OU4» в сертификатах нет. Полагаю, что вы говорите про «organizationalUnitName», а это всего лишь один из элементов имени, используемый в полях сертификата «issuer», «subject» плюс в различных расширениях сертификата (поле «extensions»).
У меня есть куча других дел, кроме копания в вашей поделке. Если мои замечания для вас пустой звук, то мне на самом деле наплевать. Мои замечания здесь тогда будут оценивать другие читатели данной статьи.
Кстати, ответьте, пожалуйста, на мой вопрос в этой теме.
Обновляете? Это как?
Правильно ли я понимаю, что можно произвольно заменять сертификаты просто зная его серийный номер?
Однако думаю, что возможны различные претензии к вашим пользовательским сертификатам, вызванные тем, что генерируются они самим пользователем. Так основная претензия будет к качеству генерируемых ключей — при генерации ключей с помощью УЦ возможно использование «правильных алгоритмов» генерации и правильных параметров к ним, а вот при генерации на стороне пользователя с этим уже могут возникнуть сложности. Ну и опять же я до сих пор утверждаю, что в ваших сертификатах полезной нагрузкой является только публичный ключ. На все остальные поля сертификата можно закрывать глаза.
Как сервер проверяет, что именно этот сертификат был сгенерирован для системы emcssl, при условии, что клиентский сертификат самоподписанный?