Comments 12
Как говорят в некоторых кругах, тема @$ли не раскрыта.
Что ожидал увидеть, но не увидел.
1. В описании pkcs7 не упомянута такая интересная вещь как co-signature (встречная подпись, дословно — подпись на подпись), фактически упрощенная функция нотариата.
2. Сама служба нотариата во всей своей мощи описана в rfc3029. Тоже не помянули.
3. Не затронули тему управления ключами, время жизни ключей, вопрос компрометации ключей, выпуск и распространение CRL, время его жизни.
4. Ничего не сказали о службе онлайновой (мгновенной) проверки статуса сертификата, она же служба OCSP, rfc4806.
5. Не рассказали о проблемах сертификации криптографического ПО в России. Хотя тут на ваше усмотрение, может быть вы не имеете к этому процессу отношения.
Что ожидал увидеть, но не увидел.
1. В описании pkcs7 не упомянута такая интересная вещь как co-signature (встречная подпись, дословно — подпись на подпись), фактически упрощенная функция нотариата.
2. Сама служба нотариата во всей своей мощи описана в rfc3029. Тоже не помянули.
3. Не затронули тему управления ключами, время жизни ключей, вопрос компрометации ключей, выпуск и распространение CRL, время его жизни.
4. Ничего не сказали о службе онлайновой (мгновенной) проверки статуса сертификата, она же служба OCSP, rfc4806.
5. Не рассказали о проблемах сертификации криптографического ПО в России. Хотя тут на ваше усмотрение, может быть вы не имеете к этому процессу отношения.
Тема несколько обширна и освящение поднятых Вами вопросов — не одной статьи об'ем.
То, что Вы не увидели того, что хотите — извините, не угодил.
Относительно Ваших вопросов:
1. Мультиподпись в статье описана. Подробности — прошу смотреть стандарт или задать корректно интересующий вопрос.
2. Нотариат относится больше к юридическому аспекту ЭП, а не к техническому. Это тема отдельной дискуссии.
3. Управление ключами при работе с ЭП — удел PKI. Читайте внимательно и смотрите ссылки.
4. См. П. 3.
5. Это вообще не относится к теме статьи. См. введение.
Готов обсудить интересующие вопросы при корректной их постановке. Мешать все темы в одну кучу — будет либо скомкано и ничего не понятно, либо очень много букв.
Если интересно, можно создать цикл статей на эту тему, раскрывающих все аспекты.
То, что Вы не увидели того, что хотите — извините, не угодил.
Относительно Ваших вопросов:
1. Мультиподпись в статье описана. Подробности — прошу смотреть стандарт или задать корректно интересующий вопрос.
2. Нотариат относится больше к юридическому аспекту ЭП, а не к техническому. Это тема отдельной дискуссии.
3. Управление ключами при работе с ЭП — удел PKI. Читайте внимательно и смотрите ссылки.
4. См. П. 3.
5. Это вообще не относится к теме статьи. См. введение.
Готов обсудить интересующие вопросы при корректной их постановке. Мешать все темы в одну кучу — будет либо скомкано и ничего не понятно, либо очень много букв.
Если интересно, можно создать цикл статей на эту тему, раскрывающих все аспекты.
Я считаю что вопрос управления ключами, в том числе цикл жизни ключей имеет
непосредственное отношение к ЭЦП.
Много — да. Скомкано — нет. Все указанные технологии образуют картину целиком,
вы выкусили самую верхушку айсберга и расказываете о ней как об ЭЦП.
Подпись изначально создавалась для «удостоверения» (от достоверность) некоторым лицом.
Т.е. обязательно должен присутствовать фактор доверия. Главным фактором доверия в мире ЭЦП служит
корневой сертификат ключа подписи CA. Компрометация этого ключа мгновенно разрушает смысл
всей иерархии. Далее аналогичное условие спускается по всему дереву до конечного пользователя.
А вы говорите управление ключами не причем. Эх…
непосредственное отношение к ЭЦП.
Много — да. Скомкано — нет. Все указанные технологии образуют картину целиком,
вы выкусили самую верхушку айсберга и расказываете о ней как об ЭЦП.
Подпись изначально создавалась для «удостоверения» (от достоверность) некоторым лицом.
Т.е. обязательно должен присутствовать фактор доверия. Главным фактором доверия в мире ЭЦП служит
корневой сертификат ключа подписи CA. Компрометация этого ключа мгновенно разрушает смысл
всей иерархии. Далее аналогичное условие спускается по всему дереву до конечного пользователя.
А вы говорите управление ключами не причем. Эх…
Прошу Вас не интерпретировать мои слова по-своему.
Посмотрите, пожалуйста, 5-й абзац, прежде чем присваивать мне слова о том, что управление ключами не причем.
Повторюсь еще раз. Управление ключами — отдельная тема, которая в данной статье не затрагивалась. Для ее раскрытия необходимо уделять внимание не технологиям работы с электронной подписью, а технологиями построения PKI.
Посмотрите, пожалуйста, 5-й абзац, прежде чем присваивать мне слова о том, что управление ключами не причем.
Повторюсь еще раз. Управление ключами — отдельная тема, которая в данной статье не затрагивалась. Для ее раскрытия необходимо уделять внимание не технологиям работы с электронной подписью, а технологиями построения PKI.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
А что PGP/GPG больше не модно? Соответствует ли этот стандарт статье 10 закона об электронной подписи? К какому виду подписи его можно отнести исходя из статьи 9? Возможно ли его использовать как доказательство в суде?
-----BEGIN PGP SIGNATURE----- Comment: Проверить подлинность https://zhovner.com/check.php iEYEARECAAYFAk8j1/sACgkQIMGD+D26DmPOHgCdFUEOlr1Q6CEHfg/QYF/ztq54 Yl0AoIxEus/PS+4r6hrUCveQA8uZE2RF =0an9 -----END PGP SIGNATURE-----
PGP — именно модно.
Я нисколько не сомневаюсь в безопасности решений PGP/GPG, но они находят свое применение именно в сегменте частной безопасности, делая упор на простое распространение ключевой информации между участниками обмена.
Для уровня Enterprise и «серьезных» взаимоотношений, как выше отмечал пользователь dendery, необходимо управление ключами, основанное на единой точке доверия. На сегодняшний день это технология PKI и Удостоверяющие Центры. Именно они призваны связать конкретное физическое лицо с его открытым ключом. Это необходимо для того, чтобы всегда был известен ответчик по конкретному инцеденту.
По Вашим вопросам:
> Соответствует ли этот стандарт статье 10 закона об электронной подписи?
Статья 10. Обязанности участников электронного взаимодействия при использовании усиленных электронных подписей.
В данной статье не требований, которым что-то могло бы соответствовать или нет
> К какому виду подписи его можно отнести исходя из статьи 9?
Статья 9. Использование простой электронной подписи
Статья описывает использование простой подписи
Возможно ли его использовать как доказательство в суде?
Возможно, в случае наличия между участниками обмена соглашения, соответствующего части 2 статьи 9 63-ФЗ.
Я нисколько не сомневаюсь в безопасности решений PGP/GPG, но они находят свое применение именно в сегменте частной безопасности, делая упор на простое распространение ключевой информации между участниками обмена.
Для уровня Enterprise и «серьезных» взаимоотношений, как выше отмечал пользователь dendery, необходимо управление ключами, основанное на единой точке доверия. На сегодняшний день это технология PKI и Удостоверяющие Центры. Именно они призваны связать конкретное физическое лицо с его открытым ключом. Это необходимо для того, чтобы всегда был известен ответчик по конкретному инцеденту.
По Вашим вопросам:
> Соответствует ли этот стандарт статье 10 закона об электронной подписи?
Статья 10. Обязанности участников электронного взаимодействия при использовании усиленных электронных подписей.
В данной статье не требований, которым что-то могло бы соответствовать или нет
> К какому виду подписи его можно отнести исходя из статьи 9?
Статья 9. Использование простой электронной подписи
Статья описывает использование простой подписи
Возможно ли его использовать как доказательство в суде?
Возможно, в случае наличия между участниками обмена соглашения, соответствующего части 2 статьи 9 63-ФЗ.
Все кошерно, но. PKCS за номером 7 может являться и присоединенной, и неприсоединеной подписью, я бы это упомянул. Потом, если вы начали про 7 и про 11, уж сказали бы в двух словах, что означают остальные цифры, за какие стандарты отвечают, 1 за RSA, 12 за хранение закрытого ключа в файле, ну и так далее. Больше бы посвятили разметке ASN.1, например. А так получилось, что вроде бы как и обо всем, но вроде как и полнота отсутствует.
Еще надо помнить, что органы власти в странах СНГ могут заставить любой УЦ (удостоверяющий центр) депонировать ключи…
Кто не в курсе: у нас в Казахстане активно продвигают идею «электронного правительства», в связи с чем всем гражданам (и не только) выдают ЭЦП=ключи=сертификаты RSA и ГОСТ «производства» НУЦ (национальный удостоверяющий центр). И, насколько мне известно, КНБ (аналог ФСБ) сейчас имеет копии выданных сертификатов (и открытой и закрытой части).
Кто не в курсе: у нас в Казахстане активно продвигают идею «электронного правительства», в связи с чем всем гражданам (и не только) выдают ЭЦП=ключи=сертификаты RSA и ГОСТ «производства» НУЦ (национальный удостоверяющий центр). И, насколько мне известно, КНБ (аналог ФСБ) сейчас имеет копии выданных сертификатов (и открытой и закрытой части).
Не знаю, как в этих ваших Казахстанах, но у нас копия сертификата это вполне себе хорошо. Дело в том, что аппаратная защита как сделана у нас (см. eToken ГОСТ), сделана так, что ключ намертво зашит в брелок. Автор указывает на PKCS#11, именно этот стандарт и используется, правда автор не раскрывает для чего именно. А я вам поясню, дело в том, что в брелок зашит не только ключ, но и сами реализации криптоалгоритмов, и чтоб брелком подписать тот или иной документ, вам не нужно писать собственную реализацию того же сначала ГОСТ 34.11, а потом ГОСТ 34.10, вам достаточно отправить в брелок пачку байт и предложение «милый брелок, подпиши, пожалуйста, ЭТО». Милый брелок схватит, вытащит из своих закромов секретный ключ и подпишет данные, и вернет вам подпись. Поэтому если нет каких-то определенных изначальных «закладок», глупо говорить о том, что в Казахстане у правительства есть копии всех приватных ключей.
Нет ничего зазорного в том, чтобы иметь копии сертификатов. Это каждый может. НУЦ однозначно хранит эти сертификаты. Закрытый ключ, если пользователь генерирует у себя на компьютере, то кнб не при делах. А вот если пользователь обращается в цон (центр обслуживания населения) к доверенному оператору, чтобы ему все эти непонятные вещи проделали и сформировали все необходимое на флешку, то тут есть небольшой риск, что ключи могут попасть к кому-угодно. Но операторы на то и доверенные, чтобы не поддаваться провакациям :). Но если даже так не захочет доверить такой приватный вопрос, то может воспользоваться защищенными носителями, у которых все выполняется на борту и никуда закрытый ключ не утечет. Так что в наших Казахстанах все с этим в порядке.
>Стандарт PKCS#11 предполагает возможность использования проприетарных расширений. Фактически, это >добавленные производителем функции, не описанные в стандарте. Обычно они служат для выполнения >специфических операций с устройствами или реализуют необходимые, по мнению производителя, функции.
Не расскажите о примерах подобного расширения стандарта производителями?
Не расскажите о примерах подобного расширения стандарта производителями?
Практически любое устройство, с которым с составе идет библиотека PKCS#11 (токен, смарт-карта, HSM и пр.), обладает своими специфичными функциями.
Например, функции инициализации устройства, задания специфичных для конкретной реализации параметров.
Специфичные вещи никак не могут быть стандартизованы, поэтому для выполнения подобных операций возможно внедрение расширений PKCS#11.
Для примера, если Вы посмотрите SDK практически на любую смарт-карту, например eToken PRO (Java) или Gemalto TPC, то их реализация PKCS#11 имеет ряд расширений как раз для подобных целей.
Например, функции инициализации устройства, задания специфичных для конкретной реализации параметров.
Специфичные вещи никак не могут быть стандартизованы, поэтому для выполнения подобных операций возможно внедрение расширений PKCS#11.
Для примера, если Вы посмотрите SDK практически на любую смарт-карту, например eToken PRO (Java) или Gemalto TPC, то их реализация PKCS#11 имеет ряд расширений как раз для подобных целей.
Sign up to leave a comment.
Технологии работы с электронной подписью