要約

  • RVP草案の第03版は、五層の検証を必ず順に実施して信頼度を積み上げる従来案を撤回し、一件の問いにひも付く証拠を扱う案へ改めた。
  • 旧版のチャレンジだけを署名したトークンに、後から操作と対象を書き足して新版の承認証拠にしてはならない。

管理端末への入室を認める前に、スマートフォンが一度応答した。そこで確認されたのは端末がチャレンジに応じたことか、入室する人物がその操作を認識したことか。結果を単一の「信頼度」と呼んでしまえば、この差が決裁の場で消える。9月29日付のRVP第03版は、その曖昧さを検証プロトコルの境界として扱う。

第02版の中心には、操作のたびに検証するという構想と、行動・身体・端末など五層を順にたどる検証カスケードがあった。各段階の信頼度を合算して閾値と比べる仕組みである。ただし、実際に許可するかどうかは当時からローカル方針に委ねられていた。第03版の新しさは、証拠と執行を初めて分けたことではない。共通の点数を前提とする設計を外し、ログインセッションの継続性と新たな在席証拠を別々に扱い、追加確認の要否を利用側の方針に戻したことだ。

新しい証拠要件は、識別子だけでなく変更不能な版と本文のダイジェストで固定する。要求には操作、対象、本人、別に行動する代理人、利用者、目的、ウィンドウ、チャレンジ、有効期限が入る。第5節の「問いのコミットメント」はこれらを一緒に覆い、検証者は自分の要求記録から値を計算し直す。応答を運ぶ方式が複数あっても、答える問いは同じでなければならない。単なる通信上のチャレンジは、画面に示した操作名まで証明しない。

移行付録は過去の記録を消せとは言わない。旧形式のトークンは歴史的な証拠として残せる。一方、新形式が操作と対象への結合を要するなら、旧トークンは合格しない。保存先の現在の情報を使って欠けた欄を埋め、当時の署名者が承認したと見なすことも禁じる。完全な問いを必要とする検証者が、チャレンジだけの旧応答を黙って受け入れるのはダウングレードとなる。

さらに「一致した」と「使った」は別の出来事だ。matchは凍結された要件に証拠が合ったという通路の結果にすぎない。利用側が特定の対象状態にその証拠を適用したとき、別のbindを記録する。再利用できる相手や目的は事前に要件へ明記し、消費は競合して二重に進まないよう扱う。最後の入場可否は対象システムの権限方針が決める。

Daniel Kadeの提案は、移行台帳に旧・新形式の署名対象、要件の版とダイジェスト、操作と対象、実際の利用記録、最後の権限判断者を分けて記すことだ。草案が定めた帳票ではない。旧スコアが高かったというだけで、新しい対象への承認まで存在したことにしないための実務上の線引きである。

Datatracker上では第03版は活発な個人Internet-Draftで、RFCのstreamは設定されていない。媒体型の登録も申請であって完了ではない。導入例や攻撃発生を示す一次資料は確認できない。ニュースとして確かなのは、提案が「一般化できる点数」から「特定の問いに限る答え」へ大きく改稿されたことだ。

出典