Подобные решения — все на токене — уже давно существуют. Но далее сразу два препятствия:
1. Если работать с ними через CryptoAPI, то нужно устанавливать криптопровайдер со всеми кошмарами, если же работать через встроенный проприетарный интерфейс, то его должна поддерживать информационная система.
2. Данные решения должны поддерживаться средствами УЦ или хотя бы регламент УЦ должен позволять генерировать ключи на таких сторонних СКЗИ, получать от них запрос на сертификат и обрабатывать его.
Как-то в п. 5 вы широко так малярным валиком по картине импрессионистов. И вообще эта проблема слегка выбивается из общего списка и ее решение или текущее отсутствие такового мало влияют на «ужасы» упомянутые в начале статьи. Как и предлагаемые вами решения.
Как говорил классик — СКЗИ бывают разные…
1. В статье речь идет только о средствах электронной подписи, наверное этим и стоит ограничиться.
2. Чем вам поможет стандартизация архитектуры и структуры средств ЭП (что бы это не значило)?
3. Параметры криптоалгоритмов и ряда протоколов, а также большинство форматов передаваемых данных и представлений открытой ключевой информации уже стандартизированы и реализованы в современных средствах ЭП большинства вендоров.
4. Пользователь практически никогда не пользуется напрямую API средства ЭП. Он использует либо функционально законченное средство подписи файлов типа КриптоАРМ, либо некоторую информационную систему, в которую встроено средство ЭП. Поэтому стандартизация API это не решение проблем пользователя, а решение проблем IT.
5. Проблема СКЗИ-рабства лежит несколько в другой плоскости, чем отсутствие стандартизации, а точнее еще как минимум в одной. Приходя в УЦ пользователь сейчас практически лишен возможности выбора средства ЭП, которым ему предстоит пользоваться. А УЦ, в свою очередь, ограничен либо средствами УЦ, либо своими коммерческими соображениями.
Этот список также неполон и поверхностен, как и п. 5 в публикации. Это действительно очень технологичная тема, требующая отдельной дискуссии.
1. Если работать с ними через CryptoAPI, то нужно устанавливать криптопровайдер со всеми кошмарами, если же работать через встроенный проприетарный интерфейс, то его должна поддерживать информационная система.
2. Данные решения должны поддерживаться средствами УЦ или хотя бы регламент УЦ должен позволять генерировать ключи на таких сторонних СКЗИ, получать от них запрос на сертификат и обрабатывать его.
Как говорил классик — СКЗИ бывают разные…
1. В статье речь идет только о средствах электронной подписи, наверное этим и стоит ограничиться.
2. Чем вам поможет стандартизация архитектуры и структуры средств ЭП (что бы это не значило)?
3. Параметры криптоалгоритмов и ряда протоколов, а также большинство форматов передаваемых данных и представлений открытой ключевой информации уже стандартизированы и реализованы в современных средствах ЭП большинства вендоров.
4. Пользователь практически никогда не пользуется напрямую API средства ЭП. Он использует либо функционально законченное средство подписи файлов типа КриптоАРМ, либо некоторую информационную систему, в которую встроено средство ЭП. Поэтому стандартизация API это не решение проблем пользователя, а решение проблем IT.
5. Проблема СКЗИ-рабства лежит несколько в другой плоскости, чем отсутствие стандартизации, а точнее еще как минимум в одной. Приходя в УЦ пользователь сейчас практически лишен возможности выбора средства ЭП, которым ему предстоит пользоваться. А УЦ, в свою очередь, ограничен либо средствами УЦ, либо своими коммерческими соображениями.
Этот список также неполон и поверхностен, как и п. 5 в публикации. Это действительно очень технологичная тема, требующая отдельной дискуссии.