(2020-05-15 15:16:06 отредактировано ldvufa)

РутокенЭЦП 2.0 и генерация CMC-запроса на плановую смену

День добрый.

Есть ли реализация в АПИ Рутокен-плагина возможность создать СМС-запрос на плановую смену в рамках RFC 5272?

Немного раскрою мысль:
1. Есть ключевая пара и сертификат на токене. Когда сертификат подходит к концу встает вопрос о продлении.
2. Через плагин мы можем создать новый PKCS10 запрос. Передать его в УЦ мы не можем, так как не выполняются требования по проверке владения текущим ключом.
3. Если подписать запрос методом Sign, то в получившемся конверте PKCS7 eContentType стоит 1.2.840.113549.1.7.1 (id-Data).
4. Однако УЦ требует чтобы бы тип был id-cct-PKIData (1.3.6.1.5.5.7.12.2), как прописано в RFC 5272, что логично.  Без этого запрос бракуется.

Подскажите куда копать в рамках стандартного API плагина. В описании к методу sign есть возможность сразу указать готовую CMS для подписи - этот вариант поможет? Есть ли пример использования?

Спасибо.

Re: РутокенЭЦП 2.0 и генерация CMC-запроса на плановую смену

ldvufa, здравствуйте!

Рутокен плагин не умеет формировать СМС-запрос.

Передать его в УЦ мы не можем, так как не выполняются требования по проверке владения текущим ключом.

Поясните, пожалуйста, что вы имеете ввиду. Вы хотите удостовериться, что запрос был создан на Рутокене?

Плагин умеет делать Simple PKI Request (PKCS#10 request, RFC3852). Full PKI Request -- СМС-запрос – требует специальный CMS c PKIData object.
PKIData object можно сформировать вручную используя https://asn1js.org/ и передать в метод Плагина sign.

Re: РутокенЭЦП 2.0 и генерация CMC-запроса на плановую смену

Павел Анфимов пишет:

Поясните, пожалуйста, что вы имеете ввиду. Вы хотите удостовериться, что запрос был создан на Рутокене?

Нет, вопрос в классическом вопросе подтверждения владения двумя ключами - текущим и новым. На стороне УЦ это можно сделать только по СМС-запросу.

Павел Анфимов пишет:

Плагин умеет делать Simple PKI Request (PKCS#10 request, RFC3852). Full PKI Request -- СМС-запрос – требует специальный CMS c PKIData object.
PKIData object можно сформировать вручную используя https://asn1js.org/ и передать в метод Плагина sign.

Спасибо.

Re: РутокенЭЦП 2.0 и генерация CMC-запроса на плановую смену

ldvufa,

Нет, вопрос в классическом вопросе подтверждения владения двумя ключами - текущим и новым. На стороне УЦ это можно сделать только по СМС-запросу.

Как именно СМС-запрос это подтверждает?

Это также можно сделать, подписав PKCS#10 запрос на текущей (истекающей, но не истекшей) ЭП -- что показывает волю человека на выпуск новой ЭП. На стороне УЦ нужно только проверить подпись PKCS#10.

А с помощью журнала операций и специальной журнальной ключевой пары в Рутокене ЭЦП 2.0, можно также убедиться, что новая ключевая пара и PKCS#10 запрос  созданы на том же устройстве, что и истекающая ЭП.

Если интересно, можем рассказать как с этим работать в Плагине и на стороне УЦ.

Re: РутокенЭЦП 2.0 и генерация CMC-запроса на плановую смену

Павел Анфимов пишет:

Как именно СМС-запрос это подтверждает?

Павел Анфимов пишет:

подписав PKCS#10 запрос на текущей (истекающей, но не истекшей) ЭП

Вот так и подтверждает - в одном запросе две подписи указывающие что человек обладает и старым и новым ключом. А помимо подписи еще и данные о текущем сертифкате. Full PKI Request такую возможность как раз дает.

Само собой на стороне ЭДО генерация ключей и СМС-запроса выполняется для пользователя как одна операция. Собственно большинство распространенных систем ДБО, например, так и работают.

Re: РутокенЭЦП 2.0 и генерация CMC-запроса на плановую смену

ldvufa, напишите, пожалуйста, нам info@rutoken.ru. Расскажите с каким ДБО вы работаете. Плагин постоянно развивается -- обсудим добавление возможности формирования СМС-запросов.