要約

  • RFC 5333 は ical-access を CalDAV のカレンダーまたは空き時間リソース、ical-sched を mailto: と iMIP による日程調整の発見に割り当てる。どちらも公開 DNS から得られる URI であり、権限や結果そのものではない。
  • 読みやすい URI は、認証が本文を守っていても氏名や雇用関係を示し得る。匿名 URI は直接的な露出を減らすが、鮮度、相関可能性、認可、到達性までは証明しない。

漏れたのは予定表の中身だけではない

カレンダーのプライバシーを考えるとき、多くの組織はイベント名、参加者、場所、メモを守る。CalDAV サーバーに認証を置き、匿名リクエストを拒めば、本文の保護としては正しい。

しかし、発見用 URI の path に人名と勤務先がそのまま並ぶ形なら、別の情報が先に見える。電話番号から導いた DNS 名を問い合わせた者は、その番号と人名、さらに組織との関係を推測できる。サーバーに一度もログインしなくても成立する観測である。

RFC 5333 は ENUM データを公開情報として扱う前提を置き、URI に氏名や雇用主が含まれる場合の懸念を挙げる。したがって、アクセス制御の監査だけで「漏えいなし」と結論づけてはいけない。発見層に何を置いたかを別に調べる必要がある。

匿名 URI は対策だが、判定書ではない

人が読めないランダムなパスを使えば、DNS 応答を一件見ただけで氏名を読むことは難しくなる。これは実用的な最小化であり、採用する価値がある。

それでも、長期間変わらないトークンは相関キーになる。同じ URI への反復問い合わせ、対象ドメイン、HTTP リダイレクト、TLS 名、サービスログ、後続のログインが結び付けば、意味は再構成される。URI が匿名に見えることは、観測者にとって匿名であることと同じではない。

さらに、匿名化は古さを直さない。電話番号が再割り当てされた後も旧 URI が残る、退職後も勤務先ドメインへ向く、サービス移行後も古い入口を返す、といった状態は起こり得る。必要なのは生成規則だけでなく、期限、ローテーション、失効と所有権変更時の手順である。

ical-access は権限ではなく用途を表す

ical-access:http と ical-access:https は、CalDAV によるカレンダーまたは free/busy へのアクセス先を示す。ここでいう access はプロトコル上の用途であり、発見者全員への許可ではない。

対象サーバーは、利用者を認証し、リソースとメソッドごとに認可できる。同じ主体でも、空き時間は読めるが件名は読めない、読み取りはできるが変更はできない、といった違いがある。URI は ACL を運ばない。

運用記録には、URI 解決、リダイレクト、TLS サーバー同一性、クライアント主体、対象リソース、メソッド、認可判断、応答、状態変更を分けて残すべきだ。「接続済み」という一語では、どの境界を越えたか分からない。

ical-sched は同意を記録しない

ical-sched:mailto は、iTIP の日程調整オブジェクトを Internet メールで運ぶ iMIP の宛先を発見する。会議依頼を送る経路として使えるが、CalDAV collection ではない。

メールサーバーがメッセージを受理しても、参加者が受理したわけではない。配送、迷惑メール判定、カレンダークライアントの解析、既存イベントとの照合、画面表示、本人の応答は別々の段階である。参加者は辞退も保留も無応答も選べる。

自動エージェントが公開アドレスを「本人の同意」と解釈すれば、ルーティング情報が意思決定権に化ける。発見は送信を試みる理由にはなっても、出席確定を記録する理由にはならない。

DNSSEC が保証する場所を限定する

DNS 応答は改ざんや偽装の対象になる。検証条件が整えば、DNSSEC は RRset が信頼連鎖に沿って認証されたかを判断する助けになる。この結果は発見経路にとって重要である。

ただし、その署名は CalDAV のログイン資格情報ではない。HTTP メソッドを許可せず、メールボックスの現所有者を確認せず、会議依頼の処理や応答も証明しない。安全に検証されたレコードが、停止中または期限切れのサービスを指すこともある。

システムは DNSSEC 状態を RRset の属性として保持する必要がある。resolver、検証時刻、secure・insecure・bogus の区別、問い合わせ名を残す。その後の TLS、認証、認可は新しい証拠として記録し、secure を包括的な「信頼済み」に変換しない。

電話番号は恒久的な人物 ID ではない

ENUM は E.164 番号から始まる。だが番号は再割り当てされ、役職や共有窓口に使われ、管理主体が変わり得る。ある時点の DNS mapping は、その時点で公開された関連を示すだけである。

URI に氏名が入っていても、現在の番号利用者と同一人物であると自動的には言えない。URI がメールアドレスでも、そのメールボックスを誰が操作するかは別の証拠を要する。カレンダーサービスが認証したアカウントも、電話番号から推測した人物と同一とは限らない。

この境界を守るには、観測時刻と由来を持つ関連として保存する。人物同一性や代理権は、該当する identity system から取得する。番号から人物、人物から同意へと二段階の推論を一気に行わない。

NAPTR の順序は稼働率ではない

order と preference は、複数 NAPTR レコードを処理する選択規則である。優先された URI が現在応答する、低遅延である、認可を通す、メールを届ける、という測定値ではない。

この値を health score として表示すると、正しい選択後の障害を DNS の誤りに見せる。また、access が失敗したため sched に切り替え、それを同じ成功として数える危険もある。読み取りと招待送信は異なる操作であり、一方は他方のフォールバックではない。

選択の記録には RRset、TTL 文脈、order、preference、flags、service、書換規則、結果 URI を含める。稼働状態は対象プロトコルの観測を別に結合する。そうすれば、設定と実行を混同せずに原因を追える。

IANA 登録は稼働サービス一覧ではない

IANA の ENUM Services レジストリは共有語彙を管理する。実装はそこから token の意味と関連 scheme を理解できる。標準化された意味は相互運用性の基盤になる。

登録行は、利用中の電話番号、実装企業、サービス数、稼働状況を数えない。登録が存在しても配備がゼロの場合があり、NAPTR が存在しても対象が停止している場合があり、対象が動いても要求した主体が権限を持たない場合がある。

語彙、公開、稼働、認可、結果は異なる inventory を持つ。安定したレジストリを現実の採用率として数えない。逆に、一時的な停止を理由に共有語彙を書き換えない。この分離が標準と運用の双方を正確にする。

プライバシーを含む証拠チェーンを設計する

記録すべき最初の列は、入力番号、正規化、派生 DNS 名、resolver、RRset、DNSSEC 状態、観測時刻である。各 NAPTR について order、preference、flags、service、正規表現と生成 URI を保持する。

その横に公開情報評価を置く。URI が人名、雇用主、役割、内部 ID を露出するか、トークンはいつ生成されいつ失効するか、どのログが相関できるかを記す。その後で初めて target service の証拠を開始する。

ical-access なら認証とメソッド別認可、ical-sched ならメッセージ交接と参加者応答を追う。前の成功で空欄を埋めない。こうした構造なら、本文が守られていても URI が関係を漏らす状況を見落とさない。

現在の被害を示す資料ではない

確認した資料は、仕組み、登録、セキュリティ上の考慮事項を説明する。特定人物の URI が現在漏れていること、不正な CalDAV 閲覧、偽の招待、事業者障害を実証してはいない。本稿はそのような事件を主張しない。

それでも、組織は公開 URI を棚卸しし、読みやすい識別子を減らし、番号移管時の失効を試験し、発見と権限を分けられる。確立した機構から予防策を導くことと、根拠のない被害物語を作ることは別である。

情報源