要約

  • RFC 9888 は、電話経路が STIR の PASSporT を SIP 内で運べないとき、着信側事業者の Call Placement Service に署名済みトークンを預ける仕組みを定める。
  • トークンは未署名の呼制御情報より先にも後にも届くため、取得範囲、鮮度、署名権限、実通話との対応は別々に確認しなければならない。

暗号側の検査は終わっていた。PASSporT の署名は通り、保護された接続から指定の保管先へ届き、短い有効時間の内側にある。ところが、その証拠が説明するはずの通話はまだ見えていなかった。

STIR は通常、SIP リクエストに PASSporT を載せる。境界装置が情報を落とす場合、PSTN を通る場合、旧式網が SIP を端から端まで保てない場合には、その前提が崩れる。RFC 9888 の CPS はトークンだけを別経路で運ぶ。発信側認証サービスが着信先用の保管先へ投入し、着信側検証サービスが呼到着後に取得するか、購読で受け取る。

CPS は着信事業者自身、委託先、複数社が共有する分散サービスのいずれでもよい。単一の世界サーバーを前提にしない点は強みである。同時に、呼と証拠は別の障害、別の時計、別の保管者を持つ二つのイベントになる。

広告が証明するのは保管先の範囲

CPS 広告は TNAuthList の値を HTTPS の保管先へ対応付ける。STIR 証明書で署名すれば、広告した電話番号資源が署名者の権限内か比較できる。発見方法は相対契約、共同リスト、データベース、DNS、証明書への URI 結合などを選べる。

これは限定された権限証明である。広告者がその範囲の提出先を示せることと、今まさに通話が発生したことは別である。共有 CPS では、どの検証サービスがどの宛先の PASSporT を受け取れるかを判定しなければならない。有効な STIR 資格を持つことは、進行中の全通話を読む権利ではない。

安全な配送は照合を代行しない

発信側サービスは STIR 資格を使う相互 TLS で CPS に接続することが推奨される。TLS は配送を守り、相互認証は接続相手を識別し、PASSporT 署名は主張を署名者へ結ぶ。CPS はさらに、受け入れる発信元と量をローカル方針で決める。

どの成功も、別経路の呼を自動選択しない。トークンの保存は取得に必要な期間だけで、鮮度上限は六十秒である。短い窓は古い再利用を抑えるが、窓内の出来事を一意にはしない。複数呼、再試行、転送、ゲートウェイ変換、投入後の経路失敗が重なり得る。

pull 方式では、帯域内トークンを持たない呼を受けてから CPS を照会する。push 方式では呼より前にも後にもトークンが届く。RFC は表示上の検証マークを待たせる必要を認め、厳密なタイミングと置換攻撃への対応を将来課題とする。したがって「待機中」は正式な状態であり、楽観的な「検証済み」で埋めてはならない。

再現できる照合記録には、両経路で見た発着番号、トークン指紋、署名者と範囲、発行・投入・取得・呼到着時刻、CPS と取得主体、ゲートウェイ変換、検証結果、競合候補、選択規則が要る。候補が二つ残れば、結論は曖昧である。

委託は観測者を増やす

RFC 9888 は RFC 8816 の公開型とは異なり、着信事業者またはその代理が CPS を運用し、呼設定で事業者が得るメタデータを扱うと想定する。第三者委託では、新しい組織が通話関係を知る。共同 CPS は観測を集中させ、PASSporT 拡張は通常の SIP より多くの情報を含み得る。

項目最小化、保存期限、目的制限、アクセス監査は依然として必要である。帯域外経路は証拠を旧式網の向こうへ届ける。証拠の意味を拡張する免許ではない。

情報源