Кратко

  • RFC 9883 позволяет владельцу сертификата подписи заявить о владении другим закрытым ключом для установления ключей, не выполняя этим вторым ключом технического доказательства.
  • CA обязан проверить путь сертификата подписи, подпись запроса и идентичность имён, а также применить политику, явно разрешающую такую замену.
  • Компрометация подписывающего ключа создаёт зависимый набор: сертификаты установления, выданные по его заявлениям, следует найти и отозвать.

В деле есть новый открытый ключ, атрибут владения и успешно проверенная подпись. Но подпись создал закрытый ключ прежнего сертификата. Закрытый ключ, соответствующий новому открытому ключу, не выполнил ни одной проверяемой операции.

Два ключа означают два разных факта

Сначала субъект создаёт пару для подписи, подписывает обычный запрос и получает сертификат подписи. Затем он создаёт пару для установления ключей. Второй запрос PKCS#10 содержит новый открытый ключ и privateKeyPossessionStatement, указывает прежний сертификат и подписывается первым закрытым ключом.

RFC 9883 точно определяет смысл: субъект сертификата подписи заявляет без предоставления доказательства, что владеет закрытым ключом установления. CA может принять заявление вместо технического POP только когда это разрешает политика сертификатов. RFC 6955 предлагает технические методы для некоторых DH- и ECDH-ключей, но они не подходят для PKCS#10 и не поддерживают KEM наподобие ML-KEM. Новый атрибут пригоден для PKCS#10 и CRMF.

Таким образом, валидная подпись доказывает контроль над подписывающим ключом в данном запросе. Она связывает ранее удостоверенного субъекта с утверждением о другом ключе. Она не показывает место генерации второго ключа, возможность его экспорта, текущую доступность или хранение в конкретном аппаратном модуле.

Недостающее доказательство заменяет политика

CA должен проверить путь сертификата подписи по RFC 5280 и подпись запроса его открытым ключом. Неудача требует отказа. Имена субъектов желательно должны совпадать. Если субъект или альтернативные имена различаются, политика обязана описать способ установить одну и ту же сущность; невозможность сделать это также означает отказ.

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

В CRMF используется вариант подписи в ProofOfPossession, обязательны poposkInput, отправитель и копия нового открытого ключа, а заявление помещается в regInfo. Формат иной, но ключ установления по-прежнему не выполняет доказательства.

Поэтому атрибут запрещено применять для получения сертификата подписи. Ключ, способный подписывать, может прямо доказать владение подписью собственного запроса. Исключение относится только к более узкой задаче ключей установления.

Граф отзыва начинается при выдаче

Получив подписывающий ключ, злоумышленник сможет создавать новые заявления. Защитой служит своевременный отзыв сертификата подписи. Если CA отзывает его из-за компрометации, следует также отозвать сертификаты установления, полученные по подписанным им заявлениям.

Для этого с момента выдачи нужен обратный индекс: сертификат подписи, байты запроса, версия политики, решение об идентичности и все выданные результаты. Подписывающий ключ должен быть не слабее ключа установления, иначе мост доверия станет слабейшим звеном.

Источники