要約

  • draft-ietf-rats-epoch-markers-05はEpoch Bellが再利用可能なマーカーを発行し、個々のattesterに正確な実時間時計を要求せずに、分散した参加者が限定的な鮮度座標を共有する方法を示す。
  • 正しい署名はマーカーとBellの鍵を認証するが、同時配信、セッションごとの一意性、時計の正確さ、証拠を測った瞬間までは保証しない。
  • Bellの識別子と形式、配信経路、ローカル受信時刻、nonce、許容窓、再送状態、判断に使った方針版を「鮮度結合受領書」に残すべきだ。

鮮度は一つの時刻では決まらない

アテステーションで必要なのは、現在時刻そのものではなく、観測した機器状態が今の意思決定に十分近いかという判断だ。状態の測定、証拠の生成、転送、鑑定、利用にはそれぞれ時間がある。信頼できる時計は位置を与え、ランダムなchallengeは一回の要求に応答を結び付ける。しかし小さな機器が安全な時計を維持できるとは限らず、relying partyが全機器と直接challenge-responseできるとも限らない。

Epoch Bellは共通の拍を発する。attesterは受け取ったEpoch Markerまたはそのhandleを、保護された証拠に入れる。検証者は、自分がまだ受け入れるBell上の位置と比較する。案は臨時のchallenge-response、要求なしのbroadcastやmulticast、要求に基づくsubscriptionを扱う。

これは便利な座標だが、絶対時刻ではない。POSIX時刻を含む形式なら、その意味はBellの時計と運用に依存する。単調カウンターなら、状態を維持するBellの範囲で順序を示すだけである。鮮度は発行、到着、証拠生成、検証方針の関係として成立する。

形式ごとに信頼の置き場が変わる

第05版にはCBOR time tag、RFC 3161のTSTInfo、そのCBOR版、Epoch Tick、Tick List、単調カウンター、epocletが並ぶ。単なる符号化の選択ではない。

時間を持つ形式はBell側の信頼できる時計を必要とする。カウンターは状態の連続性を必要とする。Tickは多数の利用者が同じ値を再利用でき、単一交換用のverifier nonceとは性質が違う。Tick Listは最近の位置をまとめて知らせるが、受信者側の状態と再同期規則が要る。約44〜64バイトのepocletはPOSIX時刻、配備固有の鍵識別子、HMACを組み合わせる。短さと引き換えに、共有鍵の保管、ローテーション、サーバー時計の同期が運用責任になる。

署名やMACが立証する命題は限定される。期待した鍵が、定義された形式のバイト列を認証した。それ以上に、時計が正しかった、再起動後もカウンターが戻らなかった、全受信者が同時に同じTickを見た、鍵が侵害されなかった、とは言えない。COSE、CWT、CBOR、RATSの概念メッセージは主張を保護し、項目を結合するための道具であり、運用上の前提を自然法則にはしない。

同じ発行でも到着は同じではない

キュー、multicast複製、断続回線、中継処理は遅延とskewを生む。近い検証者がtick 820を受け取っていても、離れた拠点は818を許容しているかもしれない。全体に一つの「最高値820」だけを適用すれば、最速経路の視点を全員の現在として扱い、遅いが正直なattesterを拒む。818を無期限に認めれば、過去に捕捉された証拠を再利用しやすくする。

Passport型ではattesterが証拠をrelying partyへ運ぶ。Background-Check型では別の場所でappraisalを行い、Attestation Resultが意思決定者に届くことがある。どちらでもResultは利用したmarkerまたはhandleに結び付けられ、方針はrelying partyまでの実際の経路を考慮しなければならない。

広い許容窓は遠隔地、休止中の機器、処理待ちに強いが、取得済みの良い証拠が使える期間を延ばす。狭い窓は再送を抑え、正当な遅延を誤って拒みやすい。ローカル受信時刻、想定チャネル、転送と処理の予算、期限を明示して初めて比較可能な判断になる。

再利用可能と一回限りは別の性質

Epoch Tickは意図的に再利用される。多数のattesterが一つのBell発行を引用できるため、配信は効率的になる。一方、そのTickが署名トークンに入っているだけでは、一回限りのchallengeと同じ意味を持たない。

一意のセッションを要求するなら、検証者は独自のnonceを加える。案は暗号学的に安全な乱数生成器による最低64ビットのエントロピーを求め、最大512ビットまでを想定する。nonceは「私の要求への応答か」を確かめ、markerは「Bellのどの位置に結び付くか」を表す。attesterの識別子または鍵、証拠のdigest、nonce、markerを同じ保護構造で結合しなければ、許容中のmarkerを古い証拠や別セッションへ移植され得る。

期待するBell鍵、配備domain、scope、marker type、algorithmも方針で固定する。不信な相手が時間トークンを弱い意味のカウンターへ切り替えられるなら、形式交渉はdowngrade経路になる。これはデータ量の最適化ではなく、証明内容の変更だ。

状態の単位が誤拒否の配分を決める

Tickやカウンターの比較には記憶が要る。Bell全体でhighest-seenを一つだけ保存する設計は安価だが、最も速い経路が全attesterの境界を進める。attesterごとの状態はコストが増えるものの、接続特性と履歴を分離できる。

常時接続のデータセンター群なら、全体境界と短い窓が合理的かもしれない。断続的な産業機器なら、個別履歴、明示的な休止状態、Bellや検証者の再起動後の復旧手順が必要になる。数値比較の裏側には、保存コストを誰が負い、誤拒否を誰が受けるかという統治判断がある。

再同期も記録対象だ。Tick Listは追い付く材料を与えるが、古い要素をいつまで認めるかは別の判断である。状態喪失後のcounter resetはrollbackに見える。Bellのkey rotationは表示時刻が連続していても、新しいtrust epochを始める。以前の境界、鍵の時代、移行理由、承認規則を保存しなければならない。

署名が正しくてもBellは誤り得る

侵害または誤設定されたBellは、暗号的に正しいmarkerを発行できる。時計が飛び、カウンターが重複し、同じ鍵が二地点で動き、受信者ごとに遅れた眺めを渡すこともある。署名検証は成功しながら、鮮度の前提が壊れる。

Bell運用者、鍵のcustody・rotation・revocation、時計または状態のhealth、配信測定、不確実期間のincident ruleを明示する必要がある。複数Bellも自動的に合意時刻を作らない。代替なのか、別scopeなのか、quorumなのかを方針が定めて初めて意味を持つ。

予測可能なTickは、暗号化された通信にも相関の手掛かりを与える。同じ発行付近のメッセージをまとめられるからだ。発行間隔、増分、scopeを変えればlinkabilityを下げられる場合があるが、許容窓と状態条件は再計算が必要になる。プライバシー対策を後付けにはできない。

Markerではなく結合過程を保存する

鮮度結合受領書には、Bellの識別子、検証鍵と鍵の時代、marker type、値またはdigest、domainとscopeを記録する。形式が発行時刻を含むならBellの主張として保存し、別にローカル受信時刻、配信チャネル、測定または予算化した遅延、許容窓を書く。

次にattester、証拠digest、測定コンテキストを結ぶ。verifier nonceを使った場合は、nonceと対象セッションを残す。状態が全体、attester別、その他のpartitionのどれか、以前の境界、replayやreorderingの結果、再同期、採用した方針版も欠かせない。decision、expiry、revocation、reviewを加えれば、後日Bellの事故が判明しても影響した判断を探せる。

これらはEpoch Marker自体に押し込むべき項目ではない。相互運用する最小の対象を保ち、将来の選択を各現場に置き、現実に行われた判断を証拠として残す。その区別が、便利な座標を万能時計と誤認しないための統治になる。

調査時点で第05版はRATSワーキンググループの有効なInternet-Draftで、2026年7月3日に更新され、2027年1月4日に期限を迎える。DatatrackerのWG状態は「WG Document Doc Shepherd Follow-up Underway」、IESG状態は「I-D Exists」で、担当area directorもtelechat日もない。文書ヘッダーはStandards Trackだが、Datatrackerのintended RFC status欄は空だった。この差は消さずに扱うべきであり、いずれも配備実績ではなく標準化過程の事実である。

情報源