Кратко

  • RFC 9763 позволяет заявителю доказать контроль закрытого ключа уже выданного сертификата, после чего центр может поместить хеш всего старого сертификата в новый.
  • Эта связь описывает решение при выдаче. Она не требует совместного использования, не показывает, что оба ключа действовали в текущем сеансе, и не определяет, достаточно ли одной успешной аутентификации.
  • Для воспроизводимого контроля нужно отдельно хранить регистрационное доказательство, политику центра, точные байты сертификатов, результаты обоих путей, текущие подписи, переговоры и локальное решение узла.

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

Все эти факты могут быть истинными одновременно. Ошибка начинается, когда связь сертификатов называют завершённой двойной аутентификацией.

RFC 9763 определяет атрибут запроса relatedCertRequest и расширение X.509 RelatedCertificate. Они дают дополнительную уверенность, что два сертификата конечного субъекта принадлежат одному субъекту. Стандарт специально уточняет: механизмы выражают связь, но сами по себе не выполняют функцию безопасности.

В запросе участвуют два ключа

Пусть Cert A уже существует, а Cert B запрашивается, например в ходе перехода от классической криптографии к постквантовой. Обычный запрос B содержит новый открытый ключ. В PKCS#10 из RFC 2986 подпись связывает имя, открытый ключ и атрибуты и демонстрирует владение соответствующим закрытым ключом.

RFC 9763 добавляет отдельное действие ключа A. Атрибут содержит издателя и серийный номер A, время запроса, местоположение и подпись. Закрытый ключ A подписывает конкатенацию DER-кодированного идентификатора и BinaryTime.

По RFC 6019 BinaryTime — число секунд после полуночи UTC 1 января 1970 года без високосных секунд. Формат общий, но допустимый возраст доказательства задаёт локальная политика центра. В журнале нужны само время, момент проверки, предел и версия политики, а не только результат «свежее».

У центра нет одной волшебной проверки

Поддерживающий атрибут центр должен получить A, проверить путь по RFC 5280, сопоставить издателя и номер с certID, применить правило свежести и проверить подпись открытым ключом A.

Получение отвечает, какие байты пришли. Путь — к какому доверенному якорю они были приведены при заданных политиках. Сопоставление — тот ли это сертификат. Время — приемлемо ли доказательство сейчас. Подпись — действовал ли ключ A над конкретными данными.

RFC 5280 рассматривает якоря и политики как входы алгоритма. Минимально корректный путь может не подходить приложению. Если присутствуют key usage и extended key usage, ограничения обоих расширений действуют независимо.

После проверок центр может выдать B с расширением связи. Оно должно ссылаться только на A из запроса. У A должны быть назначения ключа, заявленные для B. Желательно убедиться в действительности A на момент выдачи. Полезное пересечение сроков остаётся ответственностью подписчика.

Поэтому действительность A сегодня не гарантирует работоспособность пары весь срок B. Отзыв, окончание срока или перевыпуск A могут разрушить эксплуатационную пару, не меняя исторической корректности выдачи.

Хеш связывает точные байты

В B записываются алгоритм и хеш полного Cert A. Это не абстрактная личность, не одно имя субъекта и не только открытый ключ. Проверяющая сторона может локально пересчитать значение над полученным A.

Так получается узкое детерминированное правило без онлайн-разрешения центра. Но перевыпущенный A с тем же именем и ключом может иметь другой номер, срок, расширения и подпись. Его хеш будет другим, и он не заменит автоматически версию, указанную B.

Инвентаризация по имени способна скрыть расхождение. Нужны отпечатки конкретных артефактов. Расширение не следует делать критическим, иначе пострадает совместимость, и оно допускается только в сертификате конечного субъекта. Старое ПО может его проигнорировать; отсутствие ошибки не означает проверку связи.

После совпадения начинается решение

Узел, поддерживающий некомпозитную гибридную аутентификацию, может получить A и B, найти расширение, вычислить хеш A и сравнить. Дальнейшее поведение RFC оставляет протоколу и локальной политике. Один узел требует успеха обеих аутентификаций, другой допускает хотя бы одну.

В CMS и S/MIME материал выбирает подписывающая сторона, а в протоколе с согласованием проверяющая сторона может выразить предпочтение. RFC 5652 задаёт CMS, RFC 8551 — используемую упаковку сертификатов. Формат не принимает прикладное решение.

Связь не является требованием или мандатом применять сертификаты вместе. Она лишь утверждает возможность совместного применения, потому что ключи контролирует один субъект. Центр отвечает за утверждение при выдаче; принимающий узел — за риск текущего соединения.

Контроль тогда не доказывает контроль сейчас

Гибридной системе нужны доказательства общего контроля ключей при регистрации для центра и при использовании для проверяющей стороны. Подпись relatedCertRequest относится к первому моменту. Обычный запрос относится к новому ключу. Расширение сохраняет связь. Поздний сеанс всё равно требует актуальных действий ключей.

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

Это отличает тему от RFC 9883. Там сертифицированный ключ подписи может сделать политически приемлемое заявление о владении другим ключом установления, не доказывая технически владение вторым. RFC 9763 использует реальную подпись A и обычную подпись запроса B, затем фиксирует связь. Здесь важно не повысить регистрационное доказательство до доказательства сеанса.

RFC 9955 исследует свойства гибридных подписей и правила комбинации. RFC 9763 не выбирает универсальный комбинатор, а предоставляет сигнал связи для внешнего правила.

Между центрами появляется договорная зависимость

Один центр обычно знает репозиторий и якоря для A. Другая организация, выдающая B, может не уметь проверять A. RFC предусматривает предварительные договорённости: договор, настроенные якоря и согласованные правила заявления, выдачи и принятия.

Общий субъект не означает равную силу политик. Проверка личности, защита ключей, отзыв и обязанности подписчика различаются. Центр B должен подобрать сопоставимую защиту, но сопоставимость — ответственное решение, а не свойство хеша.

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

Местоположение создаёт собственный риск

Атрибут указывает, где получить A. В одной организации HTTP(S) может вести к CMS-пакету с сертификатами. Между организациями рекомендуется data: URL с цепочкой и данными отзыва; схему задаёт RFC 2397.

Подписанный URL не делает содержимое безопасным. Он может вести на вредоносные данные, которые нужно разобрать и полностью проверить. Сетевой запрос также наблюдаем и может раскрыть сам факт обработки связи. Встроенные данные снижают утечку, но не отменяют валидацию.

Следует хранить способ получения, хеш объекта, результат разбора, материалы пути и отзыва, набор якорей. Один B не воспроизводит основания решения центра.

Откат происходит раньше проверки расширения

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

Нужны минимальные настройки, аутентифицированный протокол переговоров, телеметрия выбранного режима и сигналы регрессии. Число связанных пар показывает готовность, а не фактическое использование.

Такое разделение соответствует приоритету работающего кода Хэн Лу. Минимальная начальная спецификация, локальное будущее решение и добровольное принятие позволяют стандартизировать поля, подписи и хеш, оставляя принятие тому, кто запускает протокол.

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

Доказательства, которые можно воспроизвести

При регистрации сохраняются CSR, идентификатор A, время, адрес, подписанные байты, результат подписи и путь. При выдаче — байты и хеш A, байты B, назначения, политика и пересечение сроков.

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

Источники