Кратко

  • IESG одобрила draft-ietf-acme-device-attest как Proposed Standard 30 июля 2026 года. Редакция 10 находится в очереди RFC Editor; окончательный номер RFC и внедрение не предполагаются.
  • device-attest-01 может сопоставить идентификатор Order, аттестованный открытый ключ и ключ CSR. Сила утверждения зависит от формата, центра аттестации и покрытия одного token либо привязанной к учётной записи key authorization.
  • Доказательство разрешает один выпуск. Оно не обновляет состояние устройства, а сертификат с защитой приватности может вовсе не содержать аппаратного идентификатора.

Что скрывает один флаг

Валидный сертификат часто получает расширенное толкование: «это доверенное устройство». Формулировка не сообщает, какой challenge был выполнен, кто заверил сведения, совпал ли ключ с CSR и когда проверялось состояние прошивки.

Одобренное расширение добавляет permanent-identifier для идентичности, обычно назначенной производителем, hardware-module для типа и серийного номера криптопроцессора и challenge device-attest-01. IANA уже показывает записи со ссылкой RFC-to-be. Это факт координации реестра, а не подтверждение реализации в продукте.

Сервер выдаёт свежий token. В обычном варианте клиент соединяет его с отпечатком ключа учётной записи ACME, получает key authorization и аттестацию нужного формата. Для выпуска должны сойтись три элемента: приемлемый центр аттестации, один открытый ключ в аттестации и CSR, один идентификатор устройства в аттестации и Order. Если идентификатор включён в CSR и сертификат, требуется побайтовое совпадение.

Некоторые внешние центры подписывают до появления ключа учётной записи ACME и покрывают только token. Это обеспечивает свежесть, но не связь с учётной записью. Единый признак attested=true стирает существенное различие.

Предложенный challenge мог не выполняться

В одной authorization сервер может предложить device-attest-01 вместе с другим challenge. Достаточно выполнить один из них. Это облегчает переход неоднородного парка, но требует фиксировать фактически пройденный путь.

Поддержка аттестации продуктом и даже её присутствие в предложении сервера не доказывают, что конкретный Order прошёл её. External Account Binding решает отдельную задачу допуска корпоративной учётной записи. Он не доказывает нахождение CSR-ключа в заявленном модуле; аттестация устройства не делает права учётной записи вечными.

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

Аппаратная идентичность может остаться у CA

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

Постоянный серийный номер в сертификате или журнале прозрачности связывает продления и предъявления на годы. Ротация ключа не устраняет корреляцию; раскрытие может стать необратимым и неоправданно связать переносимую службу с физическим блоком.

Обратная сторона границы столь же важна: relying party не должен выдумывать аттестацию из сертификата без идентификатора. Без отдельной квитанции он не знает формат, центр, challenge или проверенные параметры прошивки.

Payload может содержать прошивку, состояние загрузки, ОС и уровень аппаратной защиты. CA вправе отказать из-за них, но проект не унифицирует проверку всех форматов. TPM, TEE и защищённое ОС хранилище дают разные гарантии. У каждого параметра есть время наблюдения; срок сертификата не равен свежести состояния.

В слоях реальности Heng Lu одобрение IESG, запись IANA, успешный challenge, выпуск, текущее состояние и разрешение доступа остаются отдельными квитанциями. Такая точность делает автоматизацию проверяемой.

Источники