要約

  • 有効な応答が証明するのは、特定の要求を受けた鍵が有限の時刻主張に署名したことだ。時計の正しさそのものではない。
  • 連鎖報告は応答順序と「少なくとも一台が誤った」ことを示せる。どの一台か、報告を受理するか、鍵を失効させるかは別問題である。

三台の署名はすべて検証できる。それでも、受信順序に時間区間を重ねると同時には成立しない。暗号学は矛盾を消せない形で残した。しかし、被告席にはまだ誰も座っていない。

これが Roughtime 第19版の重要な境界である。NTP Working Groupの現行Internet-Draftで、Experimentalを意図しRFC Editor工程にあるが、RFCではない。第18版との差は主に編集上のため、新しい帰属規則が追加されたとは述べない。

クライアントのnonceはMerkle木へ取り込まれ、応答にはMIDP、RADI、木の根が入る。短期Ed25519鍵が応答を署名し、長期鍵がMINTとMAXTを持つ委任を署名する。委任、応答、要求包含、期間を検証して初めて有効になる。

だが仕様は、有効性が時刻値の正しさを証明しないと明記する。証明されるのは、サーバーが(MIDP-RADI, MIDP+RADI)内でその主張を署名したという保証だ。署名は発言者と改ざんの有無を固定する。物理時計の真実までは作らない。

複数サーバーモードでは、異なる運営者による少なくとも三台の稼働サーバーが必要だ。同じ順序で二巡し、後続nonceを直前の完全な応答と新しい乱数から作る。これにより応答の因果順序が証拠になる。

ここで重要なのは、単なる三つの時刻サンプルではないことだ。二巡目の要求は一巡目の応答を材料としているため、後から都合のよい順番へ並べ替える余地が狭まる。クライアントは「この応答を見た後で、次の要求を作った」という関係を第三者に渡せる。時間の絶対値に合意できなくても、観測の前後関係については検証可能な記録が残る。

署名が有効なのに区間が因果順序に反すればmalfeasanceである。報告は鍵、乱数、要求、応答を受信順に保存し、少なくとも一台が誤った時刻を送ったと示せる。ただし、二台が同じ誤った上流源を共有すれば、正直な少数派が外れ値に見える。多数決は独立性の証明ではない。

サーバーリストの採用・除外、報告受理、責任帰属、異議申立て、鍵失効は仕様外である。人間の観察者による場は一案にすぎない。それでも仕様は、リスト維持と違反裁定を安全性に不可欠とする。

この外部性は欠陥の隠蔽ではなく、権限境界の開示である。プロトコルは証拠を運べる形にするが、誰がサーバーを信頼集合へ入れ、どの証拠基準で排除し、誤認にどう異議を申し立てるかを決めない。その空白を無視して自動失効だけを実装すれば、未定義の統治判断をコードの既定値へ押し込むことになる。

したがって、署名区間、暗号検証、矛盾ペア、リスト版、提出、審査、帰属、失効、配布、修復を別状態にする。MAXT後の短期秘密鍵漏えいも、旧期間へ偽時刻を遡及署名できるため、単なるローテーションで終わらない。

Roughtimeは証明書検証の起動やNTP/PTP観測の境界に使える。法的タイムスタンプ、取引順序、端末完全性、現実作業の完了証明ではない。