要約

  • RFC 5379 の表は、priv-value ごとに対象となるSIPヘッダーとSDP項目を区別した。Privacyヘッダーは限定された依頼であり、メッセージ全体の書換権ではない。
  • 非対象の Identity が削除される場合でも、その根拠はPrivacy値そのものではなく、保護対象の変更で署名が無効になったという別の因果関係になり得る。
  • 監査には、依頼、対象判定、独立した処理根拠、変更、派生証拠、相関状態、プロトコル結果、観測者ごとの漏えい確認が必要である。

匿名化の直後に古くなる証拠

あるSIPメッセージに、発信者を示すFrom、対話を示すCall-ID、到達先を示すContact、そしてそれらを対象にしたIdentityがあるとする。プライバシーサービスは Privacy:user を受け、対象となる情報を正しく匿名化した。処理自体には誤りがない。

しかし、その瞬間に別の問題が生まれる。Identityが変更前の値を保護していたなら、変更後のメッセージに付いたままのIdentityは、もはや届いた内容を証明していない。サービスは、依頼どおりに動いたために、依頼の直接対象ではない証拠を無効にしたのである。

RFC 5379 はこのような依存関係を整理した。2010年2月にIndependent StreamのInformational文書として公表され、RFC 3323、RFC 3325、RFC 4244で定義された仕組みの実務的な扱いを説明した。既存の仕組みを変更せず、新しい規範行動も追加しないと明記している。

したがって、この文書を「より強いプライバシー命令」と読むのは誤りである。役割は、既存命令の対象と、その実行によって生じる二次的な義務を混同しないようにすることだった。

一つのヘッダーに複数の対象領域

user、header、session は強度の段階ではない。user は利用者が挿入した情報、header はネットワークが付加した信令情報、session はセッション記述に含まれる情報を扱う。id はRFC 3325のP-Asserted-Identity、history はHistory-Infoを対象とする。none と critical はさらに別の制御を担う。

RFC 5379 のマトリクスは、Call-ID、Call-Info、Contact、From、History-Info、In-Reply-To、Organization、P-Asserted-Identity、Record-Routeなどを行に置き、値ごとの操作を示した。削除、追加しない、匿名化、条件付き処理、処理なしが区別され、要求と応答の向きも区別された。

SDPでは Privacy:session の対象として c、m、o、i、u、e、p 行が示された。「セッション」という一般語から、通話に関係する全ヘッダーを対象に拡張してよいわけではない。

実装が保持すべきなのは単純な有効フラグではない。どの値が、どの方向の、どのフィールドに、どの操作を、どの仕様根拠で要求したかである。型を失った瞬間、監査記録は行動量を示しても正当性を示せなくなる。

非対象リストは権限の境界だった

Identity/Identity-Info、Path、Replaces、Route、Service-Route、Target-Dialogは、列挙された値の対象外と明記された。Privacyヘッダーの値だけを理由に匿名化または変更すべきではない。

これらが安全な情報だという意味ではない。Pathは訪問先ドメインを示し得る。Routeはプロキシ群を示す。Identity-Infoは証明書の参照を含む。ReplacesやTarget-Dialogは対話を結びつける。

それでも、センシティブであることは変更権限ではない。Pathは登録された端末へ呼を届けるために使われる。代替経路なしに隠せば、利用者を到達不能にする。Routeは次に通る経路そのものであり、見た目を匿名にするための書換えが転送意味を壊す。

プライバシーサービスは「この値は個人を推測させるか」だけで判断してはならない。「この依頼はこのフィールドに及ぶか」「別の規則があるか」「変更後も何が機能しなければならないか」を同時に答える必要がある。

Identityを消す権限はどこから来たのか

RFC 5379 が参照した当時のRFC 4474では、IdentityがFrom、To、Call-ID、CSeq、Date、Contact、本文を保護していた。プライバシーサービスが正当な対象を変更すると、その署名は無効になる。

ここでIdentityはPrivacy値の直接対象ではない。それでも無効な証拠を残すべきではないため、削除が必要になる場合がある。この処理の根拠は「利用者がIdentityを隠せと依頼した」ではなく、「保護対象を変更したため、既存の証拠が真でなくなった」である。

記録も二段に分けるべきだ。第一に、Privacy値と対象表に基づいて保護対象を変更した。第二に、その結果として完全性証拠が無効になり、別の整合性規則で撤去した。二段を一行にまとめると、依存関係の処理が利用者の包括的な委任に見えてしまう。

RFC 4474 は後にRFC 8224に置き換えられた。古い署名方式を現在の構成にそのまま適用してはならない。一方、派生証拠の原理は変わらない。入力を変更したシステムは、その入力に依存する証拠を再検証し、無効なら撤回または再生成しなければならない。

Call-IDの変更は未来のメッセージを拘束する

Call-IDをC1からC2へ変更すると、サービスは単に一つの文字列を置換したのではない。同一対話を二つの名前で扱う相関状態を作った。後のIn-Reply-To、Replaces、replaces パラメータ、Target-Dialogが、そのどちらかを参照する。

後続メッセージにPrivacyヘッダーがないこともある。別の当事者が送ることもある。それでも同じサービスが値を戻す、または翻訳する必要がある。根拠は新しいプライバシー依頼ではなく、最初の変更が作った整合性義務である。

RFC 5379 の転送例では、この義務が見える。最初のINVITEでC1をC2に変えた後、REFERから生成されたINVITEがReplacesにC1またはC2を入れる。相関表を持つサービスを通らなければ、置換対象の対話は見つからず、処理が失敗する。

この失敗は構文検証では見つけにくい。各メッセージは正しい形式でも、複数メッセージ間の意味が切れている。Privacy処理の成功を最初の送信時点で確定してはいけない理由である。

変更前には、状態保持期間、冗長ノード間の複製、再起動後の回復、非対称経路、長時間対話、遅延した転送を設計しなければならない。Call-IDを変える組織は、相関が不要になる時点まで責任を持つ。

ローカルポリシーは利用者の声ではない

RFC 5379 は実装やネットワークポリシーによる差を認め、対象外でも別の理由で扱うべき情報があることを認めた。この柔軟性は必要だが、出所を消してはならない。

トポロジー隠蔽、信頼境界でのP-Asserted-Identity処理、無効な証拠の削除、Record-Route変更後のRoute復元は、それぞれ異なる規則である。すべてを「プライバシー適用済み」と記録すると、誰の判断が通信を変えたのか分からない。

ローカルポリシーには固有の名称、所有者、版、適用条件、変更結果を付けるべきである。相関修復は原因となった過去の変換を参照する。利用者のPrivacy値は、利用者が依頼した範囲を示す証拠として残し、運用者の裁量を正当化する看板にしてはならない。

記録の役割を守ることが権限の肥大化を防ぐ。ヘッダーは依頼を記録し、仕様表は範囲を記録し、実行ログは操作を記録し、呼トレースは結果を記録する。一つの記録が他の現実を作ったことにはならない。

観測者を指定しなければプライバシーは測れない

対象表どおりに処理しても、期待した秘密が守られたとは限らない。着信者に対して匿名でも、プライバシーサービスは本人を知る。SDPのアドレスが位置やネットワークを示すことがある。課金、障害解析、証明書参照が別の相関を残すこともある。

結果の主張には、情報と観測者が必要である。何を、誰から、どの期間、どのメッセージとメディアについて隠したのか。内部で相関可能な主体は誰か。その状態はいつ消えるのか。

試験は設定画面ではなく経路で行う。登録、初回INVITE、応答、対話内要求、転送、折返し、終了を実行し、各サービスの前後を取得する。選んだ観測者への非開示と、利用者が必要とする機能の継続を同時に確認する。

呼がつながっただけでは秘密を証明せず、フィールドが消えただけでは機能を証明しない。RFC 5379 の表は一貫した実装を助けるが、配備全体に対する万能な結果証明ではない。

文書の地位も証拠の一部である

RFC 5379 はInformationalであり、Independent Streamの文書である。規範語は既存RFCから導かれ、新しい規範行動は定めないと明記した。この限定は実装時にも保存すべきである。

また、参照先は時間とともに変わる。RFC 4244はRFC 7044に、RFC 4474はRFC 8224に置き換えられた。歴史的な表は設計上の境界を説明するが、現在の要件は後継文書で確認しなければならない。

IANAのSIP Parametersレジストリも別の証拠である。名称と参照仕様の登録を示すが、製品の対応、正しい処理、状態維持、実際の非開示を示さない。

監査可能な記録には次が要る。

  • 元のメッセージ、方向、依頼主体、想定観測者
  • Privacyの各値と適用仕様
  • フィールドごとの対象表判定
  • 独立したローカル規則またはプロトコル上の理由
  • 変更前後と無効になった派生証拠
  • 識別子対応表、保持期間、保有ノード
  • 対応表を使った後続メッセージ
  • 経路、対話、転送、メディアの結果
  • 観測者ごとの開示試験

この連鎖により、依頼の存在を包括権限に、変更の存在を成功に、呼の成功を秘密の証明にすり替えることを防げる。