Кратко

  • RFC 9883 позволяет сертифицированному ключу подписи нести заявление для другого запроса на сертификат установления ключа.
  • Заявление утверждает владение, но не является техническим доказательством владения новым закрытым ключом.
  • УЦ обязан проверить путь сертификата подписанта и подпись запроса, а расхождения идентичности — обработать по политике эквивалентности.

Главная операционная ловушка — считать успешную проверку подписи доказательством двух разных фактов. Она показывает, кто подписал запрос, но не показывает, кто контролирует закрытый ключ, указанный в новом запросе. Атрибут privateKeyPossessionStatement переносит гарантию с уже подтверждённого ключа на другой ключ, но переносит её как подписанное утверждение.

OID атрибута — 1.3.6.1.4.1.22112.2.1. Полная структура имеет вид PrivateKeyPossessionStatement ::= SEQUENCE { signer IssuerAndSerialNumber, cert Certificate OPTIONAL }: поле signer определяет сертификат подписи по имени издателя и серийному номеру, а необязательное поле cert содержит сам сертификат подписи. Поле cert можно опустить только тогда, когда УЦ одновременно является издателем сертификата подписи и способен получить все действительные сертификаты, выданные им. Это узкое исключение для извлечения, а не право угадывать личность подписанта.

УЦ должен проверить путь сертификации сертификата подписи и отклонить запрос при недействительном пути. Он также должен проверить подпись запроса открытым ключом сертификата подписи и отклонить запрос при ошибке. RFC рекомендует, чтобы имя субъекта и SAN совпадали с данными сертификата подписи. Если они различаются, политика сертификата должна объяснить эквивалентность; если УЦ не может её установить, запрос отклоняется. Атрибут нельзя использовать для получения сертификата подписи.

В PKCS#10 subjectPublicKeyInfo содержит открытый ключ установления, атрибуты содержат заявление, а подпись запроса проверяется сертификатом подписи. В CRMF запрос сертификата содержит субъект и открытый ключ установления; proof-of-possession использует вариант с подписью и идентификатор отправителя, а regInfo содержит заявление. Одинаковая цель не означает одинаковую структуру кодирования.

RFC 5280 задаёт основу для пути сертификации и назначений ключа. RFC 6955 служит сравнением: там описаны механизмы технического доказательства владения ключами Diffie-Hellman. RFC 9883 не превращает своё заявление в криптографическое доказательство второго закрытого ключа. Его предмет также отличается от идентификаторов ML-DSA в PKIX из RFC 9881 и правил о подписываемых байтах CMS из RFC 9882.

Анализ Theo March: сертификат подписи можно операционно рассматривать как делегированный корень гарантии для второго ключа. Это анализ, а не требование RFC. УЦ следует связывать в аудите каждый производный сертификат установления с авторизующим сертификатом подписи, записывать решение об эквивалентности и отслеживать объём, смену субъектов, повторы и ошибки. Иначе передача гарантии не поддаётся проверке.

Связь создаёт цепочку зависимого отзыва. RFC 9883 указывает, что при компрометации сертификата подписи своевременный отзыв является единственной названной защитой, и рекомендует УЦ отозвать сертификаты установления, полученные через заявления, подписанные скомпрометированным сертификатом. Инвентаризация, оповещения и автоматическое распространение отзыва — анализ Theo March, а не обязательная схема RFC. RFC рекомендует, чтобы стойкость ключа подписи была не ниже стойкости ключа установления. При миграции, согласно операционному анализу, следует проверять сопоставимость стойкости, алгоритмы и правила эквивалентности.

Тестовые фикстуры должны включать действительный путь и подпись, недействительный путь, изменённую подпись, отсутствие встроенного сертификата у невыдавшего УЦ, успешное извлечение у выдавшего УЦ, различные субъекты и SAN с документированной эквивалентностью и без неё, запрос сертификата подписи, более слабый ключ подписанта, а также отдельные проверки размещения PKCS#10 и CRMF. В журнале связываются издатель и серия, отпечатки запроса и ключа, решение политики и выданный сертификат.

При инциденте остановить выдачу от подозрительного сертификата подписи и сохранить доказательства. Подтвердить компрометацию, быстро отозвать сертификат подписи, найти все производные сертификаты по его заявлениям и оценить или отозвать их по политике УЦ. Затем заменить необходимые ключи, пересмотреть решения об эквивалентности и силе и наблюдать за повторными запросами. Это операционный анализ, не полный процесс, предписанный RFC.

Источники