要約

  • draft-nikolaichuk-scitt-continuity-receipts-01 は、ステートフルな資産の復旧に関する署名済み Statement を SCITT の透明性サービスへ登録し、RFC 9942 Receipt を得る形式を提案する。
  • SCRAPI は HTTP 202 と entry identifier を先に返せるが、それは Receipt ではない。資産を先に渡す場合、Receipt が解決するまで復旧は unwitnessed のままである。
  • Receipt が証明するのは Issuer の主張が所定のログ位置に登録されたことだけで、復旧の発生、アテステーションの良好性、バイト一致、意味や挙動の同等性までは証明しない。

「動いた」をどこまで広げるのか

復旧試験では、起動は強い誘惑を持つ。モデルがロードできた。データベースが接続を受けた。アプリケーションがヘルスエンドポイントに応答した。復旧担当者にとって、それは重要な前進である。

しかし、起動は元の状態への復帰と同義ではない。失われたレコードを抱えたデータベースも起動する。異なる重みや周辺状態を持つモデルもロードできる。業務上の不変条件を破ったアプリケーションも、浅いプローブには応答し得る。

2026 年 9 月 29 日付の Continuity Receipts revision 01 は、この区別を透明性の証拠設計へ持ち込む。Informational を目指す個人 Internet-Draft であり、SCITT WG の採用文書でも RFC でもない。提案するのは、復旧を記述する Signed Statement と、その登録を証明する Receipt である。復旧そのものを実行する規格ではない。

復旧後に残る七つの段階

最初に復旧環境の Attester が Evidence を作る。Verifier がそれを評価し、Attestation Results を出す。鍵解放の仕組みが sealed key material の引き渡しを決める。環境は sealed material を復号し、資産を再構成し、実際に生成された平文の recovered-digest を計算する。

Recovery Authority は観察したと主張する内容を claims にし、資産の安定識別子を subject として RFC 9943 Signed Statement に署名する。Transparency Service は Registration Policy を適用し、ログへ追加し、RFC 9942 の Receipt を返す。Relying Party は最後に、Receipt、Issuer、claims、アテステーション参照と自らの利用条件を検証する。

ここで一つの主体が全段階を保証するわけではない。鍵を解放した者は生成物を見ていないかもしれない。Recovery Authority は観察者だが、独立監査人とは限らない。Transparency Service は Statement を見届けるが、復旧を再実行しない。利用者は、受け取ったものを使う効果に対して最後まで責任を持つ。

Lu Heng の現実層の考え方を当てはめれば、各記録は自分が観察した層だけで権威を持つ。上位のラベルが下位の物理事実を代行してはならない。

Receipt は何を見届けたのか

草案の定義は限定的である。Continuity Receipt は、特定の Issuer が署名した特定の Recovery Statement が、特定の Transparency Service の append-only log の特定位置へ登録され、サービスがその事実の証明に署名したことを示す。

復旧イベントが本当に起きたとは示さない。復旧バイトが元資産と一致するとも示さない。参照した Attestation Results が検証済み、あるいは favourable だったとも示さない。環境が記述通りの状態にあったとも、Registration Policy がそれらを検査したとも示さない。

これは Receipt の欠陥ではない。発言者と時系列を固定し、主張を後から静かに消すことを難しくするのが役割だ。Witness が Auditor を装わないこと自体が安全性になる。

従って、表示も分ける必要がある。Issuer が asserted した内容、独立に established した事実、現時点で unverifiable な点を、一つの「検証済み」表示へ潰してはならない。

202 は登録完了ではない

現行の SCRAPI ドラフトでは、Signed Statement を非同期に受け付け、HTTP 202 と entry identifier を返し、後から entry resource で Receipt を解決できる。この identifier は照合やポーリングには役立つが、ログへの inclusion proof ではない。

revision 01 は、Issuer に明示的な選択を求める。Receipt まで待って資産を引き渡すか、待たずに進み、Receipt が得られるまで復旧を unwitnessed と記録するかである。202 を Receipt と同一視する選択肢はない。

災害時には待てない資産もある。透明性サービスの障害によって重要業務を停止し続けるより、限定した利用者へ先に渡す方が合理的な場合はある。その場合に必要なのは、例外権限、期限、対象、代替統制、照合期限である。「復旧成功」の一語で証拠債務を消してはならない。

実測値を期待値から作らない

recovered-digest は、復旧イベント終了時に存在した平文バイトから計算する。封印時のマニフェストにある期待 digest をコピーしてはいけない。期待値は比較対象であって、観測結果ではない。

環境 measurement も native algorithm と native length のまま保持する。草案が取り上げる隣接実装は、AWS Nitro の PCR0 と AMD SEV-SNP の launch MEASUREMENT という 48 octet の SHA-384 値を 32 octet へ切り詰める。見た目がハッシュでも、AWS の policy engine が比較する完全な値とは一致しない。

Running-Code Primacy は、設計文書よりコード名を信じる態度ではない。実際に走った環境が何を生成し、どの表現でポリシーが比較したかを保存する規律である。

アテステーションの参照は将来の依存になる

Attestation Results には referenced、embedded、registered の形がある。参照だけなら Statement は小さくなるが、後日の検証には同じバイトを取得できなければならない。埋め込みなら自己完結性は高まる一方、ハードウェアや地域、ワークロードの情報を公開しやすい。別登録なら独自の Receipt を得るが、証拠オブジェクトとサービス依存が増える。

freshness は nonce、epoch ID、timestamp、none で表す。none は Evidence が challenge に結び付かず、リプレイ可能だという開示である。形式上の失敗ではないが、「現在の状態を証明した」と読むことはできない。

署名が有効な Attestation Results でも、評価結果は不利かもしれない。存在、真正性、新鮮さ、評価の良好性は別々に読む必要がある。

Operational は最も弱い同等性

equivalence がなければ none と扱う。byte-identical は、実測した復旧 digest と封印時の平文 digest が等しく、Issuer 自身が比較した場合だけ使える。operational は、ロード、起動、health probe など定義済み試験を通ったという主張で、試験定義と結果への evidence reference を必要とする。

この operational claim は弱い。草案は semantic や behavioral equivalence の値をあえて定義しない。実装が意味の同一性を検査していないのに、その code point だけを用意すれば、smoke test が過大な結論へ変換されるからだ。

Receipt が正しくても equivalence は none のままでよい。逆にバイト一致を確認しても、Receipt がまだ到着していないことはある。二つの軸を同じ緑ランプにしないことが核心である。

連続性チェーンとログ順序は競合し得る

同一 subject の Recovery Statements は prev-event でつながり、Issuer が主張する系譜を作る。append-only log が示すのは全登録の順序である。前者は「この復旧の前はどれと考えたか」、後者は「どちらが先に登録されたか」を答える。

間に gap があれば、Verifier は修復せず報告する。Issuer が中間イベントを知らなかったか、認めなかった可能性がある。entry identifier や leaf index は探索の手掛かりで、暗号学的なつながりは前 Statement の digest にある。

複数の Transparency Services をまたぐ場合、それぞれの順序保証は合成されない。長期検証では、新旧の Merkle Tree Head を結ぶ consistency Receipt も必要になる。孤立した root への inclusion は、そのログが昨日作り直されていないことを示さない。

プライバシーは検証可能性と交換される

claims を attached payload にすれば、Transparency Service は内容に基づく Registration Policy を適用できる。一方で stable subject、復旧時刻、地域、事業者関係、hardware identifier が永続ログへ露出し得る。detached payload は露出を減らすが、サービスは受け取らない claims を検査できず、Relying Party は別経路で内容を入手しなければならない。

pseudonymous subject は公開相関を弱めるが、組織をまたぐチェーン結合を壊し、Issuer の秘密鍵を長期相関の要にし、ローテーション時にチェーンを分断する。将来誰が連続性を検証できるかは、最初の登録前に決まる。

Reference implementation という名前の限界

草案は、隣接する reference implementation が本文を実装していないと明記する。RFC 9942 COSE Receipts はなく、別のログ連結方式を使い、アテステーション検証は未完で、nonce binding もない。復元部分は byte-level の決定的な order-3 Markov chain であり、意味の復元を示さない。

この開示は健全である。仕様の提案、コードの現状、配備の実績を三つの状態として保てるからだ。repository が存在するだけで running system の証拠にはならない。

情報源と限界

これらは作業中の提案、既存の Receipt／アテステーション体系、隣接コードが自己申告する差分を示す。実配備、事故、攻撃、復旧成功、相互運用、採用、semantic fidelity は立証しない。以下の release dossier は Daniel Kade の運用分析であり、revision 01 の既存要件ではない。