要約

  • Roughtime 第19版は Experimental を意図する仕様で、署名応答を鎖状につなぎ、少なくとも一つの時刻が因果順序と両立しないことを証明する。その鎖だけで誤った鍵を一意に選べない場合もある。
  • 草案は信頼サーバーリストと不正報告の形式を定める一方、報告の受理、帰責、排除、リストの維持・配布を範囲外とする。しかも、これらの手続はセキュリティに不可欠だと明記している。
  • 可搬型の信頼失効レシートとして、報告ハッシュ、帰責の限界、権限ある審査、処分、旧新リストの署名、配布、クライアント採用、訂正経路を結ぶべきだ。これは Daniel Kade の提案であり、IETF の要件ではない。

正しく署名された誤時刻

長期間停止していた機器は、証明書の有効期間を判定できるほど現在時刻を知らないことがある。ところが安全な時刻サービスへ接続するための証明書検証にも、時刻が必要になる。Roughtime はこの循環に対し、認証されたおおまかな時間区間を提供し、信頼した情報源同士が食い違った場合に外部検証可能な痕跡を残す。

現行文書は draft-ietf-ntp-roughtime-19 で、2026年3月17日に公開され、想定ステータスは Experimental である。IESG は同日承認した。Datatracker では現在 RFC Editor queue にあり、9月4日に In Progress (Second Edit) へ移った。ただし編集が完了するまでは Internet-Draft である。この記事は RFC 公開済みとも、番号が付いたとも扱わない。

基本動作では、クライアントが新しい nonce を送る。サーバーは、自分が正しい時刻を含むと考える midpoint と radius の区間を返す。署名はクライアントの nonce を含む Merkle tree のコミットメントを覆うため、その長期鍵の保持者が要求を受け取った後に応答を生成したことを検証できる。

ここで認証されるのは発言者と応答であって、時計の正しさではない。健全な鍵でも、設定ミス、上流参照の故障、侵害、故意の虚偽によって誤った区間を署名し得る。そこで複数サーバーモードでは、前の応答から得た材料を次の要求へ組み込み、時刻区間を実際の通信順序に拘束する。

区間がその順序に収まらなければ、クライアントは要求、応答、公開鍵、乱数を保存し、別の検証者にも矛盾を再現させられる。それでも結論は限定される。「少なくとも一つが誤時刻を返した」のであって、鎖の形によっては「この一台が誤った」とは言えない。

鍵が応答を署名した事実、複数の応答が両立しない事実、その鍵を信頼集合から外すべきだという判断は別物である。最後の判断は暗号計算から自動的には出てこない。

仕様書は裁定を範囲外に置いている

第19版は制度上の空白を隠さない。信頼サーバーのリストを維持・配布し、不正報告を処理するエコシステムについて運用経験が必要だとする。そのうえで、本文を wire protocol と二つの形式に限定し、リストの維持方法、配布方法、適用方針は定めない。

報告から排除に進むには、追加の review and impeachment process が必要であり、その定義は範囲外である。個々の報告を受け入れるか拒むかの運用ルールも範囲外だ。セキュリティ考慮事項は、信頼リストの維持と違反の裁定に関する基盤・手続を「不可欠」と位置づける。

これはフィールドを一つ追加すれば消える欠陥ではない。署名や nonce の連鎖は決定的に検証できる。だが帰責には、共有する時刻源、鍵管理、radius、うるう秒、実装不具合、外部テレメトリを検討する必要がある。処分には期間、比例性、独立性、サービス継続性も伴う。

さらに malfeasance という語は意図的な不正を連想させる。証拠が直接示すのは不整合である。原因が過失か侵害か悪意かは別の調査事項だ。したがって最初の公的状態は、矛盾を検証済み、帰責は保留でなければならない。

署名検証の失敗や一般的なプロトコルエラーだけでは不正報告を送ってはならない、という規定も重要だ。この経路は因果順序の矛盾に固有であり、雑多なアラーム箱ではない。

リストは住所録ではなく信頼を実行する設定である

Roughtime ではサーバーの長期公開鍵が trust root となる。クライアントには、同じ主体が運用しない、稼働中のサーバーが最低三つ必要だ。また、不正検出の成果を利用するため、どのサーバーを信頼するかを更新すべきだとされる。

共通 JSON 形式には、名称、アドレス、バージョン、公開鍵に加え、別のリストの出所や HTTPS の報告先も入れられる。しかし形式の利用は OPTIONAL で、クライアントは別の構成方法を選べる。

この余地は、共通形式から世界唯一の管理者が生まれるのを防ぐ。OS ベンダー、企業、研究共同体はそれぞれリストを持てる。クライアントは更新を採用、延期、拒否、分岐できる。分岐はプロトコル上の違反ではない。

一方でリスト編集には現実の力がある。鍵の追加は、その応答を将来の測定に迎え入れる。削除は、採用したクライアントからその情報源を排除する。判断が遅ければ既知リスクが残り、急ぎ過ぎれば多様性を失う。理由を残さず復帰させれば、制度の記憶まで消える。

リスト管理者の権限は、利用者が委ねた範囲に限られる。サーバーを普遍的に処罰するのではなく、新しい信頼設定を提案する。その効果は、各クライアントが署名を確認し、ローカルに採用して初めて現れる。

大量報告時にも証拠を失わない

クライアントは不整合を検出したとき、技術的に可能なら報告を生成し、利用者へ通知し、別の測定を行う。リストに送信先があれば HTTPS POST を用いる。

著名なサーバーが故障すると、同時に大量の報告が届く。そのため草案は指数バックオフを必須とし、再試行間隔の目安を示す。しかし受信サービスを守る規則が、端末側の証拠廃棄を正当化してはならない。

受信者は内容ハッシュで報告を識別し、耐久的な保管を受領確認したうえで、完全な重複と異なる鎖を分けるべきだ。同じ再送を複数の票として数えてはいけない。同一鍵に関する異なる経路を一件に潰せば、障害の広がりを隠す。受領返答は「保存済み」であって「失効済み」ではない。

また、再現に不要なクライアント識別子は集めない。証拠の可搬性は、観測端末の台帳を作る理由にはならない。

帰責結果には限界を明記する

二つの整合した証言が一つの不可能な区間を挟む場合、特定鍵への疑いは強い。二つの相反する応答しかない場合は、どちらを外すべきか決められない。複数サーバーが同じ事業者や上流時計に依存することもある。鍵だけが盗まれ、運用主体は正常だった可能性もある。相関した多数派が誤り、外れ値が唯一正しいことさえある。

審査では全署名、nonce の結合、区間、radius、うるう秒、収集の完全性を再確認する。そのうえで「単一鍵を特定」「候補集合」「未帰責の矛盾」のいずれかを公表する。運用ログなど外部証拠を使うなら、暗号学的証明と別の来歴として記録する。

最初の有効報告で永久削除する自動化は、速さのために帰責を捏造する。絶対確実になるまで何もしない運用は、せっかくの証拠を無意味にする。期限付きの隔離や重み低下、調査、根拠公表、削除または復帰という段階的な処理が適切だ。

NTS と Khronos は別の問題を解く

RFC 8915 の NTS は TLS と AEAD を使い、NTP パケットの送信元、完全性、再送耐性を守る。選んだ相手との通信を認証するが、その相手の時計が正しいとは保証しない。

Roughtime は、時刻を知らない端末が NTS-KE の証明書を検証できる程度の初期区間を得るのに役立つ。加えて、署名時刻同士の矛盾を外部証拠にする。両者は境界が異なるため補完的である。

RFC 9523 の Khronos は NTP の選択とフィルタリングを強化し、クライアントを時刻ずらし攻撃から守る。Roughtime は第三者に示せる不整合を重視する。安全な選択は帰責記録を自動生成せず、帰責記録は次の信頼集合を自動選択しない。

RFC 8633 と RFC 7384 も、複数情報源、監視、悪意ある時刻源、証明書との依存を示す。しかしどの文書も、暗号方式から普遍的なリスト裁定者を生み出してはいない。

可搬型の信頼失効レシート

Daniel Kade が提案する可搬型の信頼失効レシートは、プロトコル外の橋を記録する。新しいパケットでも中央法廷でもない。

最初に、報告ハッシュ、応答鎖、検証ソフトの版、各署名と nonce 結合の結果、測定時に使ったリストの正確なハッシュを固定する。端末情報は必要最小限にする。

次に、単一鍵、候補集合、未解決のいずれかを記し、権限ある審査者、利益相反、外部証拠、理由、確信度、期限を示す。ここで検証と判断を分離する。

処分欄には隔離、重み変更、削除、復帰を置き、旧リストと新リストのハッシュ、連番、署名者、発効時刻を結ぶ。期限措置は明示的に更新されない限り失効する。

配布欄は公開先と透明性アーカイブを示すが、公開を採用と呼ばない。クライアント群はプライバシーを保った集計で、インストール済みハッシュ、遅延、拒否理由を報告できる。独自リストの運用者は異なる結論を採用し、そのリスクを引き受ける。

訂正欄では、鍵侵害、時刻源の修復、鍵ローテーション、帰責への異議を扱う。誤った判断は取り消せるが、元の証拠は削除しない。復帰も署名された新しい遷移として残す。

信頼が変わる場所は、最終的にはクライアントである。公表だけではキャッシュも固定設定も変わらない。削除後には、独立した稼働サーバーが三つ以上残るかも検証しなければならない。

Roughtime は特定の矛盾を否認しにくくする。良いガバナンスは、その強みを保ちながら、証拠、裁定、公開、採用を一語の「失効」に押し込めない。

情報源