要約

  • RFC 9796 の verified=true は、その Call-Info フィールドを挿入した主体が、そこに表された情報を検証したという表明である。受信端末は、その主体との認証済み信頼関係を別途必要とする。
  • 表明の範囲は当該フィールドに限られる。発信者情報全体、会話の目的、通話の正当性、最終結果を一括して保証するものではない。
  • integrity のハッシュ一致は取得したバイト列を確かめる。出所、鮮度、可用性、表示、利用者の認識、正当性は別の受領記録を要する。

最初に見るべきなのは緑の印ではなく、その印の直前にある動詞だ。「検証した」「受け入れた」「挿入した」「受信した」「表示した」。どれも同じ出来事ではない。RFC 9796 は、その差を保ったまま Rich Call Data を SIP の端末へ届ける仕様である。

仕様は Call-Info に call-reason、verified、integrity、purpose=jcard を定義する。verified=true が意味するのは、当該フィールドを含めた当事者が、そこに表された情報を正常に検証したことだ。受信側がその表明を信頼できるかは、要求を受け取った相手との信頼関係に依存する。

つまり、表示は無主語ではない。「ネットワークが検証した」では粗すぎる。どの事業者が、どのフィールドを、何に照らして検証し、どの端末へ渡したかが必要になる。

検証を代行すると、新しい保管責任が生まれる

RFC 9795 は Rich Call Data のクレームや参照資源のダイジェストを PASSporT で保護する。RFC 8225 が PASSporT を定義し、その構造は RFC 7519 の JWT に連なる。RFC 8224 は STIR の電話番号アイデンティティを SIP に配置する。

終端事業者は、署名、証明書経路、クレーム、参照ダイジェストを検証できても、加入者端末は同じ処理を実装できないことがある。RFC 9796 は、事業者が受け入れた結果を Call-Info に変換し、認証された信頼できる UNI 上の端末へ渡す例を示す。

この変換は合理的だが、証拠を複製しているわけではない。端末が直接持つ受領記録は「PASSporT を検証した」ではなく、「信頼する相手が、このフィールドを検証済みとして挿入した」である。

運用記録は少なくとも、RCD の提示、PASSporT の到着、署名と証明書の成功、クレーム照合、ローカル方針の受容、Call-Info への変換、UNI 相手の認証、外部資源の取得、ハッシュ一致、描画方針、実際の表示、利用者の行動、後続する正当性確認、サービス結果を分離すべきだ。

一つ前の成功は一つ後の成功を証明しない。これが緑の印を有用なまま保つ条件である。

jCard は単一の真実ではなく、整合を求められた集合である

RFC 3261 の SIP は Call-Info を持つが、通常の From 表示名は存在するだけで信頼済みにはならない。RFC 9796 は、名前、画像、ロゴ、理由といった表示要素のうち、何が限定的に検証されたかを表現できるようにする。

jCard は RFC 7095 に基づき、JSON の基礎は RFC 8259 にある。RCD プロファイルは一つの entity オブジェクトを用い、名前、写真、ロゴ、From、P-Asserted-Identity、アイコンなど、重なる表現に整合を求める。整合が必要なのは、カードが複数の表明を組み合わせるからだ。

データは data: URI に埋め込める。あるいは RFC 2392 の cid: で MIME 本文を参照できる。検証済みドメインに結び付いた HTTPS のように、情報源の完全性を検証できる外部取得も可能だ。埋め込み、メッセージ内参照、外部取得では、管理主体と障害点が異なる。

空の data: URI と purpose=jcard で、表示名の検証結果だけを簡潔に伝える形もある。データ量が小さいから表明者が不要になるわけではない。むしろ端末の記録が短いほど、挿入主体を別に保存する必要がある。

ハッシュが守るのはバイト列の同一性である

integrity は URI 参照資源にアルゴリズム名とダイジェストを結び付ける。実装は SHA-256、SHA-384、SHA-512 を扱わなければならない。一致すれば、取得した資源が宣言されたバイト列と同じだと確認できる。

そこから、作成者、現在性、呼出中の可用性、表示許可、画面への描画、利用者の注目、通話目的の正当性までは導けない。ロゴが正しいバイト列でも、そのロゴを見せた会話が正しいとは限らない。

call-reason は任意で短く、切り詰められることがあり、表示も保証されない。発信者がどう設定するかは仕様外である。「支払い確認」という文字列は判断材料になり得るが、支払いの存在を証明しない。

RFC 7852 の SIP Resource-Priority 名前空間も、プロトコル上の印が周囲の認可や方針を不要にしないことを示す。規定されたラベルは規定された範囲で読むべきであり、権威らしい語感で拡張してはいけない。

中継者が内容を変えれば、検証対象も変わる

RFC 9796 は RCD 関連の Call-Info を一つの整合した版として提示するよう求める。経路上の追加参加者は、それを変更したり、競合する RCD フィールドを加えたりしてはならない。STIR などの保護がなければ、信頼できない相互接続網での改変を検知できるとは限らない。

これは表示品質の問題ではなく、証拠の対象を保つ規則だ。検証後に写真や名前を書き換えれば、画面上の対象と検証対象が離れる。変換が必要なら、入力、検証方針、変換主体、出力フィールド、宛先を記録しなければならない。

標準の状態は公開資料で検証できる。テキスト版、XML 版、RFC Editor 情報、正誤表、IETF 履歴、IANA SIP パラメータ表で規範と登録を追える。しかし特定の通信事業者、ゲートウェイ、端末の実装実績は証明しない。

動くコードという視点は、比較を実行した部品と観測結果を求める。最小の初期仕様は相互運用の意味を共有させるが、ローカルな判断を万能な保証へ膨らませない。そして現実の層を分ければ、規格上の語、暗号検証、端末表示、人の信念、結果が同じものではないと説明できる。

RFC 9796 は、複雑な検証設備と小さな端末をつなぐ。その橋を信頼できるものにするのは、橋を無かったことにせず、誰が判断を運んだかを残すことだ。

出典