Кратко

  • draft-ietf-rats-epoch-markers-05 позволяет Epoch Bell выпускать повторно используемые маркеры, чтобы распределённые участники делили ограниченную координату свежести без достоверного гражданского времени у каждого attester.
  • Верная подпись аутентифицирует маркер и ключ Bell; она не доказывает одновременную доставку, уникальность сеанса, точность часов или момент измерения аттестационных данных.
  • Verifier должен сохранять квитанцию соединения с идентичностью и типом Bell, маршрутом, локальным временем получения, nonce, окном, состоянием защиты от replay и версией применённой политики.

Свежесть возникает между событиями

В аттестации важно не само текущее время, а то, достаточно ли близко измерение состояния к решению. Сначала устройство измеряет состояние, затем создаёт evidence, передаёт его, проходит appraisal, после чего relying party использует результат. Надёжные часы располагают события на шкале. Случайный challenge связывает ответ с одним запросом. Но ограниченное устройство не всегда поддерживает защищённые часы, а relying party не всегда разговаривает с ним напрямую.

Epoch Bell даёт общий ритм. Она выпускает Epoch Markers, а attester включает маркер или короткий handle в защищённое evidence. Verifier сравнивает координату с ещё допустимой границей. Проект поддерживает разовый challenge-response, незапрошенный broadcast или multicast и подписку по запросу.

Общий ритм не равен абсолютному времени. Если формат несёт POSIX-время, утверждение зависит от часов и эксплуатации данной Bell. Если это счётчик, он показывает порядок только в контексте, который хранит его состояние. Свежесть появляется из связи выпуска, доставки, создания evidence и окна решения.

У каждого формата собственная цена доверия

Редакция 05 перечисляет временные CBOR-теги, классический TSTInfo RFC 3161, его CBOR-представление, Epoch Tick, Tick List, монотонный счётчик и epoclet. Это не взаимозаменяемые упаковки.

Временным вариантам нужны надёжные часы Bell. Счётчику нужна непрерывность состояния. Tick можно повторно применять для многих потребителей — в отличие от verifier nonce для одного обмена. Список помогает получателю догнать несколько недавних позиций, но требует локального состояния и правил ресинхронизации. Epoclet размером примерно 44–64 байта соединяет POSIX-время, идентификатор ключа deployment и HMAC. Компактность переносит ответственность на хранение общего секрета, его ротацию и синхронизацию серверных часов.

Подпись или MAC подтверждают ограниченную фразу: ожидаемый ключ аутентифицировал эти байты в данном формате. Они не доказывают правильность часов, отсутствие повтора счётчика после сбоя или одновременное получение выпуска всеми адресатами. COSE, CWT, CBOR и концептуальные сообщения RATS защищают утверждения и связывают поля; эксплуатационное предположение от этого не становится физическим фактом.

У одного выпуска много времён прибытия

Очереди, репликация multicast, прерывистые линии и промежуточная обработка создают задержку и skew. Опоздавший маркер остаётся подлинным. Ближний verifier может уже получить tick 820, пока удалённая площадка всё ещё принимает 818. Если 820 объявить всеобщей границей, перспектива самого быстрого маршрута станет обязательным «настоящим» для всех, а честное evidence медленного attester будет отвергнуто. Если 818 не ограничить сроком, старый перехват станет удобен для replay.

Различие проявляется в Passport и Background-Check. В первом случае attester несёт evidence к relying party. Во втором appraisal может выполнить отдельная служба и вернуть Attestation Result. Результат должен оставаться связанным с marker или handle, а политика обязана учитывать реальный путь до принимающей стороны.

Широкое окно терпит расстояние, сон устройства и очередь обработки, но продлевает полезность когда-то хорошего перехваченного evidence. Узкое окно сокращает replay и увеличивает ложные отказы. Для решения нужны локальное время получения, ожидаемый канал, бюджет транспорта и обработки, явное истечение. Универсального окна в протоколе нет.

Повторное использование не создаёт одноразовость

Epoch Tick намеренно используется многократно. Многие attesters могут сослаться на один выпуск Bell, что делает распространение масштабируемым. По той же причине Tick не получает свойства одноразового challenge лишь от того, что находится в подписанном token.

Когда сеансу нужна уникальная привязка, verifier добавляет свой nonce. Проект требует не менее 64 бит энтропии от криптографически стойкого генератора и допускает до 512 бит. Nonce отвечает: «Это ответ на мой запрос?» Marker показывает: «С какой позицией Bell связано evidence?» Оба значения следует защитно связать с идентичностью или ключом attester и digest доказательства.

Иначе атакующий переносит ещё допустимый marker к старому evidence или в другой сеанс. Политика также закрепляет Bell, ключ, domain, scope, тип и алгоритм. Если недоверенная сторона выбирает самое слабое толкование, согласование превращается в downgrade, а не в безобидную оптимизацию размера.

Область состояния распределяет ложные отказы

Сравнение Ticks и счётчиков требует памяти. Один highest-seen для всего домена стоит дёшево, но позволяет самому быстрому маршруту сдвигать границу для всех attesters. Медленные участники выглядят устаревшими, хотя действовали верно. Состояние на каждого attester дороже, зато разделяет историю и особенности связи.

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

Ресинхронизация тоже нуждается в происхождении. Tick List помогает догнать позиции, но не решает, как долго принимать старый элемент. Сброс счётчика после потери состояния похож на rollback. Ротация ключа начинает новую эпоху доверия, даже если видимое время не прерывается. Следует хранить прежнюю границу, эпоху ключа, причину и правило допуска перехода.

Bell может ошибаться с правильной подписью

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

Нужны названный оператор, custody, ротация и отзыв ключей, наблюдение за часами или состоянием, измерение распространения и правила для markers, выпущенных в период инцидента. Несколько Bells сами по себе не создают консенсусное время. Политика должна назвать их альтернативами, отдельными scopes или quorum.

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

Хранить нужно соединение, а не только marker

Долговечная квитанция начинает с идентичности Bell, проверочного ключа и его эпохи; типа, байтов или digest marker; domain, scope и заявленного времени выпуска, если оно есть. Отдельно сохраняются локальное получение, канал, измеренная или заложенная задержка и правило окна.

Затем запись связывает attester, digest evidence и контекст измерения. Если применялся verifier nonce, остаются nonce и сеанс. Указывается область состояния — глобальная, на каждого attester или иная, — предыдущая граница, результат replay или reordering, ресинхронизации и точная версия политики. Решение, срок, отзыв и пересмотр завершают квитанцию.

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

На дату исследования редакция 05 была активным Internet-Draft группы RATS, обновлённым 3 июля 2026 года и истекающим 4 января 2027-го. Datatracker показывал «WG Document Doc Shepherd Follow-up Underway» и состояние IESG «I-D Exists», без ответственного area director и даты telechat. Заголовок документа говорил Standards Track, а intended RFC status в Datatracker оставался пустым. Расхождение следует сохранить; это сведения о процессе, не доказательство deployment.

Источники