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

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

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

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

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

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

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

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

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

Спасибо.

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

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

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

Есть ли реализация в АПИ Рутокен-плагина возможность создать СМС-запрос на плановую смену в рамках 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 для подписи - этот вариант поможет? Есть ли пример использования?

Спасибо.