Кратко

  • 2 сентября 2026 года IESG открыл Last Call по редакции 29 Use of Remote Attestation with Certification Signing Requests; комментарии принимаются до 16 сентября. Документ нацелен на Proposed Standard, но пока остаётся Internet-Draft, а не утверждённым RFC или свидетельством внедрения.
  • В одном запросе PKCS #10 или CRMF можно передать несколько аттестаций. CA или RA всё равно обязаны доказать, что открытый ключ, HSM, собственность на платформу, её состояние и контекст свежести относятся к одной прослеживаемой операции.

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

Проект стандартизует компактный контейнер. AttestationStatement содержит OID типа и само утверждение. AttestationBundle включает одно или несколько утверждений и может нести сертификаты. Один bundle верхнего уровня помещается под id-aa-attestation в атрибут PKCS #10 или расширение CRMF.

Контейнер решает доставку, но не создаёт связь. Необязательные сертификаты могут помочь построить путь проверки. Само присутствие не устанавливает порядок полномочий, правильный Trust Anchor или политику выпуска. Разбор структуры, проверка пути и разрешение на сертификат — разные действия.

Форматы вложенных аттестаций проект не определяет и нового реестра не создаёт. Формат и OID задаются другими стандартами или поставщиками. Значит, OID — метка маршрутизации, а не печать истинности. Декодирование не равно проверке подписи; валидная подпись не выбирает доверие; доверие подписанту не связывает утверждение с рассматриваемым открытым ключом.

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

Цепочка начинается с открытого ключа CSR. Proof of possession показывает контроль соответствующего закрытого ключа в протоколе запроса. Она не доказывает место генерации, невозможность экспорта, владельца оборудования, исправность платформы или право заявителя на сертификат.

Утверждение HSM закрывает лишь один промежуток. CA/RA требуется устойчивый идентификатор связи HSM с платформой. Документ о собственности должен описывать ту же платформу и охватывать нужный период. Измерение состояния должно относиться к тому же объекту, с определённой эпохой и эталонными значениями. Совпадение названий или производителя недостаточно.

Свежесть сужает окно повтора, но не создаёт идентичность. Сопутствующий проект удерживает nonce и CSR в контексте одной PKI-операции: CMP может использовать контекст транзакции, EST — ту же TLS-сессию или сохранённое HTTP-состояние. Если CA/RA не может сопоставить CSR с прежним обменом, считать их связанными нельзя.

При запросе свежести nonce имеет длину от 8 до 64 октетов; нулевая длина означает отсутствие требования. Ведущий Attester может передать один nonce подчинённым Attesters. Несколько Evidence отвечают на общий временной вызов, но это не доказывает один ключ или одну платформу.

RFC 9334 отделяет свежесть от продолжительности состояния. После выпуска Evidence могут измениться ПО, собственник или безопасность устройства. У измерения есть момент времени; сертификат обычно действует значительно дольше.

Поэтому решение с последствиями остаётся у CA/RA. Они выбирают допустимые форматы, Trust Anchors, эталоны, правила оценки и профиль выпуска. Данные можно проверить по одной из нескольких политик или отбросить как не относящиеся к применимой политике. Проект советует описывать требования в certification practice statement.

Версия политики входит в доказательство решения. Воспроизводимый журнал хранит хеш и ключ CSR, байты утверждений, подписантов, версии Verifiers, эталонные значения, nonce и контекст, запись о собственности, результат оценки, выбранную политику и субъекта, разрешившего выпуск.

Публичный сертификат не должен становиться таким архивом. Идентификаторы оборудования, firmware, патчи, собственность и состояние цепочки поставок раскрывают чувствительные сведения. Редакция 29 не рекомендует копировать аттестации в сертификат. Риск остаётся в регистрационных логах, сохранённых bundles и записях Verifiers.

Разделение уровней реальности у Heng Lu не позволяет одному документу подменять следующий. Наличие проекта, корректный синтаксис, проверенная подпись, положительная оценка, выпуск, развёртывание и принятие Relying Party — отдельные факты. Общий стандарт координирует конверт; операционную истину должен показать CA/RA, который принимает последствия.

Источники