Кратко

  • 24 августа IESG открыла Last Call по draft-ietf-rats-endorsements-09. До 7 сентября принимаются комментарии о публикации в статусе Informational RFC; окончательного решения нет.
  • Anton Sokolov в публичном замечании, авторство которого необходимо сохранять, отделил неизменность содержания claim от продолжающегося standing Endorser и спросил, проверяется ли этот статус в момент Evidence или в момент appraisal.
  • Авторы ответили, что CoRIM уже содержит отдельные окна для содержания и подписи. Комментатор признал вопрос решённым, а редакторы всё равно решили зафиксировать различие в проекте.
  • Pull request 76 был слит 28 августа. В latest Editor's Copy теперь описаны rim-validity, signature-validity, отзыв и trust anchor, однако в нумерованной версии 09 этих абзацев нет.
  • Протокол рассмотрения комментария должен связывать сообщение, ответ, проверенный diff, merge, следующую версию, выбор policy, результат appraisal и действие IESG. Тогда редакторский merge не сможет выдать себя за одобрение IETF.

Формальный Last Call привязан к версии 09

Объявление IESG от 24 августа запросило комментарии по RATS Endorsements. Рабочая группа Remote ATtestation ProcedureS просит опубликовать версию 09 как Informational RFC. Срок — 7 сентября.

На момент проверки Datatracker по-прежнему показывал revision 09, состояние «In Last Call», отсутствие telechat date и окончательного действия IESG. Более свежий main не отменяет эту запись. Он описывает редакторский слой, а не новый нумерованный Internet-Draft и не разрешение на публикацию.

Архитектура RATS сама построена на разделении ролей. Attester выпускает Evidence о состоянии системы. Verifier оценивает его с помощью Reference Values, Endorsements и Appraisal Policy for Evidence. Verifier Owner управляет этой policy; Relying Party Owner решает, как использовать Attestation Result. Endorser добавляет утверждения, но подпись не даёт ему право окончательно определять доверие.

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

Оба положения допустимы. Однако второе можно было прочитать как ответ и на первый вопрос: если содержание статично, больше проверять время незачем.

Неизменное утверждение не останавливает время для его автора

Anton Sokolov изложил различие в публичном комментарии. Аппаратное свойство может оставаться прежним, пока сертификат производителя истекает, ключ отзывается или Verifier удаляет соответствующий trust anchor. Неизменность фразы и актуальная приемлемость того, кто её подписал, — независимые свойства.

Вопрос T1/T2 сделал границу практической. Если Evidence зафиксировало состояние в T1, а Verifier проводит appraisal в T2, на какой момент должен быть действителен standing Endorser? Комментарий поддерживал публикацию, не сообщал об атаке, компрометации устройства или отказе реализации и просил назвать выбор.

Наблюдение принадлежит Sokolov, а не Daniel Kade. Самостоятельный вклад статьи — схема институционального следа: как доказать обработку замечания, точное изменение текста и переход результата к каждой следующей стадии полномочий.

Автор документа Thomas Fossati сначала переформулировал границу: проверки standing логически независимы от временных свойств содержания, а T1 или T2 выбирает протокол либо appraisal policy. Sokolov согласился и предложил отражать выбор в результате.

Затем Fossati показал существующий механизм. CoRIM processor хранит независимые окна для содержания и подписи. В его примере подпись, отзыв и состояние trust anchor проверяются во время appraisal, то есть в T2. Идентификатор Verifier в Attestation Result способен сделать этот выбор понятным. После этого Sokolov закрыл вопрос, поскольку существующая конструкция дала нужный ответ без нового механизма.

Ответ мог остаться только в архиве рассылки. Редакторы решили перенести его след в исходный текст.

Слитая поправка различает содержание, оценку и standing

Pull request 76 открылся 25 августа, прошёл несколько редакционных изменений и получил approvals от Dave Thaler и Henk Birkholz. 28 августа его слили коммитом bb53db0c7c6203f82cfad9cd3c4b5eaf8b6fd624.

В актуальной Editor's Copy один и тот же замер прошивки H может получить доверительную оценку до обнаружения уязвимости и недоверительную после. Оба Endorsements способен подписать Endorser, чей standing всё время оставался приемлемым. Окно rim-validity ограничивает содержание и показывает, какое сообщение применимо.

Отдельно меняется состояние Endorser. Ключ, сертификат или trust anchor могут перестать приниматься. signature-validity ограничивает подпись; указанный CoRIM processor проверяет это окно, отзыв и anchor status в момент appraisal. Текст не делает T2 универсальным правилом: конкретный протокол или policy выбирает ориентир и должен его документировать.

Поэтому движутся как минимум три объекта: значение Environment, оценка этого значения Endorser и standing самого Endorser. Один флаг valid может скрыть, из-за какого из них два корректных Verifiers разошлись.

Merge подтверждает редакторскую обработку, а не решение IESG

Diff, reviewers и merge commit доступны для проверки. Тем не менее страница называется draft-ietf-rats-endorsements-latest. Это не revision 10 и не RFC. Нумерованная версия 09 в Last Call не содержит дополнение.

Такое расхождение нормально для Internet-Drafts. Редакторам нужна рабочая ветка, чтобы собрать замечания до новой подачи. Ошибка начинается, когда из дальнейшего пересказа исчезают статусы. «Редакторы слили исправление», «Working Group подала версию 09» и «IESG одобрила публикацию» — разные действия разных органов. Сейчас доказаны первые два, причём они относятся к разным снимкам текста. Третье не произошло.

Критерий отмывания мандата Heng Lu показывает границу без лишней теории. GitHub доказывает, какие bytes приняли редакторы, но не создаёт полномочия IESG. Обратная ошибка — ссылаться на официальный статус 09 и делать вид, будто более свежего улучшения нет. Надёжная запись соединяет уровни, не сливая их.

Протокол диспозиции от комментария до спецификации

Mail Archive, GitHub, Editor's Copy и Datatracker уже содержат детали. Их можно связать компактным протоколом, не создавая ещё одного органа одобрения.

Сначала он фиксирует стабильный URL комментария, дату, автора, затронутые revision и section и явную disposition: принято, принято частично, отвечено существующим механизмом, отложено или отклонено. Затем присоединяет ответ ответственного редактора, issue или pull request, head и merge commits, reviewers, время слияния и ограниченное описание изменений.

Формальная часть называет первую нумерованную версию с новым текстом, последующее состояние IESG и номер RFC, если он появится. Для двух часов также нужны окно содержания, окно standing, Evidence time, appraisal time, владелец policy, сделавший выбор, и идентичность Verifier либо версии policy, достаточная для интерпретации результата.

В конце записывается невывод. Полезный комментарий не равен консенсусу всей IETF. Merge не разрешает публикацию. Верная подпись подтверждает целостность по заданному пути доверия, но сама по себе не доказывает истину claim, институциональное право Endorser или надёжность устройства.

Частную переписку раскрывать не требуется. Достаточно публичных ссылок, хэшей, ролей, времени и состояний. Протокол не заменяет список, редакторов, Working Group или IESG. Он не позволяет одному уровню присвоить полномочия следующего.

Источники